Why most programmes stall — and how the best ones don't

Written by George Purvis, Director, VOPSAI

I've been part of a lot of AI and automation programmes. Some have delivered extraordinary, lasting value. Others — and I'll be honest here — have spent six figures proving something works in one department and then quietly faded out before anyone scaled it.

The difference between the two is rarely the technology. The technology, for the most part, works. The difference is almost always in how organisations approach the transition from pilot to programme.

After more than a decade of sitting inside these programmes — not consulting from a distance, but actually building and running them — I've come to see the scaling gap as one of the most predictable and most avoidable problems in enterprise AI.

The pilot trap

A pilot is designed to prove a point. It has a defined scope, a dedicated team, executive attention, and usually a sympathetic process that's been carefully chosen to make the technology look good. That's not cynicism — it's just what pilots are for.

The problem is that the conditions which make a pilot succeed are often the opposite of the conditions you'll face at scale. In a pilot, you have senior sponsorship and close collaboration. At scale, you're running across departments with different priorities, different data standards, and different levels of enthusiasm. In a pilot, you have a hand-picked team. At scale, you're relying on process owners who have day jobs and weren't part of the original build.

Most organisations don't fail to scale because the technology breaks. They fail because they never built the organisational infrastructure to support more than one or two automations at a time.

Start with anchor processes, not a pipeline

The instinct when a pilot succeeds is to build a pipeline — a long list of processes waiting to be automated. This is understandable, but it's the wrong frame. A pipeline implies you're managing a queue. What you actually need to manage is momentum.

The programmes I've seen scale most successfully don't try to do everything at once. They choose one or two anchor processes — high-visibility, high-volume workflows where success creates genuine ripple effects — and they make those work properly before expanding. In healthcare, automating prior authorisation is a classic anchor: it's operationally significant, clinically visible, and success in one pathway creates a template and a trust base for adjacent ones. In financial services, claims intake or income reconciliation often plays the same role.

Anchor processes build something that a pipeline doesn't: organisational credibility. When frontline teams see an automation performing reliably at scale, their attitude toward the next one changes. That shift in attitude is worth more than any number of pilots.

The playbook problem

One of the most consistent patterns I see in stalled programmes is what I call the reinvention loop. Every new automation project is treated as a fresh start. A new business case, a new governance discussion, a new argument about data access, a new design for how humans and agents will interact. The team is doing their best, but without a common framework, every project absorbs a disproportionate amount of energy just getting off the ground.

A documented playbook — even a simple one — breaks this loop. It doesn't need to be a 200-page methodology. It needs to answer the questions that every new project will face: How do we select and prioritise processes? What does a governance sign-off look like? What are our standards for data readiness? How do we design the human-agent handoff? What does a successful go-live look like, and who owns it after launch?

The organisations with mature automation programmes don't answer those questions from scratch each time. They've codified their answers. New projects move faster because the framework exists. And when something goes wrong — which it will — the playbook is also where you look first.

People are the constraint, not technology

I want to be direct about something: the limiting factor in most scaling efforts is not the AI, the platform, or the integration. It is whether the people who need to work alongside the automation understand it, trust it, and have been given the tools to manage it.

This is particularly true for the supervisory layer — the team leaders, process owners, and operational managers who sit between the technology and the C-suite. These are the people who will either champion the automation or quietly work around it. Their experience of the rollout — whether they felt consulted, whether they had a way to raise concerns, whether the training was adequate — determines whether the automation delivers its projected value or underperforms in ways that are hard to diagnose.

Scaling AI is a change programme as much as it is a technology programme. The organisations that treat it as purely a technology project consistently underdeliver. The ones that treat it as a people programme that happens to involve technology consistently exceed expectations.

Measure what actually matters

The last reason programmes stall is the most avoidable: they run out of evidence. A pilot delivers a headline number — FTEs saved, hours reduced — but as the programme expands, the reporting doesn't keep pace. Leadership can't see what's working, what isn't, or whether the original investment thesis is holding up. In that vacuum, competing priorities tend to win.

Scaling requires a metrics framework that works at the programme level, not just the project level. That means tracking decision velocity, capacity gained, error reduction, compliance performance, and service resilience — not just cost. It means reporting to the C-suite in their language: what is AI delivering for the business, and where is the next tranche of value coming from?

The programmes that sustain executive sponsorship are the ones that make the value visible, consistently, in terms that matter to the people signing off the investment.

The scaling gap is a choice

None of this is inevitable. The gap between a successful pilot and an enterprise-wide AI programme is not a technology problem — it is a design problem. Design your anchor processes deliberately. Build your playbook before you need it. Invest in your people as seriously as you invest in your platform. And build the measurement infrastructure that keeps the programme honest.

Pilots prove the concept. Scaling proves the business case. The organisations doing this well have understood that the two require fundamentally different disciplines — and they've built both.