Your IoT Pilot Worked. So Why Did the Project Still Fail?

For years, I believed that one of the biggest barriers to IoT adoption was technology awareness. If organisations understood what IoT could do, surely more of them would adopt it. Later, I thought the challenge was technical knowledge. If more engineers, students and companies knew how to build IoT solutions, perhaps adoption would accelerate.

After years of building IoT solutions, developing FAVORIOT, conducting training and watching projects move from demonstrations to pilots, my perspective has changed. IoT technology has become easier to access and easier to build, yet moving from a successful pilot into a real operational deployment remains surprisingly difficult.

The question is no longer simply whether IoT works. We already know that it does. The harder question is whether the technology solves an operational problem important enough for someone to own, fund and act upon.

IoT 1.0: First, We Had to Explain What IoT Was

During the earlier years of IoT, much of our work involved education. Many organisations had heard terms such as IoT, connected devices and smart systems, but understanding how these technologies could improve their operations was another matter.

We explained sensors, gateways, connectivity, cloud platforms, MQTT, dashboards and alerts. A simple demonstration could generate considerable interest. Connect a sensor, transmit its readings to the cloud and display the information remotely, and people could immediately see possibilities that had previously been difficult or expensive.

At that stage, awareness seemed to be the missing ingredient. The assumption was that once organisations understood IoT, adoption would follow. What we eventually discovered was that awareness could create curiosity, but curiosity did not necessarily create a project.

IoT 2.0: Then Everyone Wanted to Learn How to Build It

As awareness increased, the conversation changed. People were no longer asking only what IoT was. They wanted to know how to build it.

FAVORIOT conducted many IoT training programmes during this period. Students, lecturers, engineers and professionals learned how to connect sensors, work with ESP32 and Arduino, use MQTT, send data to cloud platforms and create dashboards.

Then generative AI entered the picture.

Today, someone who wants to connect an ESP32 to an IoT platform can ask an AI assistant for sample code. If the code fails, AI can help troubleshoot it. Questions that previously required searching documentation, browsing forums or attending technical training can often be answered within minutes.

The technical barrier has fallen dramatically. Yet something unexpected happened: making IoT easier to learn did not automatically make IoT solutions easier to sell.

The IoT Pilot Trap

This is where things became more interesting for me.

Like many technology companies, we believed that demonstrating strong technical capabilities would help convince customers. We showed sensors, connectivity, dashboards, alerts and different ways of monitoring physical assets. If the customer was interested, the next logical step was often a proof of concept or pilot.

Many pilots worked.

The sensor collected the required data. Connectivity worked. Information reached the platform. Dashboards displayed the readings correctly and alerts were triggered when predefined conditions occurred.

Technically, everyone could call the pilot successful.

Yet some projects stopped there.

There was no larger deployment, no expansion to additional assets and no move towards daily operational use. The technology had passed the test, but the project had failed to establish a reason to continue.

That was when I began to realise that perhaps we had been measuring the wrong definition of success.

A Successful Pilot Is Not Necessarily a Successful IoT Project

Imagine that an organisation wants to test whether it can remotely monitor several pumps. Sensors are installed, data is transmitted successfully and a dashboard shows whether each pump is operating.

The pilot proves that remote monitoring is technically possible.

But what happens next?

If nobody owns the operational problem, the project can easily stall. IT may be responsible for connectivity, an engineering team may handle the equipment, another department may have approved the pilot and management may control the budget.

Everyone participated, but nobody owns the outcome.

This is where IoT projects need a different set of questions. Instead of asking only whether the sensor works or whether the platform can display the data, we should ask who suffers when the asset fails, what the failure costs, who currently detects the problem, how quickly they respond and what changes when better visibility becomes available.

Those questions move the conversation away from technology and towards operations.

Customers Rarely Want IoT. They Want the Problem Solved

A maintenance manager may not care whether the solution uses MQTT, REST APIs or another protocol. He wants to know that a remote pump has stopped before the failure creates a bigger problem.

A facilities manager may not be looking for another dashboard. She may be trying to understand why electricity consumption increased unexpectedly. An environmental officer may need earlier warning when conditions move outside acceptable levels, while someone managing remote assets may want to reduce unnecessary site visits.

These are operational problems.

IoT becomes valuable when it makes those problems visible early enough for someone to respond.

This is an important distinction because technology companies naturally like talking about technology. We are proud of our platforms, devices, features and technical capabilities. Yet customers usually experience their organisations through operational problems rather than product features.

The conversation needs to begin there.

IoT 3.0: From Connected Devices to Operational Visibility

I now see the next phase of IoT differently.

The first phase was about education: What is IoT?

The second was about building: How do we connect devices and collect data?

The third should be about operations: What problem can we see earlier, who needs to know about it and what action follows?

This is why the idea of Connect → See → Act has become increasingly meaningful to me. Connecting an asset creates data, but data alone does not create value. Someone must be able to see what is happening, understand why it matters and take the appropriate action.

The dashboard should never be the destination. It should be part of the path towards a better operational decision.

Six Lessons From IoT Pilots That Never Scaled

After years of building IoT solutions and watching the market develop, these are some lessons I have learned, sometimes the hard way:

1. Do not start with the sensor. Start by understanding what the organisation cannot see today and why that matters.
2. Define operational success, not only technical success. “The sensor transmitted successfully” is very different from “we reduced unnecessary site visits by 30%.”
3. Find the operational owner before starting the pilot. Someone inside the organisation must care enough about the problem to push for what happens next.
4. Discuss production before the pilot finishes. Budget, maintenance, connectivity, cybersecurity, device replacement, support and responsibilities should not become surprises after technical validation.
5. Do not make the dashboard the final objective. Ask what decision or action should happen because someone saw the information.
6. Design the pilot around the possibility of scaling. If nobody can explain what happens after a successful pilot, that question should be addressed before spending too much time proving the technology.

Perhaps We Have Been Asking the Wrong Question

For many years, the IoT industry had to prove that connected technology worked. That was necessary when organisations were still unfamiliar with sensors, cloud platforms and connected assets.

Today, we are in a different position. Sensors work. Connectivity works. Platforms work. AI is making development and technical troubleshooting easier than before.

The harder challenge now lies elsewhere.

When evaluating an IoT project, perhaps the first question should no longer be, “Can we connect this asset?” Instead, we should ask, “What operational problem becomes visible once we connect it, who cares about that problem, and what will they do differently once they can see it?”

After years of building IoT solutions, that has become one of my biggest lessons. Technology can make something possible, but an operational problem gives the technology a reason to exist.

And sometimes, it takes a few successful pilots that go absolutely nowhere to finally understand the difference.