A few years ago, I walked into a facility that had spent close to a million ringgit on an IoT deployment. Sensors were installed. A dashboard was running. The operations manager proudly pulled up a screen showing hundreds of data points flowing in, live, in real time.
I asked him one question: “What decision did you make yesterday based on this data?”
He paused. He looked at the screen. He called a colleague over. A few minutes passed.
“Let me check the system,” he finally said.
That pause told me everything. The IoT project was not broken in the way most people imagine broken things to be. The sensors worked. The connectivity was stable. The platform was live. But something deeper had failed, and it had failed quietly, in a way that nobody in the room had named yet.
That was the moment I realised the industry had a serious problem. Not a technology problem. A thinking problem.
We Built the Infrastructure. We Forgot the Purpose.
When I look back at two decades of IoT work, across MIMOS, through my time at REDtone IoT, and now building FAVORIOT, the pattern I keep seeing is the same one. Organisations invest in sensors, platforms, and dashboards. They point to these things as proof of digital transformation. And then they wait for the results to come.
The results rarely come. Not because the technology failed, but because nobody asked the hard question before deployment: what decision are we trying to make faster?
The sensor was never the goal. The data was never the goal. The goal was always a better decision, made quicker, based on something real. But somehow, between the vendor pitch and the project sign-off and the go-live celebration, that goal got buried under the excitement of the technology itself.
I have seen this across manufacturing plants, utility companies, logistics operations, and smart city deployments. The pattern is consistent. The language around it is always optimistic. “We now have full visibility.” “We have a live dashboard.” “We are data-driven now.”
But ask the operations team what decision they made differently last Tuesday because of that dashboard, and the room goes quiet.
I Started Calling It Operational Blindness
Recently, I wrote a more technical definition of this condition for IoT World. I called it Operational Blindness. The full definition is this: it is the condition where an organisation invests in IoT infrastructure, collects operational data at scale, yet still cannot make confident, timely decisions because the data never closes the loop to action.
The organisation sees numbers. It does not see clearly.
This is not a criticism of the people involved. The engineers built what they were asked to build. The analysts produced their reports. The executives attended the strategy sessions. Everyone did their job. But the system, as a whole, was never designed to produce decisions. It was designed to produce data. And data without a decision is just noise dressed up in a dashboard.
When I started naming this condition clearly, something interesting happened. People began recognising it in their own organisations. System integrators told me they had seen this in nearly every project they had ever delivered. Operations managers said they had felt it for years but had no language for it. That recognition mattered to me, because you cannot fix what you refuse to name.
Why IoT Projects Stop Scaling
The question I get asked most often is: why do IoT pilots succeed but never scale?
The answer, in my experience, comes back to the same broken loop every time.
A pilot project works because it is small, focused, and closely watched. Someone with authority and curiosity is paying attention. Decisions get made. Results are visible. Everyone celebrates and writes a press release.
Then comes the scale-up. More sensors, more sites, more data, more dashboards. And suddenly the thing that made the pilot work, which was a human being with a clear question and the authority to act on the answer, gets diluted across a larger organisation with competing priorities, legacy processes, and departments that were never part of the original pilot conversation.
The data multiplies. The decision-making does not.
By the time the system is running at scale, there are alerts nobody reads, dashboards nobody opens, and reports that go straight from the inbox to the archive folder. The operations team, who were not involved in designing the IoT system, have learned to work around it rather than with it. They trust their own experience more than a dashboard they did not ask for.
This is not stubbornness. This is rational behaviour when you design a system without designing it around the people who are supposed to use it.
The Three Things That Actually Need to Change
After watching this pattern repeat itself across too many projects, I have settled on three things that genuinely move the needle.
The first is contextualisation. Raw data is not insight. A temperature reading means nothing unless it is translated into operational language. Not “82 degrees Celsius.” But “Motor 4B has been running above its safe operating threshold for 40 minutes and failure is likely within six hours.” Context converts measurement into meaning. Without it, the dashboard is just wallpaper.
The second is integration into workflow. The insight has to reach the right person through the channel they already use, at the moment they can act on it. Not a report that lands at 9am about something that happened at 2am. Not a dashboard on a screen in a control room that the relevant decision-maker never visits. The signal has to travel to where the decision actually gets made.
The third is closing the loop. The system needs to know whether action was taken, what action, and what the outcome was. Without that feedback loop, the organisation cannot learn from its data. It cannot improve. It cannot measure whether the IoT investment is working. The loop has to close: from sensor to decision to outcome and back.
These are not exotic ideas. But they are consistently absent in organisations that are spending heavily on IoT and wondering why the ROI never materialises.
What I Tell Every Organisation That Comes to Me
When organisations approach FAVORIOT, one of the first things I ask is: what decision do you want to make better, and who in your organisation makes that decision today?
If they cannot answer that question, the deployment is not ready. Not because the technology is not ready. The technology is almost always ready. But the organisation is not yet clear on what it is trying to do with what the technology reveals.
That clarity is everything. It is the difference between a sensor deployment that scales and one that stays a pilot forever. It is the difference between a dashboard that changes operations and one that gets opened once a month during the management review.
We built FAVORIOT precisely because we kept seeing this gap in the market. Not a platform gap. A gap between what the data says and what the organisation decides to do about it. That is the gap we are working to close.
The Real Failure Mode
The IoT industry has spent years convincing organisations that more sensors, more data, and more dashboards are the path to operational excellence. They are not. They are the beginning of the path. What lies between that beginning and actual operational excellence is the hard work of turning data into decisions, and decisions into habits, and habits into results.
Most IoT projects fail to scale not because the technology lets them down, but because nobody built a bridge between the technology and the way the organisation actually makes decisions. The bridge is not a software feature. It is an organisational design question. And it is one that the IoT industry has, for too long, left for somebody else to answer.
If you are running an IoT deployment right now and it is not producing the results you expected, I would encourage you to ask one question before you spend another ringgit on more sensors or a better platform. Ask: what decision am I trying to make, and is my current system designed to help me make it?
The answer to that question will tell you more than any dashboard ever will.
I wrote a deeper technical take on this over at IoT World