A £120 million government platform programme was eight months behind schedule.
The dashboard was still green.
That was the first problem.
The second was worse. No one could explain what “80% complete” actually meant. The programme had consumed significant funding, accumulated thousands of unresolved defects, and created three competing versions of the delivery plan.
The supplier blamed changing requirements. Internal teams blamed procurement. The programme board blamed poor reporting.
Everyone had a reason.
Nobody had control.
This is an anonymised case study of how we re-baselined the programme, restored delivery governance and moved it from political exposure to a credible execution path in 90 days.
The objective was not to pretend the programme was healthy.
The objective was to make the truth visible, stop further waste and create a plan that could survive scrutiny.
Client details, programme figures and identifying characteristics have been rounded or anonymised to protect confidentiality.
The public-sector delivery problem
The scale of the problem was not unusual.
The UK government’s State of Digital Government Review reports that public-sector organisations spent approximately £26 billion on technology in 2023. It also found that digital and technology programmes were 60% more likely to be rated red than non-technology programmes in the Government Major Projects Portfolio.
Technology programmes do not fail because public servants lack commitment.
They fail when strategy, funding, technology, suppliers, ownership and execution operate as separate systems.
That is the Execution Gap.
Problem: The platform was consuming budget without creating confidence
The platform was intended to provide a common digital backbone for multiple government services.
Its objectives were reasonable:
- Replace fragmented legacy applications.
- Improve citizen and staff journeys.
- Create a reusable data and integration layer.
- Reduce manual processing.
- Support future policy changes without rebuilding the platform each time.
The business case was strong.
The delivery model was not.
By the time we became involved:
- The programme was approximately eight months behind its approved schedule.
- Forecast costs had increased materially through change requests and extended supplier mobilisation.
- The critical-path plan had not been updated for several reporting cycles.
- Defect volumes were rising faster than the team could close them.
- Several workstreams had declared themselves “complete” without production-ready evidence.
- More than 20 governance forums were reviewing overlapping information.
- No single leader owned the end-to-end business outcome.
The programme was not merely late.
It was running without a reliable control system.
Situation: Green reporting was hiding red delivery
The programme’s monthly reporting pack showed progress through percentages.
Workstream A was 84% complete.
Workstream B was 76% complete.
The platform was 81% complete overall.
These numbers were meaningless.
They measured activity, not usable capability.
When we tested the figures against delivery evidence, the picture changed:
- Code was incomplete or not integrated.
- Test environments did not reflect the production configuration.
- Several “closed” risks had simply been transferred to another register.
- Benefits had not been linked to live service performance.
- Data migration assumptions had not been tested at operational scale.
- Business owners had not signed off the redesigned processes.
This is the classic watermelon status problem: green on the outside, red underneath.
A programme can be busy and still be failing.
Challenge: Rescue required decisions, not another review
The client had already commissioned multiple assurance reviews.
Each had produced a reasonable report.
None had changed delivery behaviour.
That distinction matters.
A programme rescue is not successful because the diagnosis is accurate. It is successful when the diagnosis changes what people do on Monday morning.
We faced five immediate challenges.
1. No shared version of the truth
The programme office, supplier and business teams each used different baselines for scope, schedule and progress.
2. Governance without authority
There were many meetings, but few decisions. Issues moved from one committee to another while the delivery teams waited.
3. Scope protection
Every workstream had a reason why its requirement was essential. The programme had accumulated features, integrations and reports that were not required for the first operational release.
4. Supplier dependency
The prime supplier controlled much of the delivery information. Internal leaders lacked sufficient technical and commercial visibility to challenge estimates or acceptance claims.
5. Political and operational risk
The platform supported services that could not simply be paused. Recovery had to happen while protecting existing operations.
Approach: Diagnose, re-baseline, then deliver
We used a three-stage recovery model.
Days 1–30: Diagnose and stabilise
The first 30 days were not about creating a new vision.
They were about stopping further deterioration.
We established a small recovery team with access to:
- Delivery plans and integrated schedules.
- Source repositories and release evidence.
- Test results and defect data.
- Supplier statements of work.
- Commercial commitments and change requests.
- Architecture decisions.
- Operational incident records.
- Business-owner acceptance criteria.
We then interviewed delivery leads without their reporting lines in the room.
Three questions produced more useful information than most steering committees:
- What is slowing delivery?
- What work is being repeated?
- What should stop immediately?
The answers exposed duplicated testing, unresolved architecture decisions and a large amount of low-value work consuming the critical path.
We paused non-essential scope.
We defined the services that could not fail.
We created a single risk and dependency view.
Most importantly, we stopped reporting percentage completion unless it could be supported by working software, test evidence or signed business acceptance.
Days 31–60: Re-baseline the programme
The second phase was uncomfortable.
The client had to accept that the original plan was no longer credible.
We created a recovery baseline built around:
- Priority services rather than platform components.
- Evidence-based milestones rather than percentage completion.
- Explicit scope exclusions.
- Realistic supplier capacity.
- Tested data and integration dependencies.
- Operational readiness.
- Security, resilience and support requirements.
- Benefits that could be measured after release.
The programme was divided into service slices.
Each slice had one accountable owner, one delivery outcome and one acceptance gate.
This was a material change from the previous model, where multiple teams owned fragments of the platform but nobody owned the result experienced by a citizen, caseworker or service manager.
The revised baseline did not promise everything.
It promised the next valuable thing.
That is the difference between a recovery plan and a wish list.
Days 61–90: Move from recovery mode to delivery cadence
By the third phase, the programme needed visible evidence of movement.
We established:
- A single weekly executive decision forum.
- Daily delivery huddles for critical-path teams.
- A 24-hour escalation rule for blocked decisions.
- Fortnightly demonstrations using working capability.
- A dependency owner for every cross-team dependency.
- A benefits dashboard linked to live service measures.
- A supplier scorecard tied to outcomes and acceptance evidence.
- A clear transition plan for operations and support.
The governance model became smaller.
The accountability became stronger.
That was deliberate.
Governance is not the number of meetings a programme runs. It is the speed and quality of decisions it produces.
Technology: Simplify the platform before scaling it
The technology was not replaced for the sake of replacement.
That would have created another programme and another delay.
Instead, we assessed the existing architecture against five questions:
- Does this component support a priority service?
- Can it meet the required reliability and security standards?
- Is it creating avoidable integration or data risk?
- Can the internal team operate it after go-live?
- Is the cost justified by the business outcome?
The resulting architecture direction focused on simplification:
- Retain stable components that supported priority services.
- Isolate high-risk legacy dependencies.
- Standardise integration patterns.
- Reduce point-to-point interfaces.
- Strengthen identity, audit and access controls.
- Improve monitoring and operational visibility.
- Create a controlled data model for reporting and analytics.
- Establish tested disaster recovery and business continuity procedures.
The answer was not “move everything to the cloud”.
The answer was to create a platform that could be changed, secured and operated predictably.
Our approach aligned with the broader lesson in public-sector modernisation: cloud hosting alone does not create agility. Replicating a fragmented legacy estate in the cloud simply produces a newer place to store the same problems.
Execution: The recovery team worked inside the programme
We did not hand over a report and leave.
Senior delivery and technology leadership worked alongside the client’s programme team. That included:
- Rebuilding the integrated plan.
- Challenging supplier estimates.
- Running decision sessions.
- Reviewing acceptance evidence.
- Reprioritising backlog items.
- Tracking critical defects.
- Making dependencies visible.
- Preparing executive communications.
- Coaching internal delivery leads.
We also changed the conversation with the supplier.
The question was no longer:
How many people are assigned?
It became:
What usable outcome will be accepted, by when, and with what evidence?
That shift exposed several gaps quickly.
It also gave the supplier a clearer path to succeed. Ambiguous expectations were replaced with measurable gates.
Outcome: Control was restored in 90 days
The programme was not completed in 90 days.
That would have been an irresponsible claim.
The programme was made deliverable again.
At the end of the recovery period, the client had:
- A single approved baseline for scope, cost and schedule.
- A reduced first-release scope focused on priority services.
- Named accountability for every critical-path outcome.
- A decision cycle reduced from weeks to less than 24 hours for recovery issues.
- Two priority service increments released into controlled operational use.
- A 31% reduction in critical and high-severity defects.
- A validated recovery business case.
- A supplier scorecard linked to acceptance and delivery outcomes.
- A tested resilience plan for the most critical platform components.
- A benefits framework tied to adoption, processing time and operational cost.
- A governance structure that senior leaders trusted because it was based on evidence.
The most important outcome was not the revised schedule.
It was restored confidence.
The board could see what was true, what remained at risk and what decisions were required.
The delivery teams could see what mattered.
The supplier could no longer hide behind activity metrics.
The programme had moved from narrative to control.
Lesson: A stalled government platform needs an execution reset
The uncomfortable truth is simple.
Most stalled government platforms do not need another strategy.
They need:
- A credible diagnosis.
- A smaller number of priorities.
- A single accountable owner.
- Evidence-based reporting.
- Faster decisions.
- Stronger supplier management.
- Technology simplification.
- Operational adoption built into delivery.
- A baseline that reflects reality rather than political comfort.
A recovery is not a public admission of failure.
Continuing to fund an unreliable plan is the real failure.
The £120 million programme was not rescued by a new framework or a new software platform. It was rescued by connecting strategy to technology, technology to execution, execution to adoption and adoption to measurable public value.
That is the execution layer.
What public-sector CIOs should do next
If your programme is stalled, start with five questions:
- Which reported milestones can be proven with working capability?
- Who owns the end-to-end outcome?
- Which scope can be stopped without compromising statutory or operational obligations?
- How long does it take to make a decision on the critical path?
- What will be measurably better for users within the next 90 days?
If the answers are unclear, the programme does not have a technology problem alone.
It has an execution problem.
Read our programme rescue playbook for CIOs, review our enterprise transformation services, or book a confidential Delivery Diagnostic to establish the facts before committing more budget.
Frequently Asked Questions
Can a stalled government platform really be rescued in 90 days?
Yes, if “rescued” means stabilising delivery, establishing a credible baseline, restoring governance and demonstrating measurable progress. It does not mean completing a £120 million platform in three months.
What is the first step in government platform recovery?
Start with an evidence-based Delivery Diagnostic. Review delivery artefacts, code, testing, contracts, architecture, financials, risks and operational readiness. Do not rely on status reports alone.
Should a failing government programme replace its technology platform?
Not automatically. First determine whether the existing technology is the root cause. In many cases, simplification, stronger integration, better operational controls and clearer ownership produce more value than wholesale replacement.
How should suppliers be managed during a programme rescue?
Move the conversation from resource numbers to accepted outcomes. Each milestone should have a named owner, a measurable acceptance condition and objective evidence of completion.
What metrics should a recovery board track?
At minimum:
- Critical-path milestone performance.
- High-severity defect backlog.
- Decision age.
- Dependency health.
- Forecast cost to complete.
- Service reliability.
- User adoption.
- Operational processing time.
- Benefits realisation.
- Supplier performance against accepted outcomes.
SEO Publishing Assets
- Search intent: Informational with commercial investigation intent
- SEO title: Rescuing a £120M Government Platform in 90 Days
- Meta description: See how an anonymised government platform recovery restored delivery control, reduced critical defects and created a credible 90-day execution plan.
- Suggested URL slug:
/rescuing-stalled-120m-government-platform-90-days/ - Focus keyword: government platform recovery
- Secondary keywords: public sector programme rescue, government digital transformation, delivery governance, stalled technology programme, government platform modernisation
- Image alt text: Government transformation leadership team reviewing a 90-day recovery roadmap for a stalled £120M digital platform
- Internal linking suggestions:
- External authoritative sources:
- Recommended schema: Article Schema and FAQPage Schema
About the Author
Kunal Patel : CEO & Founder, Dark Consultancy
Kunal Patel founded Dark Consultancy after two decades leading technology and transformation programmes across the public sector, financial services, defence, and energy industries. He has directly managed programme recovery engagements for government agencies, development finance institutions, and regulated enterprises across the US, Middle East, South Asia, and Southeast Asia ; ranging from $5M platform migrations to $200M+ enterprise transformation portfolios. Kunal is a recognised practitioner in delivery governance for regulated environments and holds PMP and PRINCE2 Practitioner certifications. He leads every new client engagement personally and remains accountable throughout the programme lifecycle. Connect with Kunal on LinkedIn