The warning signs of programme failure can emerge whilst the dashboard is still green. The latest report describes progress, the steering group has met and the completion date remains on target.
Yet the sponsor is becoming uneasy. Milestones have moved. Decisions return to meetings without being resolved. People describe how busy they are, but struggle to explain detailed progress. Reassurance in formal reviews gives way to concern in private conversations.
That unease is a reason to investigate. It does not prove the programme is failing, but it can identify a gap between the reported position and the evidence needed to support it.
Start with one commitment you’re uneasy about. It might be a go-live date, a benefit the board is counting on or a supplier handover. Ask what has to be true for it to hold, then check what evidence you have. That gives you a basis for deciding whether to correct course or revisit the plan.
Why programme failure risks can remain hidden
Programme reporting can lag behind delivery reality for understandable reasons.
Individual workstreams may be making progress without testing whether their outputs fit together. A delayed milestone may be moved while the overall completion date stays fixed. Completion percentages may count finished tasks without exposing the unresolved dependencies that determine whether anything can go live.
People may also hesitate to escalate a concern they cannot yet prove. A delivery manager sees capacity becoming stretched. A technical lead doubts an integration assumption. Operations questions whether support arrangements will be ready. Each concern appears manageable in isolation, so none prompts a wider decision.
The sponsor receives a consolidated report that smooths those differences into a single status.
Optimism can contribute too. Teams believe they can recover the time. Suppliers expect the next release to resolve outstanding issues. Leaders are reluctant to revisit a commitment on which other plans depend.
A programme can therefore continue reporting confidence while the basis for that confidence weakens. The useful question is what evidence supports the remaining commitments, including the work required to turn completed activity into a usable outcome.
Recognise the early warning signs of programme failure
A missed milestone does not automatically require a programme reset. Complex delivery involves uncertainty, and effective teams resolve problems throughout the work.
Patterns are more revealing than isolated events. The same issue appears in successive reports without a decision. Estimates change repeatedly. Delivery depends on exceptional effort from a few people. Scope grows while the consequences for time, cost and benefit remain unclear.
Other warning signs sit beyond the immediate delivery plan. Testing is compressed to protect a date. Adoption work is deferred because the system is not ready. Operational teams cannot explain how they will support the result. Customers experience disruption that does not appear in the programme dashboard.
Conflicting accounts also matter. If a supplier describes an output as complete while the receiving team says it cannot be accepted, the difference needs resolving. Another progress meeting will help only if it establishes what completion means and who can judge it.
Choose a specific commitment to examine: a release date, a claimed benefit or an important dependency. Ask what would need to be true for that commitment to hold, and what evidence shows that those conditions exist.
Recover the purpose before rewriting the plan
When confidence weakens, the temptation is to request a revised schedule immediately. That can produce a more detailed account of work whose purpose has become unclear.
First, return to the business problem. What was the programme commissioned to achieve? Which outcomes matter most now? What has changed since approval? Which commitments remain essential, and which have accumulated along the way?
A programme intended to simplify customer onboarding may have expanded into a wider platform replacement. A change designed to improve service reliability may now be measured mainly through process completion. A technically impressive delivery may leave the original customer problem unresolved.
This is the risk explored in The Programme Ate the Purpose. Recovery needs enough clarity about the intended outcome to judge which work still deserves priority.
That clarity also creates choices. Some scope may be deferred. A benefit may be achievable through a narrower release. An assumption may need testing before further investment. Leaders can assess those options only when they agree what the programme must accomplish.
Establish what is actually deliverable
A credible recovery decision needs a shared account of the present position.
Identify what has been completed, what has been accepted and what can be demonstrated in a realistic setting. These are different questions. An output can exist without meeting the receiving team’s requirements, and an accepted component can still depend on unfinished work before it becomes usable.
Examine the remaining dependencies, available capacity and operational requirements. Include data, integration, testing, training and support where they affect the next outcome. Record important uncertainties explicitly so they can be resolved or accounted for in the decision.
Consider an illustrative example of a business implementing a new customer service platform. Reports describe substantial completion across configuration and development. A walkthrough with service managers reveals unresolved data migration, an untested connection to another system and no agreed support arrangements.
The business has completed valuable work. It cannot yet support the planned launch with the evidence available.
The sponsor takes the full launch off the table and makes a one-team release conditional on a migration rehearsal, a successful end-to-end integration test and an agreed support rota. The service manager decides whether the team is ready to handle live enquiries.
Give the sponsor authority to act
To regain control of a programme, leaders need decisions to be made by people with the authority to make them. A clearer report has limited value while unresolved priorities and commitments remain outside the decision-maker’s control.
If several functions issue competing instructions, a recovery plan will inherit the conflict. If the sponsor cannot change scope or commitments, escalation may expose a problem without creating a route to resolve it.
Clarify who owns the recovery decision, who can approve changes and how disputed priorities will be settled. Give teams a clear way to raise material evidence, including evidence that challenges the agreed plan.
The leadership team also needs to respond constructively when concerns emerge. Asking for early escalation while criticising every change in forecast makes the reporting less useful. Teams should be expected to explain the issue, its consequences and the options available. Leaders should then make or assign the decision.
Keep the arrangements proportionate. A meeting should resolve a dependency, support a decision or verify an outcome. Additional reporting needs a clear purpose if it is to justify the delivery time it consumes.
Choose a recovery route the evidence supports
Once purpose, delivery reality and authority are clearer, leaders can choose a route.
Continue with targeted correction where the core plan remains credible and a bounded problem can be resolved. The correction needs an owner, a defined result and a review point.
Reset scope, sequence or timing where the intended outcome remains valuable but current commitments no longer reflect the work. Make the consequences explicit, including benefits deferred and customer expectations that need changing.
Pause a defined part where a critical uncertainty must be resolved before further commitment. Set out what evidence is needed, who will obtain it and when the decision will be revisited. A pause without those conditions can become another form of drift.
Stop or replace the programme where the case for continuing no longer holds. Account for essential services, work worth retaining and any transition required. Expenditure already incurred explains the history; it does not establish the value of the next commitment.
Each route carries consequences. Compare the cost and disruption of changing with the risk of continuing under assumptions that no longer look credible.
Test the revised direction through real delivery
A recovery plan becomes useful when it changes what happens next and provides evidence that the change is working.
Select the next meaningful outcome. Define what acceptance involves and who will judge it. Assign responsibility for its critical dependencies and establish a review point at which leaders can assess the result.
The test should address the main uncertainty.
- If integration is the concern, completing another standalone component will provide little reassurance.
- If adoption is doubtful, a technical demonstration alone will not show whether frontline teams can use the result.
- If capacity is the constraint, the test needs a delivery commitment that reflects the people actually available.
For the customer service platform, the next outcome is a limited group handling real enquiries with migrated data, working integration and agreed support. That would test more of the launch conditions than another percentage-complete report.
Agree in advance what would trigger another decision. A missed acceptance criterion, an unresolved dependency or evidence of unacceptable customer disruption should have a clear route back to the accountable leader.
Recovery may take time. The next outcome should demonstrate whether the revised direction is credible enough to justify the following commitment.
Act on programme failure risks while choices remain
Regaining control can begin with a focused examination of one doubtful commitment. It does not require a review of every workstream or a declaration that the entire programme has failed.
Ask what the commitment depends on, inspect the relevant evidence and establish what remains uncertain. Then decide whether the response should be a targeted correction or a wider change.
Through Oak CORE, Mark Conway helps leaders examine delivery reality, reconcile conflicting accounts and make practical decisions about recovery. An independent view can be useful when the same conversations keep returning, confidence is weakening or internal teams struggle to agree what the evidence means.
If a date, benefit or handover no longer looks credible, bring it to an Oak CORE Fit Conversation. We’ll look at what needs testing first and whether the issue is clear enough for you to act on, warrants a focused Check-Up, or needs a different kind of support.