The pilot worked. Scaling is a different project

The pilot ran in the customer service team for four months. The team lead volunteered for it, the two people who used the tool most were the ones who had asked for it, and a data engineer spent the first six weeks cleaning the ticket history by hand so the model had something decent to learn from. The consultants sat two desks away and fixed things the same afternoon. At the end there is a demo, a short report, and a clear sense that it worked.

The board asks the natural question: when does every team get this? A rollout plan is drafted, copying the pilot into eleven other teams over two quarters. Six months later, three teams use it daily, four tried it and stopped, and the rest are waiting for a data fix that has no owner.

The scale-out was treated as more of the same thing. It was not the same thing. A pilot is a test under conditions chosen to make it work. Scaling is an encounter with the conditions nobody chose.

What the pilot did not test

The other teams’ processes. The pilot team’s process was mapped, simplified and agreed before the tool arrived. The next team does the nominally same work in a different order, with different exceptions, and the tool’s assumptions break on the first week. The article on undefined processes describes why; scaling multiplies it by the number of teams.

The data as it actually is. Pilot data was selected, cleaned, and in places corrected by hand. Production data arrives from every system, with every gap and inconsistency intact. The tool is the same; its input is not, and the quality of its output follows the input.

Support when nobody is two desks away. During the pilot, a problem was fixed the same day by somebody who understood the tool. At scale, a problem goes into a queue. The second team’s experience of the tool is mostly its experience of that queue, and no demo measured it.

Training that is not a conversation. The pilot team learned the tool by talking to the people who built it. The eleventh team gets a recording and a document. What transferred informally in the pilot has to be designed, written and taught deliberately at scale, and nobody budgeted that.

Who pays and who owns. The pilot was funded from an innovation budget and owned by the programme. At scale, the running cost lands on a department that did not choose it, and the decision to keep it lands on a manager who was not consulted. Both are entitled to say no.

The people who did not volunteer. The pilot team wanted it. The next teams were told. The article on resistance explains why their reaction is usually reasonable; a rollout plan built on the pilot team’s enthusiasm will mistake it for obstruction.

Treat the scale-out as a new project

Diagnose each receiving team, briefly. Not a programme, a short look: how does this team do the work today, which systems feed it, what would have to be true for the tool to fit. Some teams will fit at once, some after a change to the process, some not at all. Knowing which is which before the rollout is cheaper than discovering it during.

Replace handwork with pipelines before the second team. Whatever the data engineer did by hand for the pilot has to run automatically, every day, on data nobody has looked at. If that cannot be built, the pilot’s result does not transfer, and it is better to know in week one.

Build the support and training as deliverables. A named owner, a response time people can plan around, a training path that works without the original builders. These are not overheads of the rollout; they are most of it.

Move the budget and the decision to the line. The department that will run the tool should decide whether to adopt it, with the running cost in its own numbers. That is slower than a central mandate and it produces adoption that survives the programme’s end.

Sequence the teams, and let early ones change the design. Two teams at a time, with the second wave adjusted by what the first wave found. A plan that puts all eleven teams on one Gantt chart is a plan to discover the same problem eleven times.

What to measure before deciding to scale

The pilot’s report says it worked. Before scaling, ask what it worked against: a baseline measured before it started, as the baseline article argues, or an impression formed during it. Then ask three narrower questions. How much of the pilot’s result depended on the handwork, the volunteers and the people two desks away, and what remains without them. What did it cost per month to keep running, including the time of the people who fixed it. And which of the receiving teams has a process close enough to the pilot team’s for the result to be expected to repeat.

If the answers are not known, the decision to scale is being taken on the pilot’s story rather than its evidence, and the steering committee should be told so plainly.

The honest option

Sometimes the right answer is not to scale. The pilot team keeps the tool, because for them it works; the other teams do not get it, because for them it would not; and the budget goes to a different problem. A pilot that ends this way has done its job. The failure is not a pilot that stays small; it is a rollout that is kept alive because stopping would look like admitting the pilot was wrong, when it was not.

A test you can run today

Take the pilot report and write two columns. On the left, every condition that was true during the pilot: who was on the team, who cleaned what, who fixed what, where the money came from. On the right, whether each one will be true for the next team.

If more than a handful of conditions change, the scale-out is a new project, and the right next step is a diagnosis of the receiving teams, not a rollout plan. That is the point at which VUCALE’s framing work starts again rather than continuing, and where the result of the framing is allowed to be that the pilot should stay where it is.