Plenty of industrial IoT pilots succeed technically and still die quietly. The dashboard works, the sensors report, and then nobody can explain why the project should expand. Most of the time the cause is not the technology but the scoping. A pilot should be designed as the first step of a rollout, not as a science fair exhibit.

Begin With a Problem That Has a Cost

The strongest pilots start with a pain that operations already feels: unplanned stoppages on a particular line, energy use that nobody can attribute, quality escapes traced to temperature drift, or manual rounds that take technicians away from higher-value work. Ask the people who run the equipment, not just management. A good candidate has three traits:

• It is measurable today, even if imperfectly, so you have a baseline.
• It is bounded, meaning one line, one asset class or one process step.
• It has an owner who will act on the results.

Avoid pilots described as “collect all the data and see what we find.” Without a question, data collection becomes a storage bill.

Define Success Before You Buy Anything

Write the success criteria down in plain terms, agreed with operations and finance. Examples include fewer unplanned stops on the pilot asset, shorter time to diagnose faults, or reduced manual inspection effort. Use your own baseline figures, collected before the pilot begins, so that the comparison is honest. Also write down what failure looks like and when you will stop. A pilot with an end condition is easier to approve.

Inventory What You Already Have

Many plants already generate useful data. Programmable logic controllers, drives, SCADA systems and historians often hold information that simply is not being used. Before adding sensors, check what existing equipment can already provide. Retrofitting external sensors is a valid path for older machines, but it adds installation work, calibration and maintenance, so use it where existing signals do not answer your question.

For each data source, note the protocol it speaks, who owns it, how often values change, and whether touching it requires change approval. Industrial protocols and gateways vary widely, so check each vendor’s current documentation for connection options.

Plan the Data Path End to End

A pilot touches several layers, and weakness in any of them can sink it:

1. Sensing and acquisition: sensors, controllers and gateways.
2. Transport: wired or wireless links from the shop floor to the edge or cloud.
3. Storage and processing: where time-series data lives and how it is cleaned.
4. Analysis and alerting: rules, dashboards or models.
5. Action: the human or system response when something is flagged.

The fifth layer is the one pilots most often forget. An alert nobody is assigned to handle is just noise.

A Pilot Planning Checklist

Item	Question to answer	Done when
Problem	What cost are we reducing?	Written and owner agreed
Baseline	How do we measure today?	Pre-pilot data recorded
Scope	Which asset, line or process?	Boundaries documented
Data sources	What exists, what must be added?	Inventory completed
Security	Who approves network access?	IT and OT sign-off
Response	Who acts on an alert?	Named role and procedure
Exit	When do we stop or scale?	Criteria written

Bring IT and OT to the Table Early

Operational technology teams care about uptime and safety. IT teams care about security and standardisation. A pilot that arrives with a surprise network device will meet resistance from both. Involve them during planning, agree how the pilot connects to the plant network, and avoid any change that could affect control of the process. Read-only data collection is usually the safest starting point. Safety regulations and company policy differ by site and jurisdiction, so involve your safety and compliance staff rather than assuming.

Design for Rollout From Day One

Ask uncomfortable questions now. If this works, how would we repeat it on twenty similar machines? Choose hardware and software that can be installed by your own technicians, documented in a repeatable way, and supported long term. Prefer open or well-documented interfaces over closed ones that would lock you into a single supplier. Keep an eye on the cost of ongoing items such as connectivity, licences and maintenance, which often exceed the pilot hardware.

A Hypothetical Example

Suppose a small plant has a packaging line whose main conveyor motor stops unexpectedly a few times a month. The maintenance lead proposes a pilot: monitor motor current and vibration on that one motor, compare readings with the maintenance log, and see whether early warning signs appear before failures. They record the baseline from the past months of stop reports, assign the shift supervisor to respond to alerts, and agree on a twelve-week window. At the end, the team reviews whether warnings arrived early enough to schedule maintenance, how many were false alarms, and how much effort the system needed. Whether the answer is yes or no, the plant learns something specific and cheap.

Common Pitfalls

• Pilots that depend on one enthusiastic person who then changes roles.
• Treating data quality as an afterthought, such as unsynchronised clocks or missing units.
• Skipping the baseline and then arguing about results.
• Buying a platform before defining the question.
• Underestimating how much change management the operators need.

Frequently Asked Questions

How long should an industrial IoT pilot run? Long enough to see the events you care about happen several times. For rare failures that can mean months, so pick a problem frequent enough to observe within your window.

Should we use existing PLC data or add new sensors? Start with what exists, since it is cheaper and already trusted. Add sensors only where existing signals cannot answer your specific question.

Do we need machine learning for a first pilot? Often not. Simple thresholds, trends and visualisations frequently deliver value and help teams understand their data before adding complexity.

Who should own the pilot? Someone from operations with authority over the process, supported by IT and engineering. Technology-only ownership tends to produce technology-only results.

What if the pilot fails? A clear negative result is still useful. Document what you learned, whether the problem, data or process was the weak link, and decide whether to retry, redesign or stop.

Next Step

Choose one recurring operational problem, write a one-page pilot brief covering the baseline, scope, success criteria and the person who will act on alerts, and review it with both operations and IT before purchasing any hardware.