Project Managers: The Trust Metric

September 1, 2011 — Bruce McGraw

Conventional “management” wisdom states that having trust among team members and between the team and management is critical to project success.  I just finished a project to implement a new tool suite for an organization and the need for trust was very apparent.  Trust however is neither simple to define or achieve. Trust is subjective. It involves a few key elements:

  • Predictability – a project manager expects a team member / employee to do what they agree to do in the way their manager expects them to do it. Likewise, employees trust managers who do what they say and what is expected of them.
  • Value Exchange – this element of trust means that you (and the organization) treat employees and staff fairly in exchange for satisfactorily completing the work they agree to do. This element has a touch of accountability in it.
  • Delayed Reciprocity – this element of trust is about giving payment or services with the expectation that sometime in the future your contribution will be recognized through receipt of goods or services of equal value. Kind of the “if I do good work it will be recognized/rewarded in the future” thought.
  • Honesty – this is a key element in trust.  It is very hard to measure, but easy to see when it does not exist. This element has the foundation of truth as its core.

Trust in the Real World of Management
If you only trust managers who place your interests ahead of their own, who always provide you with interesting assignments and give proper rewards and attention to your career, you will likely be disappointed. The Work Place Therapist offers these observations  about how managers make decisions:

  • They think of themselves and the impact a decision or assignment has on their lives and career (People will always look out for themselves, if possible).
  • They consider their reputation and want to be seen as go-to people who can get the job done.
  • In order of importance, they try to please their boss, the client and then you.

Understanding the priorities of senior executives and project managers helps you understand and predict how they will behave in a given situation. That being said, building trust on a team actually furthers the career goals of managers. Teams with high trust levels are more productive, more creative and enjoy the work and tasks more than teams where everyone feels they have to go it alone and watch their backs at all times. Teams without trust are dysfunctional and likely to fail.

How to Build Trust
Trust is built on a foundation of honesty. Project managers need to share information about project goals, resources and status and provide background or elaborate on the reasons for decisions. PMs need to show the team that they are professionals and value respect, honesty and accountability. The team may not like your answers; however, they will trust you as a conveyor of information.

If you make a promise to the team or individuals, you must follow through. If you fail to accomplish something you promised to do, you need to accept the responsibility, explain the failure – without pointing fingers up the management chain – and move on.

As a project manager, you build trust and the respect from your team through efforts to develop their skills and facilitating, to the extent possible, opportunities for them to display their accomplishments and be rewarded for their efforts. Taking credit for the work of others or denying them opportunities for advancement creates mistrust (vague doubts) and distrust (suspicion and complete lack of trust.) Working to ensure that team members are appropriately compensated, both monetarily and with perquisite considerations (Giving special perks), shows respect and helps develop the part of trust that relies on value exchange. Trust me when I say that the other team members will watch who you praise and reward to see if you are true to your words.

Delayed reciprocity may be the most challenging element of trust to build because it involves the most risk. From the perspective of a project manager, delayed reciprocity means you show trust in your team before you have evidence of their trustworthiness. You listen and accept their explanations of a task’s status. You expect them to solve problems and share accurate information with you and the team, without checking up on them. If an employee or staff member asks for exceptional consideration, such as time off or temporary changes in work hours because of a family problem, you trust them to be truthful and you make efforts to accommodate their situation.

Building team trust pays off in performance, creativity and employee retention. This is also how a culture of trust is built. Building trust is a key part of improving organizational and project culture. For those of you wanting to move beyond just building trust, Edgar Schein has many excellent articles and books about leadership and culture.

Have you been challenged to give or receive trust? What methods have you found successful? In your experience, what manager behaviors kill trust?

Posted in Best Practice, General Project Management, management, pm, Project Management. Tags: , , , , , . 2 Comments »

Making a Project Manager’s Work-Life Miserable

July 29, 2011 — Bruce McGraw

You might have noticed in previous posts that I occasionally mention the entertaining and wise writings of Scott Berkun. His book, Making Things Happen: Mastering Project Management (Theory in Practice) is an experience-based trip through managing a project. His other writings and presentations offer wisdom couched inside a great sense of humor and wrapped with a touch of cynicism. When he recently posted on the topic titled, How to torture your project manager. I could not resist.

I won’t spoil the entire post here, but I selected a couple good whammies and then let my mind wander over tactics and strategies that can give a project manager ulcers or at least ruin his or her day. So, here are a couple of Scott’s key observations:

  • Never give specific odds or probabilities. Always make ambiguous commitments like “Probably,” “we may be able to do that” or “it’s possible.”
  • Do not disagree directly when your manager makes a proposal or suggests an action. Wait until you are both in the presence of their boss, or bosses boss, and intensely disagree then.

Here are additional tricks of the torturer’s trade based on my observations and experience:

  • Never answer a project manager’s question directly. Always add caveats, conditions, or a list of concerns.
  • Alternatively, agree to do anything the project manager asks, without telling them how long it will take or how much effort is in involved. (They should know enough to ask- right?)
  • When working on problem solving during a staff meeting, continue to suggest that more study is needed before the question can be answered. Suggesting a gold-star committee to work on the problem and report back can add weeks of delay to the project schedule.
  • Wait until the last minute (or after) to tell your PM you are running late on finishing a task.
  • Do not ask for help with a problem until you are at least a week behind schedule.
  • Save up some really good or bad news for staff meeting with your PM’s boss.  Your PM will be glad you shared.
  • During staff meeting repeatedly change the subject to something of personal interest to the project manager. This is the same strategy you used in school to get a professor talking about politics in order to steer him away from a hard differential equations assignment.
  • Ask your previous project manager what they would do in a certain situation. Then use that as a defense when talking with your current project manager.

Goodies in the same vein from Rafael Mumme’s article, 20 Things That Drive Web Developers Crazy

  • Fill out your time sheets at the end of the week, so the PM won’t know until Monday that the project is over budget.
  • Play “catch me if you can” to get your timesheet filled out. Mention that while you’re filling out your time sheet you’re not working. “For bonus points ask how long you should add into your timesheets for the task of filling out your timesheets.”
  • Don’t tell us when you have completed a task, wait until we ask.
  • Mention at least once a week that no one uses Windows or Internet Explorer anymore — despite the analytics

Share your favorite stories of how to torment a project manager.

Posted in pm, Project Management, staff. Tags: , , , , , , . 3 Comments »

Managing Implementation Projects – Tips and Tricks

July 23, 2011 — Bruce McGraw

Is there a difference in managing a project that is implementing a “Commercial-Off-the-Shelf” (COTS) application, versus managing a new software development project? Many of you would say there is a world of difference. In my opinion, it is not that simple – there are some project elements that are common to both, and some things that are much different.  Here are some best practices from my 20+ years of managing successful projects that I’d like to share with you today.

Software is Software
Technology projects involve that dreaded word “software.” But let’s not panic. First, software has become ubiquitous—with few exceptions, is probably inside of every physical item we buy or use today (cars, TVs, cell phones, etc).  Granted, not all software is the same. Some can be configured, while other software is “locked down.” When organizations
decide to build custom software applications rather than buying a COTS tool it is often because they need to lock down functionality to a specific use or process or because they need some special function that COTS software does not have.  More and more often, organizations are discovering that a COTS application will do 80% of what they need, with 30% of the cost.

Consequently, I have been managing a lot of Microsoft® Project and SharePoint® implementations this year. These software products are very powerful and can be highly tailored to an organization’s business processes without writing new software.  Projects to implement and configure tools such as these tend to ignore some of traditional software lifecycle aspects and I don’t think this is a good thing. Here are some of the steps I think still need to be included when planning and managing an implementation project for a COTS application.

  1. Requirements.  It is the key to successful projects—COTS or not.  Managing a project still requires knowing what the client and user requires and really needs (vs. wants) to produce their job outcomes.  (Listening to Customers)
  2. Planning.  I don’t think I have to elaborate for my tradition PM readers – this is the only way to identify and set expectations, schedule, staff and resources.
  3. Design.  Even though the application may be COTS, I find that the choices for configurations, the level of customization, and the ability of the latest generation of tools
    to change the look and feel of the product – really does require a good design.  Hopefully the design is done by professionals who are experienced in the software and have implemented it before. (Design with Users in mind)
  4. Testing.  I would hope that any project involving software would include this element, but have been amazed at how many times I see something put into production without testing because it is a COTS solution. Be sure your users get a chance to test the new application (UAT). (For more on testing see the post on usability testing.)
  5. Documentation. I can’t say enough about this – and I am NOT talking about the manufacturer’s manuals. Documentation does not have to be volumes of paper. However, there should be something for the support staff that documents the configurations and changes that were made to the system. I find that when outside consultants are used, this activity is more likely to be done. In my experience, when internal staff perform the configurations, documentation to more likely to be “lacking.”
  6. Training. My #1 pet peeve is that too many organizations are now “short changing” training to cut costs. They expect that all their users need is a simple, short one-hour overview and they will become experts in using the system. I fight to include a more robust and comprehensive training as a part of the projects I manage – and yes, I know that this increases the cost of the project.  But in the long run, training that equips people to use these new tools to do their jobs also increases the likelihood of system acceptance and long-term success!  (Making training better and How not to do training)

People are People
Back in 2009, I wrote a post titled “Does anyone listen to the Customer?” which was about how the PM should be the client advocate.  In practice, a project
manager uses customer requirements, resource knowledge and experience to construct a realistic project schedule and budget.  But a good PM knows that on a COTS implementation, the customer does not really know the full limitations or capabilities of the product.

I am currently managing a project where the Business Unit clients were being asked to tell what they needed the system to do.  This was without first giving them either an
expert to guide their input, or showing them what the application could potentially do.  These are people who know their business really well – but do not have a concept of what the new application might do.

Now I believe in focusing on solving business problems for a successful project, but the process for building good requirements should not lie completely with a novice business user.  We will either get requirements that cannot be accommodated or miss opportunities to really leverage the new tool because “they didn’t ask for that function or
capability”. If the user knew all of there was to know about the tool, he or she would probably not be in the business unit but rather in IT.

At the end of the project we want the implementation to actually solve or improve some real business process issues. The best way to insure that is to involve the people who have to use the technology and see what intersections can be made between the application’s functions and the user’s job outcomes.

So how many of your projects are actually “implementation projects” rather than software development ones?
Leave us a comment….

Posted in Best Practice, General Project Management, pm, Project Management, Requirements. Tags: , , , , , , , , . 1 Comment »

Agile and project management – Advice from the warriors

May 26, 2011 — Bruce McGraw

Agile is as agile does. There has been a lot of press and hype about agile software development since the Agile Manifesto in 2001was made public. Well, those visionary ideas are a decade old now. So, I thought I would glance around the web and see the comments and advice from experienced practitioners of non-traditional management. I have written on this topic before (Agile Project Management in April 2010), but have continued to read thoughts on the subject from esteemed colleagues.

First: A couple key points from the original Agile Manifesto:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Deliver working software frequently.
  • The best architectures, requirements, and designs emerge from self-organizing teams.

Comments from Practitioners:
Here are some of the practitioner’s comments from my readings:

George Mattie
“As I understand it, agile as a methodology does not allow you to overcome the basic physics outlined in the triple constraint (ed. cost, time, scope.) Agile simply prioritizes the tradeoff as one of scope rather than time or quality.”

“On teams that work in creative services, like those found in advertising and in consulting agencies, often the person who serves as the project lead is not a project manager.”

Bill Krebs
Have short daily meetings addressing three questions:

  1. What did they do yesterday?
  2. What will they do today?
  3. What roadblocks stand in their way?

From A New Take on Standup Meetings offered by Bill Krebs.

Glen Alleman
There is an initiative to connect Agile Software Development with Earned Value Management. I’ve talked a couple of times on this topic…..  The critical issue is what is wrong with the agile software development process you are using now? Is Scrum working to deliver products on time, on budget, and meeting customer needs? If so, then what can EV add to the mix? Not much would be my contribution, on programs that do not have an EV mandate?
Excerpt from Glen’s BLOG, Herding Cats.

Alan Bustamante
(paraphrasing) Veteran project managers may find the paradigm shift, from being a specialist to needing to be a generalist, too much, and become alienated from project management or their project role.

This theme continues with a comment from Ferrix Hovi on PM Tips, “When I close my eyes, I can hear the roar of a giant waterfall. As a scrum practitioner, I feel there is little justification for a project manager role doing the specified things.”

Countering Ferrix’s suggestion to retire all project managers were these comments (with which I agree) from Donna Burgess, “Self-managing’ teams still need a leader, a protector, a decision maker, a planner, a shield, a guide, a problem solver. Sadly, many Agile evangelists will only understand the value of a PM when they don’t have one.”

“My recommendations for moving to Agile would be to try it on a small to medium project. Agile is best suited for small teams, no more than 7-10 people. If working a large project, it is recommended that you break down to small groups and manage a Scrum of Scrums.… Get the team indoctrinated in Agile before starting if at all possible. It puts everyone on the same page from the beginning.”  Jim Skinner, PMP, North Carolina Department of Insurance

“Every conversation about Agile project management eventually turns to the question of estimating. Rick Freedman explains why estimation in an Agile environment is not as mysterious as many PMs think.” (thoughtful article in TechRepublic.)

“Incorporating Agile management techniques into projects fosters a focus on the benefits of each feature. In traditional project management, the teams strive to finish the project on time and under budget and often lose sight of the overall benefits the entire effort is intended to bring the organization. It’s important to remember the strategy the project is expected to advance as well as the total cost of ownership and not just the project costs.” Kathleen B. Hass, PMP writing for Project Management World, The Blending of Traditional and Agile Project Management.

If this Agile stuff is something you want to explore, here are a few other resources:

More Details about PMI’s Agile Certification 120 question, multiple choice; 3 hr exam; pilot begins May 2011.

Top 20 Best Agile Development Books by Jurgen Appelo; June 2008

 

I hope you will add comments, resources, or thoughts on Agile development.

Posted in Best Practice, management, pm, Project Management. Tags: , , , . 2 Comments »
« Older posts
Follow

Get every new post delivered to your Inbox.

Join 354 other followers