Strategy

Your Pilot Worked. That Is the Problem.

A Success That Predicts Nothing

The pilot went well. Twenty sensors, one building, clean data, a dashboard that people gathered around. Everyone agreed it should be rolled out across the portfolio, and that was fourteen months ago.

This is the most common state I find IoT projects in, and it is worth being precise about what went wrong, because the usual explanation is wrong. The technology is almost never the problem. The sensors measure, the gateways forward, the server stores. What breaks is everything around the technology, and most of it broke because the pilot was designed to succeed rather than designed to predict.

A pilot is not a small production system. It is a demonstration run under conditions production will never enjoy: one accessible site, one motivated person who checks it daily, no security review because nothing was permanent, no procurement because it went on a credit card, and a spreadsheet standing in for a data pipeline. Every one of those is a load-bearing assumption that disappears at scale.

The Decisions That Only Look Fine at Twenty Devices

Several choices are genuinely correct in a pilot and genuinely wrong in production, which is what makes them hard to catch. They do not fail. They just stop scaling.

Provisioning by hand is the clearest example. Adding twenty devices through a web console is twenty minutes of clicking, and it works perfectly. Adding two thousand is a fortnight of clicking, done by someone bored enough to make mistakes, with no record of which units were configured when or by whom. The pilot never revealed the absence of a provisioning process because at twenty devices there was no need for one.

Naming works the same way. In a pilot every device is sensor-3 in a building everyone knows. At scale you need a scheme that encodes site, floor, asset and role, and you needed it before the first installer wrote a label. Renaming a fleet after the fact means touching the device registry, the dashboards, the alert rules and the historical data, and somebody will miss one of the four.

Then there is the data path. Pilots routinely end at a spreadsheet or a single database table with a column per measurement, which is fine for one device type. The second device type arrives with different fields and the table grows columns that are null for everything else. By the fifth type the schema is unrecognisable and every query has special cases in it. The right shape is not more complicated, it is just different, and choosing it in the pilot costs nothing while changing it later means migrating live data. That shape is the subject of the data layer article.

The last one is calibration and metadata. A pilot has none because everybody remembers which sensor is where. Production needs an installation record, a calibration history and a site hierarchy, because in year two somebody will ask whether a reading from March is trustworthy and the honest answer will be that nobody knows.

The Gates Nobody Put in the Plan

Beyond the architecture sit three organisational gates, and they are usually what actually consumes the fourteen months.

The first is IT security, and it arrives the moment anything becomes permanent. The gateway that ran happily on a desk port during the pilot is not acceptable as infrastructure. It wants a dedicated network segment, a firewall policy restricting it to the ingest server, an inventory entry, a patching owner and an answer to the question of what happens when it is stolen. None of this is unreasonable and none of it is fast, and the review will ask where the encryption keys live, which is the question that stops projects for months when nobody prepared an answer. There is a full treatment in the security article, but the scheduling point is simpler: start that conversation during the pilot, not after it.

The second is procurement. A pilot bought on a card becomes a rollout that needs a supplier assessment, a contract, a data processing agreement and possibly a competitive process. Each of those has a queue in front of it. Discovering the queue after the business case is approved is what turns a three-month rollout into a nine-month one.

The third is the operations question, and it is the one most often left entirely unowned. Who replaces a battery. Who is called when a site goes quiet. What the target is for how long a device may be dark before anyone notices. Whether there is a spares pool, and whose budget it comes from. A fleet without an owner degrades silently, which is worse than failing loudly, because the dashboards keep drawing and the data slowly stops meaning anything.

A pilot proves the measurement is possible. Production is a question about processes, ownership and money, and none of those get tested by twenty sensors in one building.

Facilities Will Decide More Than Engineering

The part that surprises technical teams is how much of a rollout is negotiated rather than engineered.

Site access is the recurring cost nobody models. Every installation in an occupied building needs a slot, an escort, sometimes a permit, and occasionally a tenant's agreement. A crew that can physically fit ten sensors in a day will fit four, because six were spent waiting for someone with a key. Multiply that by a portfolio and it is the single largest line in the deployment budget.

Then there is the local knowledge problem. The pilot site was chosen because it was easy: modern, accessible, someone helpful on site. The rest of the estate includes a 1970s building with a plant room nobody has a drawing for, a site where the electrical contractor must be theirs and not yours, and one where the switchboard is in a locked room controlled by a tenant who has no interest in your project. The pilot proved nothing about any of these, which is the argument for running the pilot on the difficult site rather than the convenient one.

Design the Pilot to Predict

The fix is not to skip the pilot. It is to change what the pilot is for, from proving the concept to sizing the rollout.

Put it on the awkward site. If the estate has a building with thick concrete, poor access and an unhelpful tenant, that is the building. A pilot that surfaces no problems has not tested anything, and the problems it fails to surface get discovered later at a hundred times the price.

Include at least two device types and two sites, even small ones. Almost every architectural decision that breaks at scale is a decision that looks correct when there is only one of something. Two of anything reveals whether the design generalises.

Provision the pilot devices the way you intend to provision two thousand of them, even though it is slower than clicking. If that process does not exist yet, the pilot is the cheapest possible place to discover it.

Run it long enough to see a failure. A month is the minimum and a season is better, because you want at least one gateway outage, one flat battery and one device that behaves oddly for reasons nobody understands. Those events are the deliverable. A pilot that runs perfectly for three weeks has told you about three weeks in good weather.

And take the network away on purpose. A deliberate outage, long enough to force every device to reconnect, tells you more about the fleet's production behaviour than any amount of steady-state data.

Budget the Second Building, Not the First

The most useful number to come out of a well-run pilot is not the hardware cost. It is the labour: hours per device installed, including travel, access waiting and the unit that had to be moved twice. Multiply that by the fleet and it is usually the figure that surprises the finance team, because in most deployments installation costs more than the devices do.

Scope creep is the other line worth funding deliberately. The first building gets twenty temperature sensors and works. Then facilities want humidity, then air quality, then occupancy to right-size the plant, then water flow, then energy per tenant for the service charge. Each addition looks small and each one multiplies across the portfolio. That compounding is far cheaper to live with on infrastructure you own, where an extra sensor costs the price of the sensor, than on a per-device subscription where every addition is another line forever. The full arithmetic is in what five years actually costs.

Budget a contingency of twenty to thirty percent for additions nobody has thought of yet, and pick an architecture where adding devices does not raise the recurring cost. Both of those are decisions made once, early, and they set how comfortable the next three years are.

When the Honest Answer Is to Stop

Not every stalled pilot deserves rescuing, and it is worth saying so.

If the measurement did not change a decision, the project has no business case regardless of how well the technology worked. Plenty of pilots produce beautiful data that nobody acts on, because the action it implies was never anyone's job. That is not a scaling problem and no amount of infrastructure fixes it.

If the value is concentrated in a handful of sites, deploy to those and stop. A portfolio rollout is sometimes the wrong shape for a benefit that lives in three buildings out of forty.

And if the pilot only worked because one person was maintaining it daily, be honest about whether that role exists in the organisation at scale. If it does not, the choice is to fund it or to buy a managed arrangement, and pretending the system will run itself is how fleets go dark.

What I Provide

The work here is mostly translation. I take a pilot that proved a measurement and turn it into a design that survives procurement, security review and a facilities team: the provisioning process, the naming scheme, the data model that accepts a fifth device type, the network segmentation the security review will ask for, and the alert rules that tell you a site is dark before a tenant does.

Then I put numbers on the rollout. Hours per install measured rather than estimated, the coverage survey for the sites nobody has been in, and the five-year cost with your device counts in it. If the answer is that the deployment should be smaller than planned, that is what the report says.

The engagement ends with a handover: source code, documentation, and training for whoever inherits it, because a scaled system that only I can operate has not actually scaled.