The first 48 hours of a programme recovery

The call

The brief is always the same. "The programme is RED. The previous PM has left. We need someone who can stabilise it." What they don't say — what they can't say, because they don't know — is which structural failures created the RED status in the first place.

The assumption is always that the problem was the PM. Replace the PM, programme recovers. It almost never works that way. The PM left because the structure was broken. Replacing them without fixing the structure gives the next person the same impossible job.

I've walked into enough of these to have a pattern. Not a methodology — recovery doesn't follow methodologies. A pattern. A sequence of things I look for in a specific order, because the order matters.

Hour 0–4: Don't touch anything

The first instinct — everyone's first instinct — is to act. Call a meeting. Request a status report. Set up a war room. Demonstrate momentum. This is wrong.

The programme has been in crisis for weeks or months before you arrived. Four more hours of observation won't make it worse. Four hours of premature action absolutely will, because you'll be acting on the narrative that was constructed to explain the crisis, not on the structural reality that caused it.

The first thing to understand about a programme recovery is that the story you've been told is not the story that happened.

In the first four hours, I read. Steering committee minutes from the last six months. The risk register. The last three status reports. The project plan — not the current one, the original one, and every revision between. I'm not reading for content. I'm reading for drift. Where did the plan change? Who authorised the change? Was it a conscious decision or did reality simply overtake the documentation?

I'm also looking for what's missing. If the risk register has 47 items and they're all rated Medium, that tells me more than any status report. If the steering committee minutes record decisions but not the discussion that led to them, I know the governance is performative. If the original plan has been revised four times and each revision simply moved the dates forward without changing the scope or approach, I know nobody has confronted the structural issue.

Hour 4–12: Find the authority map

Every programme in crisis has an Authority Vacuum. Every single one. The question is where it sits and who filled it by default.

I ask three questions in the first round of conversations:

1. Who makes the decision if there's a conflict between scope and budget? If the answer involves the word "escalate" without naming a person, that's the vacuum.
2. Who can tell the vendor "no" and make it stick? If the answer is "the PM" and the PM reports to someone who reports to the steering committee, the PM doesn't have the authority to enforce. They have the accountability without the power.
3. Who owns the risk register — not who updates it, who acts on it? If nobody can answer this without checking, the risk register is theatre.

These three questions surface the authority structure faster than any RACI matrix. A RACI tells you what was designed. These questions tell you what actually operates.

On one programme, I discovered that the PM had been making commercial decisions — approving change requests, agreeing to scope variations — because the contract manager role had been "temporarily" absorbed into the PM role eight months earlier when the contract manager went on leave. Nobody backfilled. The PM had no commercial training and no delegated financial authority. Every decision they'd made was technically ultra vires. The vendor knew this. The PM didn't.

Hour 12–24: Test the governance

By hour twelve, I have a hypothesis about where the authority gaps are. Now I need to test whether the governance framework is capable of closing them — or whether the governance itself is the problem.

Compliance Theatre is the pattern that distinguishes a programme with governance problems from a programme whose governance is the problem.

The test is simple. I pick the three highest-rated risks in the register and ask the project team: "What action was taken on these in the last month?" If the answer is "they were reviewed at the risk meeting," I ask "What changed as a result of the review?" If nothing changed — if the same risks have sat at the same rating with the same mitigations for three consecutive months — the governance is performative. The artefacts exist. The governance doesn't.

The presence of compliance theatre changes the recovery approach fundamentally. If the governance works but the programme has structural gaps, you fix the gaps within the existing framework. If the governance is theatre, you have to rebuild the governance before you can fix anything else — because you have no mechanism for making and enforcing decisions.

Hour 24–36: Map the information architecture

By the second day, I'm looking for Information Fog. Not missing information — programmes in crisis always have too much information, not too little. The fog is the inability to find the right information at the right time to make a decision.

I ask the project team to find three things:

1. The decision record for the last major scope change
2. The current version of the requirements specification
3. The vendor's last formal response to a defect

If all three come back within an hour from the same system, the information architecture is functional. If they come back from three different people's email inboxes over two days, the programme doesn't have an information problem — it has a governance problem, because decisions aren't being captured in a way that makes them findable and enforceable.

Information Fog is insidious because it looks like a tooling problem. "We need a better document management system." "We need to consolidate our SharePoint sites." No. You need to decide what information has governance effect and ensure that information — and only that information — flows through channels designed to support decisions. Everything else is filing.

Hour 36–48: The structural diagnosis

By hour 36, I have enough to construct the structural diagnosis. Not the recovery plan — that comes later. The diagnosis. What patterns are active, how they interact, and which one to fix first.

The diagnosis always has the same structure:

1. Which authority gaps exist and who filled them by default? This determines whether the fix is a governance reset (redesign the roles) or a personnel intervention (backfill a vacancy).
2. Is the governance framework capable of supporting the recovery? If yes, work within it. If no, the first action is a governance reset — not a plan revision.
3. Can the team find, share, and act on the information they need? If not, the information architecture fix must happen in parallel with the governance fix, because you can't make good decisions on bad information.

Most programmes in crisis have all three patterns active simultaneously. That's not a coincidence — they form a cascade. The Authority Vacuum creates governance gaps. Compliance Theatre fills those gaps with artefacts instead of control. Information Fog prevents anyone from seeing the full picture clearly enough to intervene. Each pattern reinforces the others.

What happens after 48 hours

The structural diagnosis goes to the steering committee. Not a recovery plan — a diagnosis. "Here are the three structural patterns that created the RED status. Here is the cascade. Here is the order in which they need to be addressed."

This is the conversation most recovery PMs skip, because it's uncomfortable. It names structural failures that the governance was supposed to prevent. It implicitly questions the steering committee's oversight. But it's the only conversation that leads to a recovery that sticks, because it forces the sponsor to confront the cause, not just the symptoms.

The recovery plan follows the diagnosis. It has three phases:

1. Stabilise — close the authority gaps, establish decision-making channels, stop the bleeding
2. Reset — rebuild the governance framework, rebaseline the plan against the structural reality, reset vendor expectations
3. Deliver — execute the rebaselined plan within the new governance framework

Most organisations want to jump to phase 3. The ones that do repeat the cycle. The ones that invest in phases 1 and 2 — the unglamorous structural work — are the ones that recover.

The principle

Programme recovery isn't a planning problem. It's a diagnostic problem. The programme didn't fail because the plan was wrong — it failed because the structure couldn't support the plan. Fix the structure first. The plan follows.

And if you're the person walking into a RED programme on day one, resist the pressure to act before you understand. The first 48 hours are not for heroics. They're for pattern recognition. Find the authority vacuum. Test the governance. Map the information architecture. Everything else flows from there.

This article contributes risks V1, V5, G1-G6, G10, K1-K4, and C4 to the practitioner's risk taxonomy.