Program delivery
Reset a stalled technology program without restarting everything
Assess a delayed transformation program, separate usable work from unresolved assumptions and create a credible recovery plan with clear decision gates.
At a glance
- Separate built, tested and accepted work.
- Expose the decisions and dependencies behind the delays.
- Recover through a useful release with visible evidence.
A slipping program does not always need a new platform, another vendor or a complete restart. It needs a clear account of what is working, what is blocked and which decisions have been deferred. Recovery starts by making the current state inspectable without turning the review into an exercise in blame.
The working method
- 01
Inspect
Establish the delivered and unaccepted work.
- 02
Reset
Agree scope, decisions and actual capacity.
- 03
Deliver
Prove a complete, supportable business journey.
Part 01
Establish what actually exists
Review the delivered product, environments, integrations, data and support arrangements. Ask for demonstrations of complete business journeys, not progress percentages. Distinguish code that has been written, functionality that has been tested and work that an operating owner has accepted.
Build one view of scope, commitments, defects, dependencies and spend. Record the source and confidence of each statement. If two teams disagree about whether a feature is complete, capture the missing acceptance decision rather than averaging their reports into a reassuring status.
Part 02
Find the decisions behind the delays
Recurring delivery problems often contain unresolved choices: who owns a source record, which process will change, what a release must include or who can accept a compromise. Separate these from technical defects. A defect needs a fix; an ownership dispute needs an accountable decision.
Identify external dependencies such as procurement, access, migration inputs and third-party readiness. Assign a decision owner and a date for each blocker. Make the consequence of no decision explicit so the program can stop pretending that every dependency will resolve itself.
| Work category | Recovery question | Possible response |
|---|---|---|
| Accepted and operating | What must remain stable? | Protect and support it |
| Built but unproven | What evidence is missing? | Test a complete journey |
| Blocked | Which decision or dependency is unresolved? | Assign an accountable owner |
| No longer justified | Does the business still need it? | Remove or defer with a recorded decision |
Swipe the table to view all columns →
Part 03
Define the smallest useful recovery release
Select a bounded business outcome that can be delivered and supported. Preserve useful work where the evidence supports it. Reduce scope around the outcome rather than removing testing, training or recovery arrangements to meet an unchanged date.
Write the acceptance cases with the operating team. Include exceptions and data reconciliation. Agree what remains manual and for how long. A limited release can be a sensible recovery step when its constraints are visible and its users know how to work within them.
Part 04
Replan around capacity and dependencies
Use the actual team's capacity and the known dependency sequence. Allow for defect correction and operational demands. Show ranges where uncertainty is material, and identify what evidence would narrow them. A new date without a changed delivery model is usually another promise built on the same assumptions.
Set a short decision cadence with a concise record of progress, risks and required decisions. Escalate issues to the person who can resolve them. Avoid adding reporting layers that consume the same specialists needed to complete the work.
Part 05
Make recovery visible in the work
Look for accepted journeys, resolved blockers, reconciled data and an operating team ready to take ownership. Report these alongside the remaining gaps. A status color can summarize evidence, but it cannot replace it.
At the next gate, decide whether to continue, change scope or stop. Keep the decision grounded in business usefulness and remaining exposure, rather than the desire to defend sunk effort. A credible reset restores the ability to make choices as much as the ability to deliver features.
- A factual inventory of delivered and unaccepted work.
- A decision log with accountable owners.
- A useful recovery release with explicit constraints.
- A capacity-based plan and an evidence-led review gate.
