difficult project teams and how to handle poor performers - 12.07.11

The problem

People in the project team are not contributing / are being divisive, or just plain out of control. The project is a mess
The solution is in a number of steps, each one applied until the end step, where the team processes and systems are reviewed.

Step 1 – ask yourself if you’re doing something wrong . Are you giving vague requirements and poor briefs to the members of your team? Are you micromanaging when you don’t need to ? Are you reprimanding your team members in public? Are you playing favourite? If you have answered that you are not doing any of these things, then go to step 2. If you are doing any of these things, then stop doing them, and see what happens.

Step 2 – ask your team members if they think that you are doing something wrong. ( If they answer that you are, this does not mean that you actually are. It means that the people you have asked think that you are. Their perception is often their reality, and this influences their behaviour ) If they think you are doing any of these things, then promise to stop doing them, check again with the team members in a while and see what their perceptions are. If they still think you are doing any thing wrong, decide whether you want to keep working on the project, or whether you replace the team members with some people who are more kindly disposed to your way of operating. If they don’t think you are doing something wrong, go to step 3.

Step 3 – Talk to the troublesome team members functional manager: Sometimes team members become “difficult” because they just don’t want to accept that you are telling them what to do and/or they think that you don’t have technical leadership. If you talk to that team members’ functional manager then the latter might rectify the situation. If this does not work, then decide whether you replace the troublesome team members. If this doesn’t solve the problems, go to tsep 4

Step 4 – If you have dealt with steps 1 to 3, or not needed to, then maybe you should ask yourself if the project sponser is the problem. The sort of person who says “ I’m not exactly clear on what I’m looking for, but I’ll be sure to hold you responsible when I don’t get it… “
Too often sponsors may have a vague idea of what they want or worse than that they may be frustrated by a complicated problem or issue but have no real idea of what they want done to address it. The first phase of the project management cycle (Initiating) is where the sponsor (or senior managers) should be clarifying why the project is being initiated and determining the high level expectations of the project. Too often this step is skipped and project managers are sent on wild goose chases trying to reach a loosely or poorly defined objective. Don’t fall into that trap.

Do the following
Clarify the effort early and often. Identify “in” scope items and “out of” scope items (out of scope is critical), tangible deliverables, timing expectations, budget restrictions, roles and responsibilities, known risks, and key stakeholders.
 Identify their soap box issue early and emphasize WIIFT (What’s in it for them). If they don’t understand exactly what they want, ask them to explain their motivation/driving factor. Oftentimes, execs have a soap box issue, predetermined bias, or hypothesis they want validated. Try to find out what this is as soon as possible.
 Ask the sponsor to prioritize cost, time, and scope (good, fast, and cheap). Which is most important (relative to the others)? Hint: The answer is not all 3
 Explicitly ask how they will define success. ALWAYS ask the sponsor to finish this sentence…I will consider this project a success if…

If you have dealt with steps 1 to 4, then go to the next step

Step 5 – look at the team processes/ procedures / systems and ask whether they are appropriate for the team that you have working on the project at the moment. As teams mature and evolve, so the processes / procedures and systems should also evolve and mature. A great tool or process can’t help without the collaboration and work of a strong team and project manager. Successful teams take advantage of failure and reflect, do a retrospective, and improve the process.
Probably the most important—and the most difficult to judge—characteristic of a well-functioning team is the possession of the focus and vision needed to create an outstanding product. Procedures / processes / systems need to assist in achieving this vision.
How do you determine whether a team has that level of shared understanding?
One method that seems to work well is to pick a few individuals from a variety of areas on the team and ask each one to briefly outline the vision for the project. If each person selected cannot immediately identify, in just a few sentences, the key goals and the key customers for the project, the project is in trouble.
A key process often missed is tracking metrics. The team should pick some metrics to track and should widely publish them regularly, at least monthly.
Decide the overall goal that you want to accomplish.
Determine a metric that will display whether you are meeting your objective. Define what it means if the number goes up, what it means if the number goes down, and what you might do about either case.
Track the metric, report it on a regular basis, and review your performance using it.
Change how you are working if you aren’t meeting your objective. If you can’t envision this happening, you’re tracking the wrong metric.

You want to avoid tracking metrics for their own sake or tracking things that don’t optimize your team’s behaviour or measure your progress. Tracking the wrong thing can be worse than tracking nothing, because you may lure yourself into a false sense of accomplishment.

One of the more reliable predictors of the health of a project can be to determine where the schedule originated. If the schedule came from anywhere other than the people who will actually do the work then there is a chance that the people doing the work don’t care about it, don’t believe it, or ignore it.

Some managers feel the need to lie to their teams about the “real” date. The manager has in his or her head the date he or she expects the work to be done, and may even tell the boss this date, but will tell the team some earlier date. Managers excuse this blatant abuse of trust by insisting that it makes the team work harder. “They wouldn’t come in on weekends or really bust it if I told them the real date.”
This is simply horrible management. You can’t trust the team with the truth, but you’re willing to trust the team with the product? It makes no sense.
It has been proved time and again that teams can and do respond well to liberal doses of the truth. Explain the details of the schedule, define the pressures on the team, involve team members in the decisions, and track the progress daily with them. Every team dealt with in this way responds like the collection of professionals it is.

Related posts:

  1. The PMO
  2. Actively engaged ? or disengaged ?
  3. Why coaching in the infrastructure area 2 ?
  4. Public workshops second half 2011
  5. Why coaching in the infrastructure area 1 ?

Leave a Reply

Logged in as