Most organizations have ways of tracking project health, but knowing when a project is genuinely in trouble — and when leadership needs to intervene — is another matter.
Many use a simple color system: green means on track, yellow signals concern and red indicates serious trouble. But the thresholds vary across organizations — and sometimes within them. Without a shared definition, a project can remain green after its original assumptions have stopped holding up.
“The greatest risk is allowing it to continue under assumptions everyone knows are no longer true.”
Tony Miller
VP of enterprise services, Ivanti
A missed deadline or budget overrun can be obvious triggers for a status change, but those problems may reflect deeper issues or assumptions. For CIOs, project management offices and executive sponsors, the question is whether the original plan, assumptions or business case still hold, who should make that call and what should follow.
"In my experience, the greatest risk is not a project moving into red status," said Tony Miller, VP of enterprise services at Ivanti. "The greatest risk is allowing it to continue under assumptions everyone knows are no longer true."
What evidence justifies escalation
A project often shows signs of trouble before missed deadlines or overruns make the problems obvious. Early warning signals can reveal that the plan no longer holds up.
Earned-value measures and cost and schedule variances can warn that performance is slipping against an approved plan. They do not necessarily reveal whether the original assumptions or business case still hold.
"These are typically lagging indicators," explained Alan Zucker, an instructor at the University of Georgia. "Productivity, quality and staff turnover are examples of leading indicators."
Other warning signs include repeated changes to the project baseline, known as rebaselining. Revising a baseline can be legitimate when the changes are approved. But without a renewed look at the business case, a project can appear on track even as it drifts from what was originally authorized.
"The earliest warning I look for is rebaselining without a re-approved business case," explained Allan Dabre, a senior manager in technology compliance and AI risk at PwC. "The date slips, the scope shrinks, and nobody re-runs the numbers, so the business case quietly turns into a story about what the project delivers now rather than what it promised."
Warning signs can also emerge in the way people work and make decisions. Uncertainty and a lack of confidence do not necessarily mean a project is in trouble, but they warrant attention.
"The strongest leading indicators are unresolved dependencies, delayed decision making, weakening executive sponsorship and repeated replanning of core assumptions," Miller said. "Another key signal is when teams spend more time managing risk and explaining variance than delivering outcomes."
Not every warning makes a project red. Yellow can mean the team has a credible plan and the authority to resolve the problem. Red is warranted when a critical commitment or the original business case is no longer achievable without a significant change or decision beyond the team’s authority. The precise thresholds depend on the project.
Who should make the call
Recognizing trouble matters only if the organization has a way to act on it.
Organizations take different approaches to deciding who can raise the alarm. One draws on Toyota's manufacturing system, where workers can stop production when they spot a problem rather than wait for management to intervene.
"I think about Toyota's manufacturing model, where workers are empowered to stop the production line when they see a quality issue," said Hugh Cumming, CTO at Vena Solutions. "IT projects should operate on the same principle. Anyone close to the work should be able to raise a red flag, regardless of their role or seniority."
Some organizations look to the project manager and executive sponsor to initiate escalation.
"The project manager should be empowered to recommend a red status, but sponsors, steering committees and governance teams must also have the authority to challenge project health independently," Miller said.
Others favor a risk-based approach that puts the decision outside the project team.
"Red should be called by someone who doesn't own the project's success, an independent governance or risk function, working from a definition of red that was written down before the project started," Dabre said.
Raising a concern, assigning the formal status and approving a reset or shutdown are different responsibilities. Organizations need to establish who owns each decision before trouble arrives.
"Red should trigger a decision, not another round of status meetings."
Hugh Cumming
CTO, Vena Solutions
Dabre noted that organizational pressure can discourage escalation. A red status can be perceived as a confession rather than an assessment.
"In most rooms, nobody gets rewarded for raising the flag, the person who calls red has to defend the call," he said. "The people who stayed green have nothing to explain."
What happens after a project turns red
Labeling a project red does little on its own. The status needs to lead to action, whether that's a reset, an adjustment or a complete stop.
"Red should trigger a decision, not another round of status meetings," Cumming said.
Cumming said the first question is whether the original business outcome remains achievable and worth pursuing.
"If it is, identify what's changed and what needs to be reset, whether that's scope, architecture, resources or timelines," he said. "If the business case no longer holds, be prepared to stop."
Three questions when a project turns red
When a project turns red, the next step should be an executive review, not another status meeting. Tony Miller, vice president of enterprise services at Ivanti, recommends focusing on three questions:
1. Does the business problem still matter?
2. Is the plan still achievable?
3. Do we still have the commitment required to succeed?
What a reset looks like in practice
Not every course correction requires a red status. A large Sauce Labs project needed a reset after its intended customers shifted late in development. Prince Kohli, CEO of Sauce Labs, said the project was still the right one, but the user experience and entry points needed redesigning.
"This made the project yellow from green, and that was healthy, as it allowed us to hit the right customers even if late, versus the wrong ones on time," Kohli said. "We had to move design people into the team in a hurry and sacrifice or delay some other projects."
A badly underestimated timeline can also force a reset. Zucker described leading an effort to develop a new financial reporting application.
"The technology team estimated it would take nine months to build. They were not even close. It took over two years," he said.
Zucker said the team had to restructure the project several times, bringing in a new technology lead and shifting responsibilities from the technology to the business team.
"The application was finally deployed. It was a success and was used for the next decade," Zucker said.
How to make a red status count
Effective escalation starts while projects are still green, when CIOs and executive sponsors can establish the rules.
The following practices can make a red status count:
Write down the evidence. Set thresholds before a project gets into trouble.
"The objective performance thresholds for this decision should be clearly documented in the organization's procedures/guidelines or the project's management plan," Zucker said.
Make the call safe. Leadership behavior determines whether people feel comfortable raising a concern.
"Strong leaders create an environment where transparency is rewarded and early escalation is viewed as responsible leadership, not failure," Miller said.
Triage the warnings. Giving more people the ability to raise concerns also means deciding which issues warrant escalation, without discouraging anyone from speaking up.
"If there are too many escalations, it is a sign of bad planning earlier in the project, which leads to a different kind of review," Kohli said.
Judge a red by what follows. Escalation must lead to a decision, not become the end of the process.
"Red is only useful if it changes what happens next," Dabre said.
Sean Michael Kerner is an IT consultant, technology enthusiast and tinkerer. He has pulled Token Ring, configured NetWare and been known to compile his own Linux kernel. He consults with industry and media organizations on technology issues.
