Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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?
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).
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.
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.
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.
