In the fast-paced world of project management, maintaining a project’s status outside of the dreaded “Red” zone is crucial for success. “Red” project status leads to management escalations and frantic efforts to get back on track, but adopting proactive strategies can help keep projects from going off the rails.
By learning from the scenarios in this article, teams can navigate complex projects more effectively, avoid the pitfalls that lead to “Red” status, and ensure successful project delivery.
Things to know about keeping project status out of “Red”
- What is “Red” Project Status?
- Common Project Problems
- How To Minimize the Risk of Projects Going Red
- Example of Project Going “Red”
- Better Example of Project Going “Red”
What is “Red” Project Status?
Red is a signal put on status reports to communicate that a project will likely exceed either schedule or budget (or both). Once a project goes into Red, there are usually management escalations and lots of meetings to create plans to get the project back on track.
Common Project Problems
Problems that cause a project status to go “red” often lie in a few areas, including:
- Unspoken assumptions about how various parts of the project will be handled
- Unexpected complexity learned during the project
- Dependencies on other systems and teams that were not identified at the start of the project
- Pride, or the need to look competent in the eyes of the stakeholders
How To Minimize the Risk of Projects Going Red
Most IT projects involving code development are inherently risky because the teams usually create something new, often with recent technologies. However, many problems can be avoided through transparency. Risks should be discussed with the project stakeholders, and then the team should work with them to mitigate the risks.
Example of Project Going “Red”
The following is a hypothetical story of a project over time, along with the weekly status reports that are going to the project stakeholders.
Week 1
The team starts on a new authentication feature. They initially estimated that this feature would take 5 weeks. The IT manager recommended using an older system; however, they discovered a new system recently released to the market that should be much easier to integrate.
The team decides to use the new system and surprise and delight the stakeholders by finishing the feature early.
Status report: “Team has begun analysis for the Authentication feature.”
Week 2
The team begins to design and integrate the authentication system with their application. They find that the product is a little more complex than they expected. However, to avoid raising alarm, they do not feel a need to communicate this to the Stakeholders.
Status report: “The team continues to analyze and design the Authentication feature.”
Week 3
The developers have integrated the authentication system into their application, and it is working. However, they started running into problems integrating with other systems at the company. Each time they contact another team, they are told that they have never seen this authentication system before and do not understand what they are trying to do.
The team schedules meetings with the other teams to walk them through the new authentication system, confident that they will make the needed adjustments in their systems.
Status report: “Authentication feature is dev complete; integrating with dependent systems.”
Week 4
After meetings with the dependent teams, it became clear that the other teams were unwilling or unable to upgrade their authentication systems to the new system. The project team decided the only way forward was to go back and re-do the work, using the old system.
The team made an assumption that the other teams would want to integrate with their new system, underestimated the complexity of the new system, and didn’t anticipate the project dependency on the other teams.
The team wanted to look competent to the stakeholders and not admit that they made a mistake trying to use the new system. They decide to use the buffer time in the schedule (generally used for sickness, vacation, and other unplanned events) and shave off time from other features to fit this in.
Status report: “The team continues to work out some issues with the Authentication feature.”
Example Project Conclusion
Predictably, while the team completed the Authentication system, the timeline for other features became compressed, and the whole project got behind schedule and went into Red status. The team struggles to communicate this to the stakeholders, but ultimately tells them that delays in the Authentication feature resulted in delays to the overall project. The stakeholders ask why this wasn’t brought up earlier, but they can only apologize.
Lesson Learned
The team didn’t realize that this surprise may have been avoided if they had involved the stakeholders in the risky decision from the start. The stakeholders may have:
- Told them that the other teams would not want to make the changes to integrate with the new authentication system
- Discussed the change with the other teams’ management to get agreement on the integration work
- Connected them with subject-area specialists who could have steered them in the right direction.
Escalation isn’t about admitting failure or getting someone into trouble. Often, it’s just about getting information to the right people at the right time to clear the path to success.
Even if the stakeholders’ involvement didn’t get the project back on track, by discussing the risk earlier in the project and bringing it up in every status report, nobody is surprised when you need to make changes to the plan.
Here is how the same project could have played out…
Better Example of Project Going “Red”
Week 1
The team starts on a new authentication feature. They initially estimated that this feature would take 5 weeks. The IT manager recommended an older system to use; however, they discovered a new system that was recently released that should be much easier to integrate.
The team presents this decision to the project stakeholders, along with the possible benefits of finishing the feature early and the risks inherent in using new technologies. The stakeholders approve the use of the new technology.
Status report: “Team has started analysis of the Authentication feature using the new system. The team and Stakeholders agree that the potential benefits outweigh the risks.”
Week 2
The team begins to design and integrate the authentication system with their application. They find that the product is a little more complex than they expected. They keep the stakeholders in the loop.
Status report: “The team continues to analyze and design the Authentication feature. The new system is more complex than originally thought, but the team is confident that they can complete the work on time.”
Week 3
The developers have integrated the authentication system into their application, and it is working. However, they started running into problems integrating with other systems at the company. Each time they contact another team, they are told that they have never seen this authentication system before and do not understand what they are trying to do.
The team schedules meetings with the other teams to determine where integration issues are. At the same time, the team escalates these problems to the stakeholders, who say they’ll meet with the management of the other teams.
Status report: “The Authentication feature is functionally complete. We have run into issues integrating with dependent systems. We will meet with the other teams to see if we can find a solution.”
Week 4
After meetings with the dependent teams, it became clear that the other teams were unwilling or unable to upgrade their authentication systems to the new system. The stakeholders have come to the same conclusion in their meetings. Together, the team and stakeholders decided the only way forward was to go back and re-do the work, using the old system.
The project team calculates the impact of this rework on the project plan and communicates the updated plan to the stakeholders. They say the update looks reasonable. The plan is updated.
Status report: “The team has run into blocking issues with the new Authentication system. After discussions with the dependent teams and the project stakeholders, the decision was made to redo the work using the existing authentication system. This will push back the schedule by 3 weeks. The project stakeholders have signed off on the schedule change.”
Better Example Project Conclusion
By involving the project stakeholders in major decisions, project teams bring them along as partners in the project. They work together with the team, celebrate victories together, and suffer setbacks together. And adjustments made along the way can keep the project out of Red status.
Partner with AIM on Your Organization’s Digital Journey
Our team at AIM Consulting consists of experienced and knowledgeable experts who lead technology engagements across industries and deeply admire each client’s success.
Our consultants have the experience required to manage complex and expansive projects, communicate effectively to align phases, and increase team collaboration, providing shared understanding at all organizational levels.
Insights By
Ready to Achieve Valuable Outcomes On Time and On Budget?
Learn how our delivery experts at AIM Consulting can help improve agility, reduce waste, and maximize value from your organization’s technology initiatives.
