By the time someone calls in external help for a failing programme, the situation is usually further gone than the official status reports suggest. Green-amber-red ratings have been amber for longer than anyone will admit. The schedule has been rebaselined at least once. Key people have started leaving.
The first 30 days aren't about fixing the programme. They're about understanding it well enough to know whether it can be fixed, and if so, how.
Week one: diagnose, don't fix
The instinct when arriving on a programme in trouble is to start making changes immediately. Resist it. Premature action based on an incomplete picture makes things worse.
Spend the first week in listening mode. Talk to engineers, testers, product owners, architects, delivery managers — not as a group, individually. Ask the same questions: What's actually broken? What did we know six months ago that we're pretending we don't know now? Where is the real risk? What would you do if you were in charge?
You'll hear the same themes repeatedly. The things people tell you in one-to-ones but won't say in a programme review are usually the things that matter most. Scope that keeps growing without timeline adjustment. A technical dependency that nobody wanted to acknowledge. A key individual who's a single point of failure and is already looking for a new job.
Document what you find. Not for a report — for your own clarity. By the end of week one you should have a clear picture of the three to five things that are actually causing the programme to fail.
Week two: stop the bleeding
Before you can recover a programme, you have to stabilise it. This usually means making some short-term decisions that feel uncomfortable.
Descope aggressively. Most failing programmes are failing because scope has expanded beyond what was ever achievable in the original timeline. Have the honest conversation about what must ship versus what was nice to have. This is a stakeholder conversation, not an engineering one, but engineering needs to be in the room with data.
Address the critical path. What is the one thing that, if it slips further, makes everything else irrelevant? Put your best people on it and remove everything else from their plate.
Fix the escalation path. On distressed programmes, problems often don't surface until they're critical because people are afraid of the reaction. Create a low-friction way for engineers to flag blockers early and respond to those flags without blame. This won't fix the programme but it prevents it from getting worse.
Week three: communicate honestly
This is the week that separates recoverable programmes from unrecoverable ones. Not because of the technical situation — because of whether leadership can handle an honest assessment.
Produce a clear-eyed status that says what is actually true: what will be delivered, when, with what level of confidence, and what the risks are. Not a political document. Not the version that makes people feel better about what's happened. The real version.
If the honest answer is that the original scope cannot be delivered in the original timeframe, say so. Stakeholders can handle bad news delivered clearly and early. What they cannot handle — and what destroys credibility permanently — is bad news that comes out at the last minute wrapped in spin.
Week four: build the recovery plan
A recovery plan is not a revised project plan. A revised project plan takes the same approach and adds more time. A recovery plan changes the approach.
What will you do differently? If testing is a bottleneck, how are you automating it? If deployments are slow, what's the pipeline work needed? If the architecture is blocking parallel development, what's the decoupling strategy? The plan needs to address the root causes identified in week one, not just extend the timeline.
Sequence for early wins. The team is demoralised. Leadership is anxious. Shipping something — anything — that demonstrates progress changes the atmosphere on a programme. Find the work that can be completed and delivered in the next two to three weeks and prioritise it.
What recovery actually requires
Technical competence is necessary but not sufficient. Programme recovery requires stakeholder management, team psychology, and honest communication in equal measure. The hardest part is almost always the conversations that should have happened six months earlier but didn't.
Not every programme can be recovered. Sometimes the right answer, reached with clear eyes after a proper diagnosis, is to recommend stopping. That's a legitimate outcome of a recovery assessment, and the courage to say it is worth more than any recovery plan.
Back to Insights