A Stage-Gate for Scaling Pilots: Evidence Required Before Each New Site

Why one successful pilot is not a licence to scale

The gap between an invention and an innovation is easiest to see when a pilot ends. A pilot proves that a solution can deliver an outcome inside one controlled environment; it does not prove the same outcome will appear at the second, fifth, or twentieth site. By the standards used in innovation management and asset-management practice, an innovation exists only when it is embedded in processes and produces a repeatable effect. A single-location result remains local evidence; until it has been shown to travel, it is not transfer evidence.

Scaling fails most often not because growth is impossible but because evidence is misread. Teams treat a successful pilot as permission to commit broadly — a pattern sometimes called evidence overreach. A pilot can look strong in one line, one shift, or one product family and still collapse in production when master data is incomplete, exception paths were excluded, users were hand-held by the project team, or integrations were manually patched. The remedy is to treat each new site as its own test of whether the original result generalizes.

• Transfer evidence: outcomes that replicate across contexts, teams, and operating conditions.
• Local evidence: results that depend on a specific team, site, or one-off configuration.
• Ask before every gate: what about the pilot would not survive contact with a new site?

How stage-gate thinking applies between sites

The stage-gate model, introduced by Robert G. Cooper for new-product development, divides a project into stages separated by gates. At each gate, cross-functional reviewers apply go/kill/hold criteria against a scorecard before the next tranche of resources is released. Its value is discipline: decisions are made on evidence, not momentum, and weak bets are killed early while stopping them is still cheap. The same logic transfers naturally to site rollout — instead of one all-or-nothing launch decision, you install a sequence of gates, one per location or per tranche of sites.

In highly regulated environments — transport, utilities, manufacturing, retail networks — gate criteria must go beyond commercial promise. Infrastructure practitioners who adapt stage-gate add explicit readiness criteria for data, analytics, processes, and safety alongside the business case. A site can be technically ready yet organizationally and institutionally unprepared: responsibilities unclear, contracts absent, acceptance rules unwritten. Each site gate should therefore review four planes: evidence of effect, economics, the operational and data foundation, and the governance or institutional base.

Keep gates light but real. For low-risk digital changes a rigid multi-stage process adds friction; for capital-heavy or regulated rollouts the gate is the cheapest place to stop a mistake. A sensible default is fast, hypothesis-driven iteration inside the preparation stage, with strict gates reserved for the moment a new site commits real capacity and budget.

The evidence packs each new site must clear

Define, before the pilot ends, what a new site must prove to pass. Government guidance on converting pilots into production repeatedly stresses that success criteria must be quantifiable, tied to a dashboard, and set before results arrive, so go/no-go reviews are objective rather than retrospective rationalizations. In practice, five evidence packs cover most cases.

Reproducibility and performance. The model should show stable outcomes across shifts, users, and normal variability — repeatable cycle time, error rate, latency, uptime — not a single good week. If the result was achieved only through project-team heroics or vendor engineering on site, it is not yet reproducible.

Data and integration readiness. Completeness of master data, roles, document versions, and records matters more than teams expect; many pilots fail at scale because data cleanup was deferred. Interfaces to surrounding systems must be tested under realistic load and failure, because manual workarounds that were tolerable in a pilot become bottlenecks in production.

Economics at scale and governance. The business case must survive production overhead: support, validation, licensing, integration maintenance, and rollout labor. In parallel, move the operating agreement onto durable rails — SLAs, reporting formats, acceptance rules, named support owners, and a workable rollback — so the innovation shifts from project mode into regular operations. That institutionalization package is what turns a working pilot into a working norm.

Designing the gate: thresholds, scorecards, and no-go signals

A gate review needs three inputs: a completed outputs package, a weighted scorecard agreed in advance, and a cross-functional panel that includes operations, finance, and the site's own leadership. Scores should be checked against thresholds fixed before results are known, not against a softened target invented afterward. Reviewers need the authority and the habit to issue a genuine hold or no-go, because a gate that rubber-stamps progress stops predicting anything.

Watch for no-go signals that indicate a site is not ready: the rollout depends on manual data fixes or project-team intervention that will not exist in steady state; exception paths such as rework, deviations, or nonconformance were excluded; core integrations remain fragile or unreconciled; validation evidence is incomplete; no clear owner exists for support and configuration; or KPIs improved only because measurement conditions were unrepresentative.

A useful practical rule: if the implementation team stepped away for thirty days, could site operations, quality, and IT run the process, support users, manage changes, and defend the records? If not, the location is still in pilot, however green the dashboard looks. Raise the evidence bar as commitments become less reversible; a decision that can no longer be undone should be harder to reach than one that can. This is general management guidance, not legal or financial advice, and exact thresholds are site- and jurisdiction-specific.

Turning a project into an operating norm

Scaling across sites becomes affordable only when the second site stops being a fresh project and becomes execution of a codified playbook. Capture learnings, resource needs, and delivery processes as templates; record pricing logic, onboarding, escalation, and change-management procedures; and monitor post-rollout with simple red-amber-green dashboards that surface issues early. Lessons from site N should be fed back into the package for site N+1 through loops between engineering, operations, and the new locations.

Replication also needs honest capacity planning. Organizations that scale before production and support can absorb demand damage reputation and customer trust. Practitioners commonly recommend holding a buffer on the order of 20–30% of resources and budget, because a broad rollout cannot always be slowed or stopped mid-flight. And because current metrics and rules optimized for the existing operating model can systematically suppress a new solution, design acceptance criteria, contract forms, and reporting with an eye to procurement and compliance realities rather than bolting them on at the last gate.