Cisco recently ran a survey which revealed about 60 percent of Internet of Things projects stall at the Proof of Concept phase with only 26 percent were what Cisco considered a “complete success”.
What were the top points of failure?
- Time to Completion
- Limited Internal Expertise
- Quality of Data
- Cross Team Integration
- and Budget Overruns
These 5 reasons for failure cover a lot of ground, and are the result of initial assumptions, lack of understanding in the process, and of course corporate infighting! I have translated and expanded upon these 5 reasons below from both a device and system structure point of view.
Poorly Specified IoT Projects cause Time Delays and Budget Overruns
An under-specified project can run into roadblocks, detours, hijacks and redesigns from a number of different sources. Here are a few “gotchas” that Hallsten Innovations has seen before:
IoT Device Development is NOT about Gluing Kits Together
In the beginning of a design process it can be tempting to think about your problem in terms of dev-kits or readily available boards fitting together like LEGO pieces. For example, “A google home is just a microphone connected to a raspberry pi”, “Intelligent refrigerators are just bar codes sensors connected to a BLE chip”, etc…
The idea that these components are “easy” to put together and interface is a notion perpetuated by the rise of DIY Arduino and other electronic platforms. When you are considering large, documented dev kits, we agree that interfacing is very straightforward.
However, don’t under estimate the complexity of a design simply because two dev kits can be plugged in together and talk for a Proof of Concept. You are only 10% of the way there.
Dev kits are not suitable for commercialization for a variety of reasons including:
- IP Ownership
- Supply Chain Availability
- Cost Effectiveness
- Design Control
- Lack of Low Level Driver Capabilities
The bottom line is that a DIY tool built from readily available items can be a future risk to your project.
Battery Life
Nothing can ruin a project faster than a dead battery. A device that needs to be out in the field for a month will not succeed on a battery that only lasts 6 days. (We’ve seen it)
So, engineering teams should be very pessimistic when doing back of the envelope calculations on battery life. Commonly, a calculation at the lowest power setting of the main processing chip and the maximum mAh storage rating of the battery to estimate battery life will almost certainly be incorrect.
This performance blunder will never get that performance! Why do you ask?
- Your chip will wake up more often than you think
- Components like capacitors and ESD diodes leak current
- Anything with a radio is difficult to estimate (try answering the question, “how long does my radio transmit for when it sends a packet?” and you will see estimates get out of hand)
So, How should battery estimates be done?
By nature, these measurements are tricky. Hallsten Innovations approaches this problem from several angles:
- Build a model for your system using data sheet values. Typically done in MATLAB, we generate different usage scenarios and use these to explore the design space.
- Measure everything. Hallsten Innovations uses high precision current measurement equipment to measure individual component power draw either on dev kits or (even better) new boards.
- Understand and test devices under edge conditions such as high or low temp, typically these data are not included in datasheets but will dramatically impact battery health and performance.
But even with all of that, give yourself a safety factor. We use factors from 1.5x to 3x for estimates.
Certification Requirements
More often than not, certification is a task relegated to the end of a design process. Hallsten Innovations recommends planning pre-certification testing early in the design process. A project delayed 6 months due to a failure to pass FCC requirements is a kick in the gut!
Planning on using Wi-Fi or bluetooth? Maybe you are planning on using an existing module. Is this module, FCC listed, Wi-Fi or bluetooth certified? Integrating approved modules can relieve some testing requirements but only if strict guidelines are in place (ie, using the same approved antenna, and going the FCC filings with the listed FCC ID).
What if you need to make an adjustment to a module or add a different radio for your project? Redesigning a wireless device for these certifications, even if the change is small, will almost certainly require a fresh certification process. Such a certification can cost between 15 and 20 thousand US Dollars, and demand weeks of your development cycle.
So, plan ahead, consult experts, and test often to avoid running into the pitfalls of missing certification milestones!
Limited Internal Expertise and Team Clashes will confound an IoT Deployment
People.
It’s funny that an Internet of Things project can fail because of people.
This spring our fearless leader Jon Hallsten wrote about The Industrial Internet of Things Reference Architecture. The IIRA document is an excessively thorough reference that outlines and helps clarify assumptions based on an IoT deployment. This document clarifies what an architecture looks like, data flow, stake holders and responsibilities.
This document of course is Industrial-centric, but can serve as an example for any type of project.
Spending even just one day reviewing the document in order to learn the scope of it’s clarifications will drastically help an IoT project deployment success rate. What I like about it is it’s balanced approach to managing the difficult relationship between IT and plant floor operations. This relationship has caused project failures for decades.
Data Visualization Expectation
Expectations of what constitutes a reasonable Data Visualization Proof of Concept can be high from project stakeholders and upper management. This is of course the end deliverable that decision makers are interested in.
Expectations of a flourishing dashboard of data with Business Intelligence recommendations, connections to CRM, third party providers, and ERP Resource Planning is a far, far way from identifying whether or not a plastic injection molding machine is running at optimum temperature, or whether the lights are on or off.
Assumptions on data visibility can hamper a project. Imagine an executive being shown project status at at the proof of concept stage and seeing but 1 or 2 data points. That’s not connectivity… that’s failure.
Hallsten Innovations suggests either working with a visualization provider (we have recommendations) that offers enterprise level and enterprise quality data visuals, or properly describing low proof of concept expecations before hand well before any first presentation. Either way – meet expectations and if you can and surpass them!
If your IoT project is lost in the weeds, Hallsten Innovations has the experience and the know how to move you from Proof of Concept and into Reality.
Our deliberateiterative proven development process can be accessed at any stage of a project. We have dozens of product wins and successful Proof of Concept successes for our clients. We bring the experience to bring you success.