Most organisations do not fail at the pilot. They fail at the step after it. Here is what separates a demonstration from a deployed system.
The pilot trap
A pilot proves that a sensor can send a reading and a model can produce a prediction. Production proves something harder: that the reading arrives every day for three years, that somebody acts on it, and that the cost of doing so is lower than the value it creates.
The gap between the two is rarely about algorithms. It is about device management, connectivity design, integration with the systems people already use, and clear ownership of the workflow the data is meant to trigger.
Design for the second year, not the first month
Battery strategy, firmware update paths, SIM and spectrum choices, spare parts and field service response all look irrelevant during a proof of concept and decisive afterwards. Ask any vendor how a thousand devices get a security patch, and how you would know if two hundred of them stopped reporting.
Choose an architecture where the analytics layer can be replaced without re-touching the field hardware, and where field hardware can be replaced without re-writing the analytics.
Start where the loss is measurable
The strongest first deployments target a loss the finance team already recognises: unplanned downtime, non-revenue water, spoilage, energy spend, shrinkage. If the baseline number exists before the project starts, the business case defends itself afterwards.