English | EN 
With more and more organizations using the Internet of Things (IoT) to connect devices, systems, physical objects, and data, how do you ensure that your investment in connected products really does give you an edge over the competition?
It appears that, despite their promise, a vast majority of IoT projects are non-starters in that they never go beyond the initial discovery or Proof of Concept (PoC) phase. According to some analysts, the figure stands at 75% of all IoT projects currently undertaken.
So, how do we transform this situation and go from a point where 75% of all IoT projects are failing to a world where there are 50 billion connected devices by 2020? I believe that the key to achieving success is not just accomplishing a successful technical PoC, but also demonstrating business value by creating a successful Proof of Value (PoV).
Companies usually start their IoT journey by first conducting a PoC with the assumption that when this is successful they will move on to fully-fledged production. And yet, more often than not, even though the PoC is a technical success, the full implementation or rollout ends with several aborted attempts at IoT adoption. We believe the roots of this failure can generally be traced back to how a PoC is set-up and executed.
The solution is to get it right from the start and here are my 6 best practices for ensuring your IoT connected products projects move from PoC to post-implementation success.
1) Demonstrate business value
Many organizations struggle to make money from their IoT projects because the PoCs have an excessive focus on proving the technical feasibility of a project, rather than its business feasibility. However, we need to remember that technology is merely an enabler to a bigger goal, which in most cases is profitability.
Currently, PoCs are typically the responsibility of R&D departments. That’s where they begin, and business hardly ever gets involved. This is a big mistake.
As an example, we recently worked with a medical devices company manufacturing X-ray machines. Our brief was to conduct a PoC for enabling the company to consistently predict the failure of X-ray tubes with an accuracy of at least of 96%. We worked with the R&D department and were able to meet the technical requirements fairly easily. However, what was a lot tougher was proving its business value because the interaction with the business team came fairly late in the process. Yet this was the team that would have to take the product to the end-customers. Convincing this team of the benefits turned out to be a much larger task than merely proving the project’s technical feasibility.
Now we recommend involving the business side right at the beginning of every project and setting up a PoV. This will enable use cases to be worked out that are easily demonstrable, add value and can be taken to the customer for a quick win.
2) Insist on high quality, accurate data
Normally, when we start a PoC, we receive input data from our clients. Such data could be based on past data from their customer service centers, or log data, or data generated by their internal systems. To prove the use case, this data needs to be of extremely high quality. However, due to a multiplicity of factors, we often find that’s not the case.
Additionally, when we generate data during the PoC, we can be pressurized to use low-quality sensors. This is mostly due to budgetary constraints. Clients often feel that once the project moves from PoC to actual production, then they will get better sensors. This ignores the fact that using low-quality sensors will give low-quality data and this, in turn, might lead to incorrect inferences and anomalies in the results.
The learning here is that great care should be taken with the data on which the PoC is based.
3) Testing for scalability must go beyond simple extrapolation
When testing for scale during a PoC, it is extremely important to use appropriate simulators to get accurate results. Simple extrapolation will not do. If a team has 50 devices and wants to test for 5,000, there is a temptation to just copy the same data 10 times to arrive at the results. Unfortunately, this is not the way 5,000 real devices might work. Instead, a simulator is needed to correctly replicate that behavior.
The issue is that using a simulator increases project costs. Also, if the team is geographically distributed, simulators often have to be shipped to various location, increasing the time taken for the PoC. To avoid this, teams often take shortcuts by simply extrapolating data for a larger number of devices. However, this tendency must be avoided to ensure any degree of confidence in the PoC results.
4) Invest funds and time in your PoCs and PoVs
PoCs typically work under tight time and cost constraints, leading to rushed technology decisions. However, a quick-shot PoC is usually very short-lived. If you do a PoC in anything like 8-10 weeks and expect the results to dictate your long-term strategy, you might start a project that hurts you in the later stages. Why? Because 8-10 weeks is simply not enough to do the level of due diligence required for a long-term strategy.
I saw an example of this in one of our recent engagements with a smart toilet company in Australia. They had made exactly this kind of a mistake with their previous vendor and were now in a situation where they could not scale their project to more than 5,000 toilets per installation, per server. This had restricted their ability to bid for smart cities projects in Australia. They came to us to remedy this and we did a PoC for close to 16 weeks, coming up with the results necessary to support their business in the long term.
5) PoCs must be a multi-disciplinary effort
Although I have already talked about this, I can’t stress it enough – any IoT PoC project must be multi-disciplinary from the outset. Our observation is that most of the time, a project is won by the sales team with the target customer coming from either the business or the R&D division. However, very rarely do we get a project for a PoC which starts with the involvement of both departments. Such projects usually meet the expectation of just one party.
For example, we were working with a company making pneumatic pumps and did a PoC for one of their plants in North America. One part of this involved measuring the vibration analysis for a specific type of plant. Unfortunately, it was only after the completion of the PoC that we were given inputs by the business team and realized that they had a roadmap for the product that was going to add more features apart from vibration. Ideally, we would have tracked multiple parameters during the PoC for it to provide actual lasting value to the client. Thus, we now always insist on the involvement of a multi-disciplinary team before we start any PoC.
6) Do not ignore security during PoCs
IoT security is undoubtedly critical. Unfortunately, this is an aspect that often gets overlooked during the PoC phase, with teams starting to look at security only during the actual implementation. However, the security architecture is key and ignoring it can have serious business ramifications. For example, consider home automation systems company Nest who discovered its systems could be hacked, potentially leaving consumers vulnerable to cyberattack.
Security is crucial for IoT-enabled devices and expecting architecture that was originally built for a PoC to address such security concerns is not realistic.
In summary, as the pace of IoT adoption picks up in the coming years these six recommendations will help to improve the success rate of IoT projects. Move beyond PoC to embrace Proof of Value, which takes a holistic look at the technical and business feasibility and considers the long-term aspects of scalability and sustainability.
