The post-mortem is one of the most honest documents an organization ever produces — and one of the least useful. By the time a project has failed visibly enough to warrant a formal review, the cascade of problems stretches back months. The delivery team knew. Middle management suspected. And somewhere in a status report, the evidence was there, buried under amber RAG ratings that nobody escalated. Project management and risk management disciplines exist precisely to catch these signals before they compound. The organizations that consistently deliver complex programmes are not the ones with the most sophisticated methodologies — they are the ones that have trained themselves to act on early warning signs rather than explain them away.

Why projects fail late but signal early

In our experience working with mid-market organizations on complex transformation and technology programmes, project failure almost always has a long pre-history. A two-month delay that surfaces in month eight was typically seeded in months two through four. The reason organizations miss these signals is structural: status reporting is designed to communicate upward, and teams under pressure quickly learn that escalating problems invites scrutiny, so they absorb the problem instead. The result is a gap between the real project state and the reported project state that widens slowly until it becomes impossible to conceal.

The ten warning signs below are organized roughly by when they tend to appear in a project lifecycle. Some are visible in the first quarter of a programme; others emerge mid-execution. None of them are exotic — every experienced programme manager has seen them. The failure mode is not ignorance of the signs; it is the organizational habit of rationalizing them rather than responding to them.

1. Schedule slippage that is not escalated

What it signals: When individual workstream leads report that they are “slightly behind” but the project-level schedule shows green, the team has begun absorbing slippage locally rather than surfacing it. This is not a scheduling problem — it is a team culture problem that indicates the escalation path feels unsafe or futile.

The intervention that works here: Introduce a simple rule at the workstream level: any task that moves its completion date by more than five business days must be reflected in the integrated master schedule within 48 hours, with a documented recovery plan or a formal request for schedule relief. The act of making slippage visible — without punishing the person who surfaces it — resets the team norm. Programme managers who do this consistently find that teams begin escalating earlier because they see that early escalation leads to help, not blame.

2. Scope is being absorbed without change control

What it signals: Mid-market technology and operations projects are particularly vulnerable to what practitioners call “scope gravity” — the tendency for new requirements to attach themselves to an active project because it is the path of least resistance. When delivery teams begin absorbing requirements that were not in the original scope document without raising a change request, two things are happening simultaneously: the project’s cost and schedule baseline are becoming meaningless, and the team is being asked to do more work with the same resources.

The intervention that works here: A two-week audit of what has actually been built or configured versus what was in the original scope document. In our experience, organizations running projects of six months or longer without a formal change log have typically absorbed between 15 and 30 percent additional scope without corresponding budget or schedule adjustments. Make the change log visible to the steering committee, not just the project manager.

3. Key decisions are being deferred repeatedly

What it signals: Every integrated master schedule contains decision milestones — moments where a business choice must be made before technical or operational work can proceed. When the same decision appears on three consecutive fortnightly status reports as “in progress” or “pending stakeholder alignment,” the project has a governance problem, not an information problem. The decision is deferred because no one with the authority to make it has been given a forcing function to do so.

The intervention that works here: Escalate the decision to the steering committee with a hard date and a stated consequence: if the decision is not made by a specified date, the project will be delayed by a specified number of weeks. This is not a threat — it is an accurate description of the dependency. Steering committees that have never been shown the cost of their indecision in concrete schedule and budget terms are often surprised by this framing. Show them once, clearly, and the pattern of deferred decisions typically improves.

4. Testing and quality assurance windows are being compressed

What it signals: In virtually every project that runs late in its build or development phase, the schedule recovery plan involves shortening testing. This is one of the most reliable predictors of post-go-live failure in programme management. Testing is compressed because it is at the end of the schedule and because its output — defects — is unwelcome news. The organizations that do this consistently have not made a rational trade-off; they have deferred risk to the worst possible moment.

The intervention that works here: Treat testing duration as a protected minimum in the project schedule, not a float buffer. When build phases run late, the recovery plan should first examine whether parallel workstreams can be accelerated, whether scope can be formally descoped for a phase-two delivery, or whether the go-live date can be moved. Compressing testing should be the last resort and should require explicit steering committee sign-off, with documented risk acceptance.

5. The project sponsor has become difficult to reach

What it signals: Sponsor disengagement is one of the most consequential early warning signs in programme management, and one of the most socially awkward to name. When a sponsor who was actively engaged in the first two months of a programme becomes consistently unavailable for steering committee meetings, stops reading status reports, or delegates all project interaction to a more junior representative, it usually means one of three things: the sponsor has lost confidence in the project’s trajectory, the sponsor’s priorities have shifted at the executive level, or the sponsor never had genuine organizational commitment to the programme’s objectives.

The intervention that works here: A direct, private conversation between the programme director and the sponsor — not via email, not via the project manager — to explicitly name the pattern and ask whether the programme still has executive sponsorship. This conversation is uncomfortable and is frequently avoided. In our experience, it is almost always worth having, because the alternative is a programme that continues consuming budget and organizational attention without genuine executive backing. If the sponsor’s commitment has genuinely eroded, the steering committee needs to know and the programme’s future needs to be decided explicitly, not by attrition.

6. Budget underrun in the early project phases

What it signals: Finance functions are trained to flag overspend. They are rarely trained to flag underspend in early project phases — but early-phase budget underrun is a reliable warning sign that the project has not actually started the work it was funded to do. In mid-market organizations, early-phase underspend typically indicates delayed vendor onboarding, unfilled project team roles, or a project that exists on paper but has not mobilized. The budget will be spent — usually in a compressed rush in the final phases, which drives poor decisions, overtime costs, and quality shortcuts.

The intervention that works here: Require monthly reporting of actual spend versus planned spend by phase, with a narrative explanation when cumulative underspend exceeds ten percent of the phase budget. The question to ask is not “are we under budget?” but “are we progressing the work we planned to progress?” If spend is behind plan and deliverables are also behind plan, the project is simply late. If spend is behind plan but deliverables are on track, investigate whether the cost model was accurate. These are different problems requiring different responses.

7. The risk register has not been updated in more than three weeks

What it signals: A static risk register is a sign that risk management has become a compliance activity rather than a management tool. On active projects, the risk profile changes continuously — new risks emerge, existing risks change in likelihood or impact, mitigations succeed or fail. When a risk register goes stale, it means either that the project team is not genuinely assessing risk, or that they are assessing it but not recording their assessments. Either way, the steering committee is making decisions based on outdated information.

The intervention that works here: Make risk register review a standing agenda item at every fortnightly project team meeting, with a named owner for each open risk. The owner is required to confirm or update the risk status at each meeting. This takes approximately fifteen minutes on a well-managed register and is the single most reliable way to keep risk management from becoming a box-ticking exercise.

8. Stakeholder engagement is concentrated in one or two individuals

What it signals: Projects that rely on one or two “go-to” business stakeholders for all requirements clarification, decision-making, and user acceptance are extremely fragile. When one of those individuals goes on leave, leaves the organization, or is pulled into another priority, the project loses its primary interface with the business. In our experience, this pattern is most common in mid-market organizations where the project champion is also a senior operational leader with significant competing demands.

The intervention that works here: Map stakeholder engagement explicitly — who has been consulted, who has been informed, and who needs to be involved in user acceptance. If the map reveals concentration in fewer than three business representatives, actively broaden the engagement. This is not about adding bureaucracy; it is about building organizational resilience into the programme so that personnel changes do not create project crises.

9. Issues are being closed without resolution

What it signals: Issue logs are routinely manipulated to show green status — not through deliberate dishonesty, but through a cultural pressure to close issues rather than carry them. Teams close issues by marking them “resolved pending confirmation,” “monitoring,” or “accepted.” When you audit closed issues and find that a significant proportion have no documented resolution action or have simply been re-opened under a different entry, the issue management process has lost integrity.

The intervention that works here: Require that closed issues have a documented resolution action and a named confirmer — someone outside the immediate delivery team who confirms that the issue is genuinely resolved. A fifteen-minute audit of any project’s closed issue log is one of the fastest ways to assess project health that is available to a programme director or PMO lead.

10. The team is too busy to plan

What it signals: When delivery teams are too busy executing to maintain their own schedules, attend planning sessions, or update project documentation, the project has entered a reactive mode that dramatically increases the probability of late-stage failure. Planning and execution are not alternatives — they are complementary. Teams that stop planning under delivery pressure consistently find that their execution quality degrades: rework increases, dependencies are missed, and the schedule becomes notional rather than real.

The intervention that works here: Protect a fixed percentage of the team’s available time for planning, documentation, and coordination — in our experience, approximately ten to fifteen percent is the minimum viable allocation for projects of medium complexity. If the team cannot maintain this allocation because of delivery pressure, the project is either understaffed or the scope is too large for the timeline, and that is a conversation that needs to happen at the steering committee level, not be resolved by asking the team to work harder.

Acting on signals before they compound

The ten signs above share a common characteristic: each one is manageable at the point it first appears and significantly more expensive to address once it has persisted for four to six weeks. The organizations that manage complex projects well are not the ones that avoid these signals — they are the ones that have built governance structures and team cultures in which surfacing a warning sign is treated as a contribution rather than a failure. That cultural shift requires consistent, visible behaviour from senior leaders: actively rewarding early escalation, responding quickly when signals are raised, and never shooting the messenger who brings bad news early.

If your organization is running programmes worth more than one million dollars without a structured mechanism for detecting and acting on early warning signs, the question is not whether you will encounter these signals — it is whether you will see them in time to respond.

Frequently asked questions

How do we distinguish a genuine warning sign from normal project turbulence?

The key distinction is pattern versus event. A single missed milestone is turbulence. The same milestone slipping twice without a revised recovery plan is a pattern. A risk that appears on three consecutive status reports without a change in its rating or mitigation is a pattern. Apply a simple rule: any single indicator that persists for more than two fortnightly reporting cycles without a substantive management response is a warning sign that requires escalation, regardless of its apparent severity.

Our project manager says everything is under control. How do we validate that independently?

Ask for three specific documents: the integrated master schedule with the original baseline still visible, the change log showing all scope changes since project initiation, and the risk register with dates showing when each entry was last updated. The state of these three documents will tell you more about project health than any number of status conversations. If any of the three does not exist or has not been updated in more than three weeks on an active project, that is itself a warning sign.

At what point should a CFO or VP of Operations personally intervene in a troubled project?

Senior leader intervention is appropriate when the project is exhibiting three or more of the ten warning signs simultaneously, when the programme represents more than two percent of the organization’s annual operating budget, or when the steering committee has been presented with clear warning signs and has not taken action within two reporting cycles. The intervention should be structured — a formal project health review with an independent assessor — rather than informal pressure on the delivery team, which typically makes the culture of non-escalation worse, not better.

Is it ever the right decision to cancel a troubled project rather than attempt recovery?

Yes, and this decision is made far less often than it should be. In our experience, sunk cost reasoning keeps organizations investing in programmes that have lost their business rationale, their executive sponsorship, or their viable path to delivery. The right framework for this decision is forward-looking: given what we know now about the remaining cost and timeline to completion, and given the current state of the business case, would we approve this project today? If the answer is no, cancellation or fundamental restructuring is a legitimate and often correct decision. The cost of cancelling a troubled project is almost always lower than the cost of completing it badly.

How often should a formal project health review be conducted on a multi-year programme?

On programmes longer than twelve months, a formal independent health review — conducted by someone outside the immediate delivery team — should occur at least every six months and at every major phase gate. An internal PMO review does not substitute for an independent assessment; teams that are close to the work have too much investment in the current trajectory to assess it objectively. The health review should examine schedule integrity, scope management, stakeholder engagement, risk profile, and financial performance against plan. It should produce a written output that goes to the steering committee, not just to the programme director.

Ten Early Warning Signs Your Project Is in Trouble (Before It Becomes a Crisis)

Most senior operations directors, CFOs, and VPs of IT have experienced at least one project that failed visibly but showed clear warning signs weeks or months before the crisis became undeniable. This post provides a structured, specific framework for detecting those signals early — and the interventions that work at each stage before the cost of recovery compounds.