The wrong instinct
When a transformation programme is visibly in trouble — behind schedule, over budget, or both — the pressure to act immediately is intense. The steering committee wants action. The programme board wants a revised plan. The business units affected by delays are escalating. The instinct is to add resources, compress timelines, and accelerate.
This is almost always the wrong response. Programmes that are in trouble are usually in trouble for structural reasons that adding resources does not fix. More people on a programme with an unclear scope will produce more confusion, not more velocity. A compressed timeline on a programme with unresolved dependencies will produce more rework, not faster delivery.
The diagnostic sprint
The right first move is a diagnostic sprint: a structured, time-boxed exercise — typically three to four weeks — that identifies root causes rather than symptoms. The output is not a revised plan. It is an honest assessment of what is actually wrong and what it will take to fix it.
A diagnostic sprint has three components. The first is document review: programme plan, RAID log, change request log, steering committee papers, and budget tracking. These documents tell you the official story of what has happened. They also reveal what has been avoided — the risks that have been escalating without resolution, the dependencies that have been consistently amber for six months, the budget variances that have been explained away.
The second component is structured interviews. Not the programme team — they will tell you what they think you want to hear, or what they have been telling the steering committee. The interviews that matter are with the business stakeholders who were supposed to benefit from the programme: the finance director who was promised a faster close, the operations manager whose team is supposed to use the new system. They will tell you what the programme team cannot.
The third component is a technical assessment. This is not a full code review or architecture audit. It is a focused assessment of the specific technical risks that the programme's own RAID log has been flagging without resolution: the data migration that has never run clean, the integration that works in the test environment but has not been validated against production volumes, the performance test that has been deferred three times.
The four root causes
The four root causes that account for the majority of stalled programmes are: scope that was never properly defined, dependencies that were never properly managed, decisions that were deferred until they became crises, and a programme team that lost the confidence of the business.
Undefined scope manifests as a change request log that grows faster than it closes, a business case that no longer bears any relationship to what is being built, and a programme team that cannot give a confident answer to the question 'what will this system do when it goes live?'
Unmanaged dependencies manifest as a RAID log full of amber dependencies that have been amber for months, a schedule that has been revised repeatedly without resolving the underlying dependency issues, and integration workstreams that are blocked waiting for decisions from third parties.
Deferred decisions manifest as scope gaps — areas of the programme where nobody has agreed on the answer and everyone is hoping the question will go away. They do not go away. They surface at the worst possible time: during system integration testing, during user acceptance testing, or during go-live.
Loss of business confidence manifests as disengaged business stakeholders who have stopped attending programme reviews, a business change team that is going through the motions without believing in the programme, and a steering committee that has started asking questions it stopped asking six months ago.
The recovery plan
The recovery plan that comes out of the diagnostic sprint needs to address root causes, not symptoms. For scope problems, that means a reset workshop with the programme sponsor and business stakeholders to redefine and lock scope — followed by a formal change control process with teeth. For dependency problems, it means escalating unresolved dependencies to programme board level and getting decisions made. For deferred decisions, it means a decision log with owners and deadlines reviewed weekly by the programme director.
For programmes that have lost business confidence, the recovery plan needs to start with honesty. The steering committee needs to hear an accurate assessment of where the programme is — not an optimistic reforecast. Programmes that have been in trouble for months have usually been accompanied by optimistic reporting that has eroded trust. Rebuilding that trust starts with telling the truth about the current state, even when the current state is worse than the steering committee expected.