Why Your Pilot Never Scaled
The site volunteered, the integration was unbilled, the benefit was measured by its advocates, and nobody owned it afterwards. Six structural reasons, and the reframing that fixes them.
Almost every industrial organisation has a successful pilot and no rollout. The technology worked, the numbers were good, the presentation went well, and two years later it is still running at one site while everyone involved has moved on. The reasons are structural rather than technical, and they are visible before the pilot starts if anyone is willing to look.
The first is site selection. Pilots are run at the site that volunteered — the one with the best network, the most capable maintenance team, the newest equipment, and a manager who wanted it to work. That site is chosen precisely because it is unrepresentative, and every difficulty it did not have is a difficulty the rollout will meet for the first time at scale, without the vendor's engineer standing next to it.
The second is hidden subsidy. During the pilot, the integration was done by a project engineer whose time was charged elsewhere, the tag list was hand-cleaned over a weekend, the network exception was granted verbally, and the data landed in a spreadsheet somebody maintains personally. None of that appears in the business case, and all of it has to be paid for at every subsequent site — which is why the second deployment so often costs more than the first rather than less.
The third is arithmetic. Benefit usually scales with the size of a site; cost per site is closer to fixed. The pilot at the largest plant therefore shows a ratio no smaller site can reproduce, and the rollout stalls somewhere around site five when the finance team recalculates using an average site rather than the best one. This is worth doing deliberately at the start: take the pilot's costs, apply them to the median site and the smallest site, and see whether the programme still exists.
The fourth is variance. Two hundred sites means two hundred network configurations, several controller vintages, different tag naming conventions, local modifications nobody documented, and different ideas about who is allowed to touch what. The pilot encountered none of this because it happened at one site with one set of conventions. Most of the effort in a real rollout is not the technology; it is the discovery and reconciliation of local variation, and no pilot designed as a technical proof will have measured it.
The fifth is ownership. When the project team disbands, who runs this? Which budget pays for the connectivity, the licences, the certificate renewals, the replacement sensors? Who gets the alert at three in the morning, and what are they expected to do? A pilot has a project manager; a deployed system needs an operating model, and organisations routinely fund the first without ever creating the second.
The sixth is measurement. The pilot's benefit was assessed by the people who wanted it to succeed, usually without a baseline, a control site, or an agreed method — which means the number that justified the rollout cannot survive contact with a finance function that asks how it was calculated. If the benefit is real, it deserves a measurement good enough to defend; if it is not, better to find out at one site.
The corrective is to change what the pilot is for. A pilot is not there to prove the technology works — for most industrial IoT the technology demonstrably works, and another proof adds nothing. It is there to measure what deployment costs at site number fifty. That reframing changes every decision: choose a difficult, representative site rather than a willing one; commit to sites two and three before starting, so the second-site cost is inside the project rather than a future request; count every hour spent on integration, tag mapping, network changes and training, because those hours are the product; and treat driving that per-site cost down as the pilot's actual objective, not a later optimisation.
Two more things belong in the plan. Define the operating model during the pilot and hand the system to whoever will own it before the project closes, with the budget line already created. And write the kill criteria at the start — the conditions under which this stops — because a pilot that cannot fail also cannot conclude, and the industrial landscape is full of systems that are neither scaled nor switched off, quietly consuming attention at one site each.