Why Pilots Succeed Where Scale Struggles
Pilots operate within conditions that favour success. Understanding these conditions explains why they do not automatically transfer to wider deployment.
A typical pilot operates at a single site with a known user population. The team is small and motivated. Relationships are direct. Problems are solved through conversation rather than process. Governance is often informal, based on trust and proximity.
These conditions are not weaknesses. They are why pilots can move quickly and demonstrate value. But they are also why pilot success does not predict scale success. The conditions that enabled the pilot are precisely the conditions that scale removes.
Bounded conditions
Single site, known users, contained scope, informal governance, direct relationships, rapid iteration.
Emerging complexity
Multiple sites, variable contexts, formal requirements surface, relationships become indirect, process replaces conversation.
System conditions
Cross-organisational deployment, procurement requirements, regulatory scrutiny, governance load proportional to reach.
The gap between pilot and scale is not primarily technical. The software that worked at one site will generally work at ten. The gap is governance: the accumulation of requirements that were deferred, simplified, or informally managed during the pilot phase.
Signal: When innovations stall at scale, the cause is usually governance load that was invisible in the pilot, not technical limitations that emerged later.
Assurance Debt
Like technical debt, assurance debt accumulates when governance decisions are deferred. Unlike technical debt, it often remains invisible until scale forces it into view.
During pilot development, teams make reasonable decisions to defer formalism. A lightweight clinical safety approach is sufficient for a contained deployment. Information governance can be managed through direct relationships. Accessibility requirements can be addressed later. Each deferral is individually sensible.
The debt compounds. By the time an innovation is ready to scale, the accumulated governance obligations can exceed the original development effort. Procurement surfaces questions the pilot never had to answer. Clinical safety cases must be rebuilt for multi-site deployment. Information governance frameworks must work across organisational boundaries.
Clinical Safety
Pilot safety cases often assume bounded conditions: known users, single site, direct oversight. Multi-site deployment invalidates these assumptions.
Cost to address retrospectively: Significant. Safety cases may need fundamental restructuring.
Information Governance
Pilot IG arrangements often rely on local agreements and direct relationships. Cross-organisational deployment requires formal frameworks.
Cost to address retrospectively: High. May require Data Protection Impact Assessments and formal agreements.
Accessibility
Pilots may defer accessibility compliance, particularly for internal tools or limited user populations. Public sector deployment requires WCAG compliance.
Cost to address retrospectively: Variable. Can require significant interface redesign.
Supplier Assurance
Pilot relationships often bypass formal supplier assessment. Procurement at scale requires evidence of security, stability, and capability.
Cost to address retrospectively: Moderate to high. May require certification, audits, or architectural changes.
Assurance debt is not a moral failing. It is a natural consequence of how innovation works. The problem is not that debt accumulates, but that it often accumulates invisibly until procurement or deployment forces a reckoning.
The pilot succeeds because governance is deferred; scale fails because governance becomes unavoidable.
Signal: The true cost of an innovation includes its assurance debt. Pilots that defer governance are borrowing against future deployment.
Procurement as Governance Surface
Procurement is often blamed for slowing innovation. This framing misses what procurement actually does: it surfaces governance questions that were previously deferred.
A procurement process asks questions about clinical safety, information governance, accessibility, security, supplier stability, and contractual risk. These are not bureaucratic obstacles. They are legitimate requirements for deploying technology at scale in healthcare.
When procurement feels slow, it is usually because the innovation being procured has not yet answered these questions. The delay is proportional to the assurance debt accumulated, not to the procurement process itself.
What Procurement Surfaces
Clinical safety: Has a Clinical Safety Case been produced to DCB 0129? Has the deploying organisation assessed risks under DCB 0160?
Information governance: What data is processed? On what legal basis? What are the cross-border implications? Has a DPIA been completed?
Accessibility: Does the solution meet WCAG 2.1 AA? Has it been tested with assistive technologies?
Security: What certifications exist? What penetration testing has been conducted? How is data protected?
Supplier assurance: What is the supplier's financial stability? What business continuity arrangements exist? What happens if the supplier fails?
The Procurement Paradox
Innovations that invest early in governance readiness pass through procurement faster than innovations that defer governance until procurement forces it. The paradox: governance investment that seems to slow early development actually accelerates overall deployment.
Signal: Procurement does not create governance requirements. It reveals requirements that always existed but were not previously visible.
Governance Readiness Before Scale
The alternative to retrospective governance is building scale readiness into innovation from the beginning. Not by over-engineering early, but by making deliberate choices about what to defer and what to establish.
This does not mean full compliance before pilot. It means awareness of what compliance will require, explicit decisions about what to defer, and a credible path to addressing deferred items before scale.
Clinical Safety
Establish hazard identification early, even if the full safety case is deferred. Document assumptions that would invalidate pilot safety arrangements at scale.
Information Governance
Define data processing purposes and legal bases from the start. Design for cross-organisational data sharing even if initial deployment is single-site.
Accessibility
Build to WCAG standards from the beginning. Retrofitting accessibility is more expensive than building it in.
Supplier Readiness
Understand procurement requirements early. Build toward certifications and audit readiness rather than treating them as late-stage obstacles.
The Investment Case
Governance readiness requires investment during a phase when resources are scarce and urgency is high. The case for this investment is not moral but practical: innovations that defer governance pay more in total, not less.
The cost is not just financial. Assurance debt introduces delay when delay is most damaging: at the point of scale, when clinical value could be extending to more patients, when competitive advantage depends on deployment speed, when funding depends on demonstrating scalability.
Signal: Governance readiness is not an overhead on innovation. It is a multiplier on the value innovation can deliver.
What This Means for Different Actors
For Innovators and Founders
Treat governance as a product requirement, not a compliance afterthought. Understand the assurance debt you are accumulating and have a credible plan to address it. Build relationships with CSOs and IG leads early, not at procurement.
For Innovation Teams in NHS Organisations
Design pilot frameworks that make governance requirements visible from the start. Ensure innovations have explicit scale plans that include governance readiness. Resist the pressure to defer all governance until "after the pilot proves value".
For Clinical Safety Officers
Engage with innovations early, when guidance can shape design rather than block deployment. Develop frameworks for pilot safety that make scale requirements explicit. Consider how assurance can compound rather than reset.
For Procurement
Recognise that procurement friction often reflects upstream governance gaps, not process failure. Consider how procurement requirements can be made visible earlier in the innovation lifecycle. Work with innovation teams to reduce surprise.
For System Leaders
Create environments where governance readiness is valued and supported during innovation, not imposed at deployment. Invest in governance infrastructure that innovations can inherit rather than rebuild.
How This Connects
Scaling from pilot is one dimension of governance infrastructure. It connects to questions about how assurance operates at scale and how governance can be shared rather than rebuilt.
These pages describe governance as infrastructure: capabilities that compound when shared, and reset when rebuilt.
Frequently Asked Questions
Why do digital health pilots succeed but struggle to scale?
Pilots operate within bounded conditions: a single site, known users, contained scope, and often informal governance arrangements. These conditions allow rapid iteration and close relationships. Scale removes these conditions. Multiple sites introduce variability. Formal procurement introduces requirements. Cross-organisational deployment introduces governance load. The pilot succeeded because of conditions that do not survive expansion.
What is assurance debt?
Assurance debt accumulates when governance decisions are deferred during early development. Like technical debt, it compounds. A pilot that defers clinical safety formalism, information governance review, or accessibility compliance accumulates obligations that must be paid before scale. The debt is not visible in the pilot but becomes blocking at procurement.
Why does procurement slow innovation scaling?
Procurement is not the cause of scaling friction. It is where accumulated governance gaps become visible. Procurement processes surface questions about clinical safety, information governance, accessibility, and supplier assurance that pilots often defer. The delay is proportional to the assurance debt accumulated, not to procurement bureaucracy itself.
What governance must exist before scaling?
Before scale, innovations need: clinical safety cases that anticipate multi-site deployment, information governance frameworks that work across organisational boundaries, accessibility compliance that meets public sector requirements, and supplier assurance that satisfies procurement. Building these retrospectively is more expensive than building them early.
Planning for Scale?
We work with innovators, NHS teams, and system leaders on governance readiness that enables scale rather than blocking it.
Book a discovery call