Most people would not want to be the bearer of bad news. However, if your project is not really “Green” (on time, on budget, on scope, etc.) then report the status as “Yellow.” If problems persist, say within a week, report the project status as “Red.”
Some optimistic project managers may hesitate to report the problems because they genuinely believe that a quick resolution will arrive soon. In some cases, however, the problems have nothing to do with the project manager’s abilities but the lack of commitment of others.
Given this, it is very crucial to communicate the importance of the problematic areas and the timely completion of the same. Highlight the dependencies and the potential impacts. Escalate the problems if necessary—but don’t cry wolf. If you’re still unsuccessful, then you’ll have no choice but to report the problems.
Connect with Dr. John A. Estrella via Facebook, LinkedIn and Twitter.
Tags: project status reports
I think the premise of the question, “When to REPORT a project is red?” presents a problem. It suggests that only a project manager has access to the information necessary to judge progress. Information should be accessible across the entire project team.
Whether you are a business analyst, tester, engineer, stakeholder or project manager, you can work more efficiently if information is shared across job functions. A big part of keeping teams synchronized is their ability to know how others are progressing and how their own progress will impact others.
If a project manager is the only one on a team that has the information to know that a project is falling behind then I would humbly suggest that there is an increased likelihood that the project is or will be in the red.
How did you arrive at the conclusion that information was not shared?
It could be that the individual in question is just on the “outside” of the core project team whose job is simply to provide guidance or approval. For example, that individual could be a subject matter expert or a project steering committee member. Despite your repeated pleas to that individual to provide the guidance or approval in a timely manner, you still did not get a response—for reasons unknown. As a result, you and your team cannot proceed to the next tasks.
So, everybody is aware of the situation but you are pretty much stuck—until you raise a flag to bring awareness to the situation. This scenario could happen, as it did to me on several occasions, despite my best efforts to be proactive in identifying potential problems in my projects.
Agreed, there is nothing you can do about executives or stakeholders who are unresponsive. I also agree with you about the need to raise small details that have the potential to blow-up into big problems and that a good PM will proactively alert stakeholders of potential problem areas regardless of how information is shared.
My response was based on the fact that for many of the people who come to us for help, the answer to whether a project is on-time, on-budget, or in scope exists only in a spreadsheet on the PM’s hard drive (and that spreadsheet has week-old data that may also be incomplete). In that situation, “raising the alarm” is at the sole discretion of the PM until it becomes way to late. When that data lives in a centralized repository and can be rolled up into a real-time project health dashboard accessible by stakeholders, then everyone knows the project’s status with or without a report from the PM (assuming they choose to look).
Great blog. Thanks.