A stalled digital programme rarely stops in one visible moment. Delivery continues, forecasts become less credible, decisions accumulate and the same work remains nearly complete for several reporting periods. People lose confidence before the board formally accepts that the programme needs a different course.

Recovery should not begin with a new supplier, a motivational relaunch or an assumption that everything built so far is worthless. It begins with a short, independent assessment of what is true, what remains valuable and which conditions must change before further spending is justified.

Stabilise before promising recovery

Protect live services, client obligations, data and access first. Identify whether the programme has introduced security, privacy, resilience, contractual or operational exposure. Ask appropriate specialists to address urgent concerns.

Pause irreversible or low-confidence work where delay is safer than continuation. This does not require stopping every activity. Necessary support, evidence gathering and completion of a genuinely safe deliverable may continue under explicit authority.

Secure the working record: contracts, plans, repositories, environments, designs, research, content, data, decisions, risks, invoices and supplier correspondence. Confirm client-authorised access. Recovery becomes much harder when the organisation depends on one individual or a departing supplier to explain the present state.

Communicate that an assessment is underway, what remains operational and when decisions will be made. Avoid announcing a turnaround before the evidence exists.

Reconstruct the original case

Find the investment case, approval conditions and any later changes. Extract the intended outcomes, baseline, cost, timeframe, assumptions, dependencies, risks and benefit owners.

Vague outcomes such as “improved digital experience” cannot guide recovery. Translate them into observable service or commercial conditions, but do not retrofit targets merely to make the programme appear successful. If the original baseline was absent, establish a defensible current baseline and record that limitation.

Ask whether the need still exists. Market conditions, organisational strategy or client behaviour may have changed since approval. A recovery programme should not rescue a solution to a problem that has disappeared.

The related article on why digital programmes fail helps separate symptoms from structural causes.

Establish what has actually been delivered

Replace percentage-complete reporting with working evidence. Inspect usable software, configured environments, migrated content, integrations, tests, research, decisions and operational capability.

For each element, determine:

  • whether it meets an agreed need;
  • quality and outstanding defects;
  • security, accessibility and performance evidence;
  • dependencies and operating cost;
  • ownership and ability to change it;
  • work needed to make it safe and useful;
  • whether retaining it is better than replacement.

A sound architecture can coexist with poor governance or an obsolete specification. A partially built asset may be valuable, and sunk cost alone cannot justify preserving it. Make the judgement component by component.

Reconcile spend, committed liabilities and forecast-to-complete. Include internal effort, licences, support, exit and transition. Avoid comparing a revised scope with the original budget as if the outputs remained identical.

Diagnose the system around delivery

Most stalled programmes contain interacting causes. Examine at least six areas.

Purpose: Were the problem and outcomes clear enough to make trade-offs?

Governance: Who could decide scope, cost, risk and priority? Were decisions made inside the intervention window?

Delivery: Did the team produce working evidence, manage dependencies and maintain a credible forecast?

Users and operations: Were affected people involved in research, testing and service design? Was ownership after launch defined?

Commercials: Did the contract and incentives fit the uncertainty? Could change and bad news be surfaced without immediate dispute?

Foundations: Were data, integration, content, security and internal capacity sufficient for the plan?

Use interviews, delivery artefacts and system evidence. Treat blame statements as hypotheses. Marketing, technology, the supplier and the sponsor may each hold part of the explanation.

The companion guide to warning signs of a stalling transformation can support the review, provided findings are validated in the actual programme.

Decide among recovery options

Recovery is only one possible decision. Present leaders with real alternatives:

  • continue with corrected governance and plan;
  • narrow to a coherent outcome;
  • complete or stabilise one valuable element and stop the rest;
  • change team, supplier or commercial arrangement;
  • pause until a named prerequisite exists;
  • close the programme and transition useful assets;
  • restart around a revalidated problem.

For each option, show outcome, cost range, time range, internal capacity, dependencies, risk, reversible steps and effect on existing obligations. State confidence and missing evidence.

Do not make supplier replacement the automatic answer. A capable supplier may have been working inside an unworkable governance model. Equally, a new charter cannot correct persistent inability to deliver. Judge performance against evidence and the agreement.

Make the restarted programme observably different

Confidence will not return because leaders say lessons have been learned. Show the structural changes.

Create a small steering group around the decisions the programme actually requires. Give it written authority and a route for broader stakeholder input. Replace retrospective status presentations with options, evidence and decision deadlines.

Reduce work in progress. Choose the smallest coherent outcome that matters and can be delivered safely. This may mean deferring an attractive portal, integration or feature until data, ownership or user evidence exists.

Define working demonstrations and quality evidence throughout delivery. A fast visible result can help when it solves a real problem and meets required controls. An arbitrary 30-day promise can reproduce the pressure that caused the stall.

Put the revised business case and outcome measures in place before restarting material delivery. If evidence remains weak, fund a bounded discovery or proof rather than disguising uncertainty in a full programme.

The detailed guide to restarting a stalled digital programme covers this method in more depth.

Repair relationships without erasing accountability

Speak directly with the existing supplier and affected internal teams early. Explain the assessment, protect contractual positions and allow factual response. Delayed or ambiguous involvement can turn a delivery review into a dispute about replacement.

Record what worked as well as what failed. People who raised concerns previously need to see how those concerns enter decisions now. Give practitioners genuine authority over the knowledge they own, without asking them to absorb sponsor accountability.

Do not use “psychological safety” to avoid clear performance decisions. Recovery requires both a fair diagnosis and named responsibility for future action.

Control returning ambition

Early progress often invites old scope back before the foundations have proved stable. Keep deferred items tied to explicit prerequisites and decision gates. A successful first release earns review, not automatic expansion.

Monitor outcome, quality, forecast, adoption and team conditions. Preserve the option to stop if recovery assumptions fail. Move into normal service governance only when ownership, controls and operating capacity are real.

If this situation is familiar, Distinction offers a confidential first conversation through the contact page. The useful conclusion may be that the programme can recover, needs to narrow, should pause or is better closed. A credible recovery starts by making those alternatives visible while meaningful choices still exist.