The programme is certainly busy. Calendars are full, the supplier sends weekly reports and a large team is completing tasks. Ask when the business will receive a usable result, though, and the answer becomes strangely complicated.
Busyness is easy to report. Progress should be possible to show.
The National Audit Office has seen this pattern repeatedly in large digital change. Its six lessons for digital transformation begin with understanding the business problem, setting realistic timescales and dealing honestly with legacy systems and data. It also warns that technology change involves people, processes and systems — not simply a new platform.
Recovery therefore starts by replacing activity with a clear decision. The aim is not to protect the original plan or find somebody to blame. It is to establish what outcome still matters and the most credible route to it.
Recognise the warning signs
Common signs include milestones repeatedly moving, scope described differently by different people, unresolved decisions and progress reported mainly as tasks completed. Costs may continue to rise while the expected business change remains distant.
Another warning sign is a plan that depends on everything going right from now on. A credible forecast should allow for known uncertainty, testing, data problems and operational preparation.
Pause new commitments
Before agreeing more scope or extending contracts, stop long enough to understand the position. This does not mean halting all work. It means avoiding decisions that reduce the remaining options while the facts are unclear.
Identify any commitments that must be made immediately and separate them from work that can wait for the reset.
Restate the outcome
Write down what the programme must change for customers, employees or operations. Keep it specific enough to test. If leaders cannot agree on the intended outcome, the delivery team cannot make sensible trade-offs.
Some original objectives may no longer matter. Remove them rather than carrying old promises into a revised plan.
Establish the real position
Review working software, data, integrations, security, supplier obligations, unresolved defects and operational readiness. Ask for demonstrations and records rather than relying only on status reports.
The review should distinguish work that is complete, work that needs correction and work that has not started. It should also identify decisions the team is waiting for.
Choose what to keep, change or stop
Recovery rarely means discarding everything. Some work may be sound but sequenced badly. Other parts may be too complex, based on weak assumptions or no longer worth the cost.
Assess each major part against the outcome, remaining cost, risk and dependency. Then make explicit choices about what stays in the plan.
Put one person in charge of the whole decision
Programme management coordinates work, but recovery also needs senior technology judgement. One named leader should own the overall recommendation, resolve design and supplier conflicts and explain the position to the board.
That person must be able to challenge both internal preferences and supplier claims.
Build a plan around evidence
Use milestones that demonstrate a working result: a completed data migration test, a live process handled end to end or a recovery exercise passed. Evidence-based milestones give leaders a clearer view than percentages and traffic-light reports.
The revised plan should include cost ranges, decision dates, named owners and conditions that would trigger another review.
Reset governance and reporting
Board reporting should state what changed, what decision is needed, what evidence supports the forecast and where confidence remains low. It should not hide uncertainty behind detailed delivery language.
A programme can recover when leadership is prepared to change the plan in response to evidence. Asking the same structure to work harder usually extends the problem.