5

As the answers on this forum have re-iterated over and over, frequent transparent communication is critical, and stakeholders should be made aware of risks and problems early and often.

As such, when (or is it) appropriate to name names in a status report to stakeholders when a given project is off track due to bad performance by a given team or team member? How do you balance the hit to the working relationship versus the need to draw attention to a problem that may have a broad impact?

10

I have two answers for this.

First- Always. Build your project from the start, with clear lines of responsiblity. Every task has an owner, and it is clearly visible in the responsibility matrix (I use a full RASCI style). In my upcoming milestone reports I will list who the owner is for those upcoming milestones, along with the status.

You create a pattern of accountability from the get go. Green, Yellow, Red, every task has an owner.

Second Never report a red status up the line without first making sure that task owner knows the report is happening and give them time to address the issue. Manager Tools just put out a podcast labled "Internal Team Pre-Wire", which addresses this topic directly. As Horstman puts it "You don't drop a dime on a team member."

Even if its a regular status report, you make sure the task owner is clear. "Bob, I have to report project status on Wednesday. This is going to show as red."

Horstman suggests 48 hours notice. Not always possible, but five minutes notice (Walking into the meeting, you tell Suzy you are going to hang her out to dry is not giving her time to respond).

  • +1 - I really like this approach. Giving the team member time to change the status from red to yellow is great for the team member as well as for the PM and the project. No one likes bad news, even if you're just the one delivering it. – jmort253 Apr 2 '11 at 19:48
  • In domains with highly static plans, this approach may be quite effective. Is the approach different when dealing with domains containing much higher variability or more unknowns when entering into the project? – Eric Willeke Apr 7 '11 at 5:23
7

Ultimately, the project manager is responsible for the survival or failure of a project. If a team member did something that caused a problem (or even project failure), you are still responsible for the project. Stakeholders expect you to manage the team, the risks, the scope, the schedule, everything.

Based on this, I would say that naming names (especially for blame) is useless. If anything, it'll look like you're trying to pass on the blame to someone else.

Therefore, I would say name team-member names to those outside the team to give them credit. This shows that you support your team and are happy to give credit where it's deserved.

And also, name names (if absolutely necessary) within the team. Ideally, the person you're blaming is in the room when you're telling whoever else it is who needs to know what they did.

Again, the person is not important who made the mistake, because everybody makes mistakes; what's important is to move forward as a team, regardless of who slipped up.

  • 1
    +1 brilliant answer, except one thing. I would change the last phrase to "move forward as a PM, regardless of who slipped up". This is what project sponsors are expecting from you. This is what the first part of the answer is about. – yegor256 Apr 3 '11 at 10:33
  • Great overall answer! My mantra is almost always "Public credit, private critique", and I agree with @yegor in that the entire team is in the project together, and the fault is collective even if the cause is singular. – Eric Willeke Apr 7 '11 at 5:22
  • +1. It is always your fault. tinyurl.com/itisyourfault. – thousandtyone Apr 7 '11 at 16:48
  • @Eric. "the fault is collective even if the cause is singular" - I'm guessing this means the fault will be perceived as collective even when the fault is singular; is that correct? – gef05 Apr 8 '11 at 13:10
  • @Gary Very rarely have I seen true singular fault, at least in my software development domain. If a single task leads to a non-delivery, why was the team not collectively aware of that task struggling? If sone person was working late the night before, why were they alone? I'm struggling to create a non-malicious answer where the system couldn't have adapted effectively to prevent the single point of failure. (I can think of many intentional ways of destroying a project, and those probably should be called out by name and dealt with via HR) – Eric Willeke Apr 11 '11 at 13:18
3

Feel free to name names when giving credit. Avoid the appearance of favoritism. Giving credit as soon as possible is a good idea, but you don't need go give credit every time it is earned.

I would try to avoid naming names when there are problems. You can still target teams by stating which deliverables are not available on time. The appropriate managers should know which team is responsible. There may be acceptable reasons why you aren't getting the support you need, but management needs to be made aware of the effect.

If you have problems with resources assigned to the project, you may need to involve the Human Resources department. They may be placed in an appropriate position or otherwise out of their comfort zone.

If you need to dress someone down, do so in private. Listen to their explanation, and try to come of with a remediation plan. Document the discussion as soon as possible. If the person needs to be removed from the project, such documentation may be important.

If the problem is an honest mistake own up to it, but don't name names. Those involved will know what happened. Do consider how to avoid similar mistakes in the future.

1

Within the team: always (for the good and the bad)

Outside the team: Never

If you as the project manager do this, putting blame on someone who isn't even there and has no chance to defend themselves (the technical term for this is "throwing someone under the bus"), you will do more damage to your team than you can probably imagine. Instantly the team focus will be on CYA (Cover Your Arse) instead of working as a team and being honest when things aren't working out. A blame game, or rather arms race or cold war, will begin, and any positive team dynamics you had will be destroyed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.