A project rarely announces that it is in trouble. It slips quietly: a slipped submittal here, an approval that takes a fortnight longer than planned, a reforecast that keeps promising the time will be made up "in the next phase." Each on its own looks survivable. Together, they move the finish date — and by the time a milestone is formally missed, the slippage is often months deep.
Recovering that situation is a discipline in its own right. It is not about working the team harder or adding people in a panic. It is about diagnosing what actually went wrong, rebuilding a plan that reflects reality, and re-imposing the controls that let you steer. Here is how a structured recovery works.
The warning signs, before the milestone slips
The projects that recover well are the ones that catch the drift early. The signals are usually visible long before a date is officially missed:
- Progress is reported as a percentage rather than against defined, verifiable deliverables.
- The forecast completion date never moves, even as tasks fall behind — a sign the plan has stopped reflecting reality.
- Float on the critical path is quietly disappearing week after week.
- The same risks appear in the register month after month with no owner and no action.
- Meetings shift from planning the work to explaining the delay.
Why the instinctive reactions make it worse
Under pressure, the common responses often deepen the hole:
- Throwing people at it. Adding resource to a late, poorly understood project usually slows it further — new people need direction the team can't spare.
- Crashing everything. Accelerating tasks that aren't on the critical path spends money without moving the finish date.
- Hero mode. Relying on a few individuals working unsustainable hours buys a few weeks and burns the people you most need for the rest of the project.
- Optimistic reforecasting. Assuming lost time will be recovered later, without a concrete plan for how, simply moves the reckoning downstream.
Recovery starts by admitting where the project actually is — not where the plan says it should be.
A structured recovery
1. Diagnose honestly
Establish the true status against verifiable deliverables, and separate the causes of delay from the symptoms. A slipping date is a symptom; late design, an unresolved interface or a decision stuck in approval is a cause. Fixing symptoms achieves nothing.
2. Re-baseline to reality
A plan the team no longer believes is worse than no plan. Build a recovery baseline that is achievable, agreed, and owned — even if it confirms an uncomfortable new completion date. Credibility is more valuable than optimism.
3. Protect the critical path
Focus effort and money where they actually move the finish date. Everything else is secondary until the critical path is stabilised.
4. Fix root causes, not symptoms
Clear the decisions, approvals and interfaces that are generating the delay. Often the bottleneck sits outside the delivery team entirely — with a client decision or a third party — and no amount of internal effort will move it.
5. Restore controls and cadence
Re-establish a short, disciplined reporting rhythm: current status, forecast, risks, decisions needed. Recovery holds only if the controls that were missing during the drift are put back in place and kept.
6. Manage stakeholders deliberately
A credible, evidenced recovery plan — delivered before the client discovers the slippage themselves — buys trust and room to work. Silence spends both.
An independent reviewer sees what a team inside the pressure cannot, and can deliver hard messages to stakeholders without the internal politics. If the project matters and the internal reforecasts keep proving wrong, an external recovery review usually pays for itself several times over.
Recovery is controls under pressure
Every recovery is, at heart, the reinstatement of the disciplines that should have been there all along: a realistic baseline, honest progress measurement, critical-path focus, and a steady reporting cadence. That is also why the same evidence trail matters if the delay later becomes a claim — see our note on what forensic delay analysis actually involves. The projects that never need recovery are simply the ones that kept those disciplines from day one.