Pilot Purgatory: Why Your Transformation Strategy Is Stuck in the Sandbox

The pattern is familiar enough to have a name. An organization identifies a transformational technology or operating model that could meaningfully change how it delivers value. A pilot is commissioned — bounded in scope, adequately resourced, enthusiastically sponsored. The pilot succeeds. The results are documented. The case for scaling is presented to leadership. And then the initiative enters what practitioners have come to call pilot purgatory: the liminal state in which a proven concept cannot reach enterprise deployment, accumulating further pilots and further evidence of local success while the structural barriers to scaling remain unaddressed.

Deloitte's 2026 US Health Care Executive Outlook captures the current version of this pattern with unusual precision. Eighty-three percent of health system executives expect agentic AI to add immediate organizational value. Only 2% have deployed it across the enterprise. The gap between expectation and execution is not a credibility gap — these executives believe in the technology.

It is not a resource gap — the investment is available. It is a coordination architecture gap: the absence of the structural mechanisms through which legal, IT, clinical operations, finance, and governance functions — each with legitimate authority over some element of enterprise AI deployment — can make the simultaneous, coordinated decisions that enterprise scaling requires.

Why pilots don't predict enterprise success

A pilot succeeds within the conditions of the pilot. A motivated team, bounded scope, active executive sponsorship, and the energy of novelty create a context that is fundamentally different from the context of enterprise deployment. The pilot demonstrates what the technology can do when the surrounding conditions are favorable.

It does not demonstrate what the organization can do with the technology at scale — because at scale, the surrounding conditions are not favorable. They are contested, fragmented, and governed by multiple actors with incompatible incentive structures who were not involved in designing the pilot and who have not committed to accommodating its outputs.

John Kotter's research on why transformation efforts fail identified the absence of a powerful, cross-functional guiding coalition as the most common structural deficit in large-scale organizational change. The pilot team is rarely this coalition. It is an enthusiastic subset of the organization operating in a protected space.

When the pilot moves to scaling, it encounters the full complexity of the organization it was never designed to navigate — the FISMA compliance requirements, the procurement governance cycles, the clinical workflow integration needs, the liability frameworks that legal has not yet reviewed. These are not unexpected obstacles. They are the predictable requirements of enterprise deployment that the pilot's bounded design never had to address.

The capability trap mechanism

Nelson Repenning and John Sterman's research on capability traps describes a self-reinforcing dynamic that characterizes organizations stuck in pilot purgatory. Each failed scaling attempt is attributed to implementation execution — the wrong team, the wrong deployment sequence, the wrong change management approach — rather than to the structural design failure that actually produced it. The response is another pilot with better execution. The structural problem — the absence of a cross-functional coordination architecture that integrates the constraints of every function whose agreement enterprise deployment requires — is never addressed, because it is never identified as the root cause.

The trap is persistent because its mechanism is invisible. Pilot purgatory looks like a series of execution failures. It is actually a single design failure, repeated. The design failure is treating transformation as a technology deployment problem rather than a complex system problem — a problem that requires the simultaneous coordination of actors with different incentives, different timelines, and different legitimate claims on the governance of the thing being transformed.

The design change that breaks the cycle

The organizations that escape pilot purgatory most reliably do not improve their pilots. They change what the pilot is for. Rather than treating the pilot as a proof of concept that will build the political case for scaling, they design the pilot as the first phase of a system design process — one whose explicit output is not a successful demonstration but a map of the coordination architecture that enterprise deployment requires.

This means involving the downstream implementation actors before the pilot concludes, not after it succeeds. Legal's constraints, IT's integration requirements, clinical governance's approval process, finance's ROI framework — these need to shape the architecture of the transformation before the architecture is fixed, not after the pilot has established a technical direction that their constraints cannot accommodate.

The session that convenes those actors — that puts legal, IT, clinical, and finance in the same room as the transformation sponsor and forces the resolution of their competing constraints into a single, coherent deployment architecture — is not a bureaucratic hurdle. It is the transformation. Everything before it is hypothesis. Everything after it is execution of a plan that the people who must implement it have already stress-tested and committed to. Pilot purgatory is not a technology problem. It is the cost of designing the wrong phase first.