Escaping pilot purgatory: a 90-day operating plan for UK digital change

UK organisations are not short of digital experiments. A local authority can show a promising automation prototype; an NHS trust can demonstrate a clinical-support model; a mid-market insurer can point to a cloud proof of concept that worked well in a controlled setting. The difficulty begins after the pilot has served its purpose. The prototype is celebrated, the vendor reference is secured, and then momentum quietly dissipates. The organisation has not rejected the idea. It has simply failed to move it into production.

This pattern is often called pilot purgatory. It is rarely a technology failure. It is a management failure expressed through unclear ownership, narrow success criteria, disconnected funding and an operating model that was never designed for a live service. As UK organisations enter another year of constrained budgets and high expectations for AI and automation, the ability to escape pilot purgatory is becoming a core delivery capability.

Why pilots stall after the proof of concept

A pilot is usually designed to answer a narrow question: can this work? A production service must answer a wider set of questions. Who owns it? Who supports it at 8am on a Monday? Which budget pays for it once the innovation funding ends? What happens when data quality drops, a model drifts or a supplier changes its pricing? Pilots are often funded from transformation or innovation budgets, while production must be funded from run budgets that are already stretched.

There are other recurring causes. Procurement and security teams are engaged late, so the route to a live contract is unclear. Benefits are asserted but not baselined, making it impossible to prove whether the pilot created value. The vendor pilot team is not the same team that will support production. Data integration is underestimated because the pilot used a clean extract rather than the messy operational reality. Governance is either absent or so heavy that it slows the transition to a crawl.

The result is a familiar holding pattern: more pilots, more proofs of concept and very little scalable change.

The 90-day escape plan

The following plan is deliberately compact. It assumes a pilot has already shown enough promise to justify a production decision. The objective is not to perfect the technology. It is to establish whether the organisation can run and fund the capability as a service.

Days 1-30: establish a production mandate

The first month should settle accountability. A named executive sponsor should own the outcome, not just the experiment. A product owner should be responsible for the service definition and benefits case. A service owner should be identifiable before build completion, not after go-live. The organisation should agree a single decision gate with explicit stop, pause and continue criteria.

This is also the point to define production in business terms. What transaction volume, user group, service level and risk profile will count as live? What is the total cost of ownership over three years, including support, licensing, data, security assurance and change capacity? Finance, procurement, information security and data protection should be engaged now, not at the point of contract signature.

Days 31-60: test the operating model, not just the technology

A production-readiness review should examine the service as it will actually run. That means support routes, incident management, access control, audit trails, data quality, integration failure handling and, where AI is involved, human oversight and model monitoring. A shadow-run or limited live run is more useful than another demonstration.

Success metrics should move from novelty to operations. Depending on the use case, these may include adoption rate, processing time, error rate, cost per transaction, override rate, incident frequency and benefit realisation against a baseline. Vanity metrics such as number of users invited or demonstrations delivered should be retired.

Days 61-90: fund, contract and transition

The final month should convert the pilot into an approved operating arrangement. That may mean reallocating existing budget, presenting a phased business case, or using a service redesign saving to fund the run cost. The contract must cover production realities: performance measures, data portability, exit assistance and clear responsibilities at transition.

The operating model should also be settled. A small product team, a service management route and a change control process are usually more important than a large programme structure. The decision to scale should be taken at the end of this period, with evidence rather than enthusiasm.

Governance that does not smother delivery

Pilot purgatory often produces one of two extremes: no governance at all, or a committee structure that delays every decision. A better approach is to align the transition with the existing portfolio. Use a stage gate, not a new board. Require a named service owner, a baselined benefit case and a funded run cost. Review risks fortnightly and investment decisions monthly. Keep the governance light enough to permit decisions and firm enough to prevent drift.

Funding routes in a constrained environment

In the current UK climate, few organisations can rely on a permanent innovation fund. Production must be funded from core budgets or from credible savings. A phased business case that releases investment in stages is often more persuasive than a large upfront request. Shared services, service redesign and reallocation from lower-value activity are realistic routes. The important discipline is to include run costs from the outset rather than treating them as a later problem.

Conclusion

Pilot purgatory is not escaped by running more pilots. It is escaped by treating the transition to production as a management task with owners, metrics, money and an operating model. A 90-day plan will not answer every question, but it will force the right ones. For UK organisations under pressure to demonstrate value from digital change, that discipline is more valuable than another proof of concept.