Why Pilots Succeed and Rollouts Fail
A successful pilot gets celebrated, funded for wider rollout, and then quietly underperforms at scale. McKinsey's manufacturing research has a name for this pattern: pilot purgatory. Here is what actually causes it.
A pilot succeeds, gets celebrated internally, and is approved for organisation-wide rollout — which then quietly underperforms, disappoints, or stalls entirely. This pattern is common enough that McKinsey's manufacturing-sector research gave it a name: pilot purgatory, describing initiatives that get stuck permanently at pilot scale, unable to translate a genuine small-scale success into a genuine large-scale one. This is a companion piece to our guide on digital transformation.
Why a successful pilot is not evidence the rollout will succeed
Pilots get disproportionate attention. A pilot team is usually smaller, more engaged, and more closely supported than a full rollout population will ever be. The pilot's success partly reflects that concentrated attention, which cannot scale proportionally to the whole organisation.
Pilots are often run by early adopters, not a representative population. Volunteers or hand-picked participants for a pilot are systematically more receptive to change than the broader employee base. Their enthusiasm is real, but it is not representative of how the technology will land with people who did not choose to be early adopters.
Pilots frequently skip the organisational complexity that scale introduces. A pilot in one team, one location, or one product line avoids the cross-team dependencies, competing priorities, and legacy system integrations that a full rollout inevitably encounters. The pilot proves the concept works in a simplified environment, not that it survives the actual complexity of the whole organisation.
The workflow redesign that made the pilot succeed often does not travel. If the pilot succeeded partly because of a locally redesigned workflow — the differentiator covered in our piece on workflow redesign — that redesign may not transfer cleanly to other teams with different existing processes, different constraints, or different local workarounds.
What separates pilots that actually scale from those that don't
The pilot was designed from the start to test scalability, not just feasibility. A pilot that only asks "does this work" answers a narrower and less useful question than one that also asks "does this work under conditions resembling the eventual scale."
A representative, not self-selected, pilot population. Where organisationally possible, including participants who did not volunteer, and who represent the range of roles and attitudes the full rollout will actually encounter, produces a more honest signal about what to expect at scale.
The support model is explicitly designed to change between pilot and rollout, and that change is planned for. If the pilot succeeded because of hands-on support from the project team directly, the rollout needs a support model that can operate at the organisation's actual scale — a plan, not an assumption that the same intensity will somehow continue.
Outcome metrics, not just pilot enthusiasm, determine the go/no-go decision. Our piece on measuring whether a technology project worked covers this in more depth — a pilot that produced enthusiastic anecdotes but no measured outcome improvement is a weaker case for scaling than one with modest enthusiasm and clear outcome data.
A practical test before committing to full rollout
Ask specifically: what about this pilot's success depended on conditions that will not exist at full scale? Concentrated attention, a self-selected population, a simplified organisational context, and informal support are the four most common answers. If the honest answer to any of them is "yes, and we haven't planned for that changing," the rollout is not yet ready to be scoped on the pilot's numbers alone.
What we do
We design pilots from the start to answer the scaling question, not just the feasibility question, and we build the rollout's support and change management model explicitly, rather than assuming pilot-level intensity will somehow continue. If you have a successful pilot and are deciding whether and how to scale it, that is a conversation we are glad to have.
Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions.