Project Triage and Recovery

Two different problems wearing the same name

"The project's in trouble" gets used for two situations that need completely different responses, and mixing them up is the single most common way a recovery goes wrong before it's even started.

A struggling project is behind or over budget, but the fundamentals hold: people broadly agree on what it's for, the team can tell you what's blocking them, and the sponsor still believes it's worth finishing. It needs better management — tighter scope, clearer priorities, a harder look at the plan. What it doesn't need is someone new coming in and rebuilding it from scratch.

A failing project has lost one of those fundamentals, not just its schedule. Nobody can give you the same answer twice when you ask what "done" looks like. The team has stopped raising blockers because raising them stopped changing anything. The sponsor is quietly hedging — still funding it, but no longer defending it in the room. That's not a scheduling problem. That's a trust and alignment problem wearing a scheduling costume, and a replan won't touch it.

The fastest way to tell which one you're looking at: ask three different people, separately, what success looks like. If you get three compatible answers, it's struggling. If you get three different answers, or three confident answers that quietly contradict each other, it's failing — and the work starts there, not with the plan.

What to look at first

What project triage actually is covers the seven questions I use to get the diagnosis fast — I won't repeat them here. What matters for recovery specifically is the order you act on what triage tells you, because doing things in the wrong sequence is its own way to fail.

Triage nearly always surfaces more than one problem. A capability gap here, a stakeholder disagreement there, a deadline nobody's checked is real. The instinct is to fix the biggest one first. Resist it. Fix the one that's actively getting worse first — the thing that, left alone for two more weeks, forecloses your other options. A capability gap doesn't get worse on its own. A stakeholder relationship that's quietly souring does, every week it's ignored.

That ordering — urgency of decay, not size of problem — is the single biggest difference between a recovery plan that actually works and one that reads well in a steering committee deck and changes nothing.

The first fortnight

Concretely, in roughly this order:

• Contain what's actively deteriorating. Not fix — contain. If a key relationship is souring, get in front of it this week, even with an imperfect answer. A late, honest conversation beats a well-timed one that never happens because you were still preparing it.
• Get one page of shared truth. Not a status report — those are usually part of the problem, written to manage perception rather than describe reality. One page, plain language, that the sponsor and the delivery team would both sign their name to. If they can't agree on that one page, that's the actual finding, and it goes to the top of the list.
• Name the decision that's been avoided. Every failing programme has one — a scope call, a resourcing call, a "do we actually need this by that date" call — that's been deferred because nobody with the authority to make it wanted to own the consequences. Recovery doesn't start until that decision gets made, even if it's the wrong one. An avoided decision is worse than a bad one, because at least a bad decision can be corrected against evidence.
• Reset the reporting, not just the plan. If the old status reporting produced the trust gap you're now fixing, keep it and just changing the plan underneath it won't hold. The one page of shared truth from step two becomes the new reporting artefact, not a one-off.

None of this is the recovery plan itself. It's what has to be true before a recovery plan is worth writing. Skip straight to replanning — the instinct almost everyone has under pressure — and you get a detailed, well-resourced plan for solving last month's problem.

Replan only once the diagnosis holds

A recovery plan is a normal plan, with one difference: it has to explicitly account for whatever triage found, not just route around it. If the real problem was a capability gap, the plan needs the capability in it, not just tighter milestones for people who still don't have what they need. If the real problem was that nobody agreed what "done" meant, the plan needs that definition written down and signed off before a single task gets rescheduled.

A recovery plan that could have been written before the diagnosis is a sign the diagnosis didn't actually change anything — which usually means it wasn't trusted, or wasn't done properly in the first place.

What actually derails a recovery

A few patterns show up often enough that they're worth naming directly, because each one looks like progress from the inside while it's happening.

• Replacing the plan instead of the diagnosis. A new Gantt chart, a new tool, a new cadence of meetings — all visible, all defensible, none of them touching why the last plan didn't hold. If the recovery plan doesn't name what was actually wrong, it's redecoration.
• Treating governance as the fix. More steering committees, more sign-offs, more reporting layers. This is what "help" turns into when a project gets marked red without a real diagnosis underneath it — and it makes a trust problem worse, because it tells the delivery team their judgement is the thing under review, not the plan.
• Confusing a quiet week with recovery. The first two weeks after a serious intervention are almost always calmer — everyone's paying attention, nobody wants to be the one who breaks the truce. That calm is the intervention working, not the programme being fixed. Declaring victory here is the single most common way a recovery gets re-opened a month later.
• Solving it alone, in a document. A brilliant diagnosis that only one person believes changes nothing. The one page of shared truth only does its job once the sponsor and the delivery team have actually sat with it together and agreed it's accurate — not received it as an email attachment.

What "recovered" actually means

Not "back on the original schedule." Almost nothing that's genuinely failed gets back to its original schedule, and treating that as the bar just recreates the pressure that caused the trouble in the first place.

A programme is recovered when three things are true at once, not just one of them for one good week:

• The sponsor and the delivery team would independently describe the current state the same way, without coordinating first.
• The team is raising blockers again, because raising them visibly changes something.
• The plan survives contact with a bad week. One missed milestone doesn't trigger a return to the pre-recovery pattern — panic, blame, a new plan nobody trusts.

That third one is the real test. Any plan looks recovered during a good stretch. Whether the underlying trust and clarity actually got fixed only shows up the first time something goes wrong again — and something always does.

Handing over

Recovery is a bounded engagement, not a permanent fixture. The job isn't done when the programme is stable with me in the room — it's done when it's stable without me. That means the one page of shared truth has to survive my exit, the decision-making I unstuck has to keep happening without me chasing it, and the team needs to own the plan, not just execute it. A recovery that only holds while the recovery consultant is watching hasn't actually recovered anything; it's just been paused.

Worked examples

What Is Project Triage? covers the diagnostic step in full — the seven questions, and the difference between triage and a replan. Why I Built the Triage Tool is the origin story: why the first hour of a struggling project is the one that actually matters, and what building a tool to compress it taught me about the work itself.

Three more on specific ways recovery actually derails: I Have Never Seen a Programme Go From Ninety to a Hundred, on what "90% complete" is usually hiding; We Added People and It Got Slower, on why headcount isn't the fix it looks like; and The Build Was Fine. The Decisions Weren't., on the failure mode this guide's "what actually derails a recovery" section describes in practice.

Get in touch

I'm currently taking on contract and advisory work in the UK, for programmes that are behind, broken, or both. The best starting point is LinkedIn, or if you want a first read on where a struggling project actually stands before we talk, the free project triage tool walks through the same seven questions this guide builds on.