How to Run an IoT Pilot Project That Turns Into a Rollout

TL;DR: An IoT pilot project fails at the planning stage, not the technical one. Agree one metric, one baseline, one pass mark and one decision date before you buy anything. Scope it to one site, one gateway and six to twelve sensors, from £360.62 ex VAT. Survey coverage first, then run a twelve-week clock to a fixed go/no-go gate.

Last updated: 15 September 2026

What this guide covers

• Why pilots stall
• Picking the use case
• Defining success first
• Size and cost
• The coverage test
• Who to involve
• Data and integration
• Running it
• The rollout gate
• Five ways pilots die
• The checklist
• FAQs

Why does an IoT pilot project so rarely turn into a rollout?

Because nobody agreed in writing what a pass looks like. The technology usually works. What is missing is a pre-agreed metric, a measured baseline, a threshold and a decision date. Without those four, a working trial produces a meeting where everyone nods and nothing gets ordered.

The pattern has a name: pilot purgatory. Cisco surveyed 1,845 IT and business decision-makers in the United States, the UK and India and found 60 percent of IoT initiatives stall at the proof of concept stage, with only 26 percent counted a complete success. Its top five challenges were time to completion, internal expertise, data quality, team integration and budget overruns.

Microsoft’s IoT Signals research, surveying over 3,000 IoT decision-makers, found roughly 30 percent of projects fail at proof-of-concept, usually because implementation proved expensive or the benefit was never clear.

Bain’s industrial survey (627 respondents, 329 industrial) shows the same shape: between 2016 and 2018, worry about technical expertise and data portability rose as more firms ran real trials. The nine-step method below attacks those details. It assumes a LoRaWAN IoT pilot project, so read what LoRaWAN is first if the radio side is new to you.

How do you pick the right first use case for an IoT pilot project?

Pick the pain that already has a name, an owner and a number. One measurable problem, one person who feels it monthly, one figure that moves if you fix it. Name all three in a sentence, or you have a demonstration rather than an IoT pilot project.

Score the candidate honestly. Give each question 0, 1 or 2 points. Under 8 out of 10, this is not your first IoT pilot project.

1. Can you name the number that moves? Pounds, hours, litres, kWh, incidents per quarter. “Better visibility” scores zero.
2. Is there a named owner who feels it? Someone whose month gets worse when this goes wrong.
3. Can you baseline it in four weeks? Either historic data exists, or normal can be measured quickly.
4. Can one person approve the spend? If it needs a capital request, you have lost a quarter.
5. Are there ten more assets like this one? A pilot with nowhere to scale to is a science project.

Question five is the one people skip. An IoT pilot project on a unique asset proves nothing about a rollout, so the finance case never appears. Choose the boring repeated thing.

How do you define success before buying any hardware?

Write one paragraph and get it signed. It needs a single metric, the measured baseline, the threshold that counts as a pass, the decision date and the decision-maker’s name. Five elements, agreed before a purchase order exists.

The shape of it: “Between 1 September and 24 November, unplanned callouts to the Portsmouth pump station will fall from a baseline of 6.5 per quarter. A pass is 3 or fewer, with under one false alert per sensor per month. The Operations Director decides on 28 November.”

Three rules make it work. The baseline must be measured, not remembered, because remembered baselines flatter the status quo. The threshold must be a number finance would accept. The decision date goes in the diary before sensors arrive, because an open-ended IoT pilot project is how purgatory starts.

How big should an IoT pilot project be and what does it cost?

One site, one gateway, six to twelve sensors, eight to twelve weeks. Enough to prove coverage, data quality, alerting and human behaviour, small enough for a department head to authorise from operating budget. Bigger pilots do not produce better evidence, only longer approval queues.

Entry cost is the part most people get wrong. A complete UK bundle with gateway and sensors starts at £360.62 ex VAT for the Water and Leak Monitoring Kit and runs to £619.49 ex VAT for the LoRaWAN Starter Kit, a gateway plus three environmental sensors. At that price an IoT pilot project is discretionary spend, not a capital project.

Add sensing points individually rather than over-buying. An EM500-PP pipe pressure sensor is £197.52 ex VAT, an EM500-UDL ultrasonic level sensor starts at £202.01, an AM307 indoor ambience sensor is £224.45 and a CT303 current transformer is £101.75. A realistic twelve-point IoT pilot project lands between £1,500 and £3,500 in hardware. Lifetime running costs are in our buying guides.

Eight weeks is the floor, because a baseline and a tuning period must both fit inside an IoT pilot project. Twelve is the ceiling, because past that the budget year turns.

What does the coverage test involve and why does it de-risk the pilot?

Walk the site with a LoRaWAN field tester and log signal strength at every position where a sensor will go, before ordering. It takes half a day and prevents the most common technical failure in an IoT pilot project: devices that cannot reach the gateway.

The failure looks like this. The gateway goes on the office ceiling, where the power and Ethernet are. The sensors go into a basement plant room or a below-ground chamber, and concrete, metal and standing water all attenuate hard. Nobody finds out until week three, and by then the IoT pilot project has a credibility problem it never recovers from.

The Milesight Field Tester FT101 at £441.42 ex VAT is the tool. Carry it to each intended position, trigger an uplink, read back signal strength, signal-to-noise ratio and how many gateways heard it. Test the worst position first.

Leave margin: a position that only just works with a tester in your hand will not work with a battery sensor bolted behind a pipe. If coverage fails, the answer is usually a second gateway, or a semi-industrial gateway from £279.82 ex VAT mounted higher. Our gateway buyer’s guide covers that choice.

Who needs to be in the room for an IoT pilot project?

Four functions: operations, IT or OT security, facilities and finance. Cisco’s respondents named collaboration between IT and the business side the biggest single success factor, cited by 54 percent. Get all four into a one-hour kick-off and capture their objections in writing.

• Operations: does this create more alarms someone answers at 2am? Answer with the false-positive target and who receives alerts.
• IT or OT security: what connects to what, in which direction, and does anything new appear on the corporate network? Have the diagram ready. Our notes on OT cybersecurity practice cover the segmentation questions.
• Facilities: who drills the holes, who holds the keys, what is the permit-to-work process? Book access before the install.
• Finance: what recurs after the hardware, and whose cost centre carries it in year three? Answer per point per year.

Name a deputy in that same meeting. Champions get promoted, seconded and poached, and a single point of human failure ends more trials than radio does.

What data and integration questions must you settle up front?

Four, all answered before you buy: where the data physically lands, whether you can export raw history from day one, who owns that history if you change supplier, and what an alert actually triggers. Retrofitting an answer afterwards turns a technical success into a stalled purchase.

Data portability is not theoretical. Bain’s numbers show concern about it climbing as organisations gained real proof-of-concept experience. The test is simple: on day one of your IoT pilot project, can you download twelve weeks of raw readings as CSV, and is there a documented API? If not, the rollout case gets written on someone else’s terms.

The alert question is equally concrete. “Send an email” is not an integration. Decide whether the output is a shared inbox, an SMS to a duty phone, a helpdesk ticket or a point in the building management system, then exercise it during the IoT pilot project. An untested alerting route fails on the night it matters.

How do you actually run the pilot week by week?

In four phases: install and verify, baseline with alerts off, tune thresholds from observed data, then run clean to the decision date. The classic mistake is switching alerts on in week one. You do not yet know what normal looks like, so everything generates noise and nobody opens the emails.

• Weeks 1 to 2, install and verify. Fit every device, confirm each reports on schedule with acceptable margin. Record install time per sensor; the rollout case needs it.
• Weeks 3 to 4, baseline only. Alerts stay off. You are learning the real operating range, which is almost never the one people told you about.
• Weeks 5 to 6, set thresholds from observed data, not the datasheet. Route every alert to one shared inbox.
• Weeks 7 to 10, tune. Log every false positive with a cause. Target under one false alert per sensor per month before scaling.
• Week 11, write it up against the threshold you agreed. Nothing else.
• Week 12, the go/no-go meeting. Same four functions, decision made that day.

Track two numbers nobody thinks to track: data completeness, the percentage of expected readings that arrived, and time-to-acknowledge. Neither can be reconstructed after the IoT pilot project has ended.

What evidence turns an IoT pilot project into a purchase order?

An evidence pack of six items: baseline versus pilot figure, incidents caught, data completeness, false alert rate, install time per sensor and total spend. Then one line of arithmetic comparing annual cost avoided against annual cost of monitoring. That is the business case.

The arithmetic is easier than people make it. Cost per monitored point per year is the sensor price divided by service life, plus a share of the gateway, plus platform fees and battery replacement. Take a £197.52 pressure sensor over five years, add a share of a £279.82 gateway across twelve points, and you land near £55 to £75 per point per year.

Do not invent the other side. Open your incident log for the last twenty-four months, count events this monitoring would have caught, and use costs you actually incurred. If twenty points cost £1,400 a year to monitor and the log shows two escaped-water incidents at £9,000 each, the case writes itself. If the log shows nothing, say so.

Bring the rollout quote to that meeting. A decision-maker who has just seen good evidence approves far more often than one asked to wait a fortnight for pricing, so request rollout pricing before the gate.

What are the five ways an IoT pilot project dies?

No pass mark, no coverage test, no deputy, no data access, no budget path. Each is preventable in an afternoon at the start and unfixable at the end. Check your plan against this list before ordering hardware.

1. No agreed pass mark. The trial “worked” but nobody can state whether it passed, so the decision defers. This ends more pilots than every technical fault combined.
2. Coverage never tested. Sensors cannot reach the gateway, the fix arrives in week four, and credibility never returns.
3. The champion leaves. One person held the context. Name a deputy on day one and make them attend every review.
4. The data is inaccessible. You cannot export history, so you cannot build the case, so the rollout does not happen.
5. No path to the money. A successful IoT pilot project lands on a desk with no budget line behind it. Identify whose budget funds the rollout during planning, not after the result.

What does a good IoT pilot project checklist look like?

Before you buy. Use case scores 8 or more. Metric, baseline, threshold, decision date and decision-maker in one signed paragraph. Coverage surveyed with a field tester. All four functions briefed. Data export and alert routing confirmed. Rollout budget owner identified.

During. Every device verified reporting in week two. Alerts off until week five. Every false positive logged with a cause. Completeness and time-to-acknowledge tracked weekly.

At the gate. Evidence pack complete. Cost-avoided arithmetic from your own incident log. Rollout quote in the room. Decision made on the agreed date.

A no is a good outcome. An IoT pilot project costing £600 ex VAT that honestly tells you the problem is not worth solving has done its job. What you cannot afford is no answer at all.

Want a second pair of eyes before you commit? Book a scoping call or request a pilot quote. Tell us the metric, the site and the deadline, and we will scope and price the trial. Or browse the full range with UK prices shown.

Frequently asked questions

How long should an IoT pilot project take?

Eight to twelve weeks: two to install and verify, two of baseline with alerts off, two to set thresholds, then four running clean. Under eight weeks you have no baseline. Over twelve, the sponsor or budget year changes.

How much does an IoT pilot project cost in the UK?

Hardware starts at £360.62 ex VAT for a complete gateway-and-sensor kit and typically lands between £1,500 and £3,500 ex VAT for a twelve-point deployment. Add £441.42 ex VAT for a field tester.

How many sensors do you need for a pilot?

Six to twelve on one site with one gateway. Fewer than six and a single faulty device distorts the result. More than twelve and you spend approval time rather than learning time.

What is pilot purgatory in IoT?

Pilot purgatory is the state where a trial neither fails nor scales. It keeps running, consuming attention and budget, without reaching a decision. Cisco found 60 percent of IoT initiatives stall at proof of concept. The usual cause is no agreed pass mark.

Can you reuse the hardware in the rollout?

Yes, with LoRaWAN equipment. The gateway and sensors used in an IoT pilot project are the same production units you would deploy at scale, so nothing is wasted if it passes.