Avoid IoT Pilot Purgatory with Agile IoT

The process of creating and deploying IoT solutions can seem daunting, especially when you take into account the catastrophic rate of failure that is faced by programs that get stuck in IoT Pilot Purgatory. When more than 70 percent of pilots are failing to take off, it’s hard to avoid the conclusion that there’s a problem in the process. 

One solution to the problem is Agile IoT, a product management strategy often contrasted with waterfall-style management. If you're interested in learning more about Agile IoT, Ben Wald, Founder and CEO of Very, an IoT development company, will host a webinar called Beat the Odds: How Agile IoT can get You Past the Pilot on December 9 at 2 pm, that's designed to walk you through the process and details of getting out of IoT Pilot Purgatory. 

In the meantime, we grabbed Ben for a few minutes to pick his brain on Agile IoT on your behalf. Read on for more.  

IoT For All (IFA): What is the problem with the high rate of pilot failure? Isn’t the point of running a pilot to find faults in real conditions?

Ben Wald (BW): Pilots are failing not based on the merit, viability, or real-world conditions they are facing, but because they are not set up for success, to begin with. 

Many of these pilots are a company's first and only IoT initiative. If a company were running many pilots and some of them for moonshot initiatives, I’d say - great! For these, a healthy failure rate is ideal because it shows that you are testing the edges of what’s possible. But oftentimes, we see basic pilots failing that are trying to unlock some really attainable and fundamental value.

IFA: Why should solutions developers worry about this at all? Isn’t execution and scale the problem of the implementor?

BW: We definitely subscribe to the philosophy that it’s a requirement upstream as much as possible to be thinking about the implications of decisions downstream. This means that we consider volume, scale, long-term maintainability, and rate of degradation for various components upfront. We see this being important and impactful to plans because there is a data strategy that needs to be engineered upfront. If you only consider your MVP or limited scale in your data strategy, it can be really costly to try and re-factor for that later. 

IFA: What are some of the biggest obstacles to scaling IoT solutions and products and avoiding IoT Pilot Purgatory? 

BW: When you're developing machine learning models, real feedback loops can pose a challenge. When deployed into the field, some models require feedback from people — whether it’s field technicians or app users — and it's all too easy to overestimate the consistency and accuracy of the human input.

Data transfer costs can also become a real challenge in scaling solutions. It’s easy to get excited upfront about all the things you can do with all the sensors you’ve added out in the field. The rubber meets the road on the costs of moving that data, and likely the upfront investment you’ll need to make with software and firmware to sort through and compress the data on the edge before sending.

IFA: What’s the difference between developing a pilot/test case and a solution developed with scale in mind from the outset?

BW: The biggest difference is in the completeness of the subcomponent parts successfully working together. A pilot or proof of concept aimed at validating a specific part of the solution could also be labeled as an engineer research spike. You want to vet and validate that you can do that single thing or do that thing while acquiring parts that keep the overall BOM under your COGS target. A solution developed with scale in mind is checking all the boxes. You’re looking at the viability of how all the parts need to work together, factoring in scale, and extensibility into that validation process.

IFA: How does Agile IoT lead to better outcomes in IoT solution development? How does it avoid common pitfalls?

BW: Agile IoT allows for an extreme focus on iterating and getting individual parts working, and then the whole system working, as soon as possible. Then, you spend cycles making optimizations and tweaks instead of waiting for some big release. Agile is a methodology and not an excuse for not doing the work on the business case. You still need an ROI model; you still need deadlines and budgets. But how you organize cross-functional teams and coordinate the micro-efforts is where an Agile approach can really move the needle.

To get the full download on Agile IoT and how you can leverage this strategy to avoid IoT Pilot Purgatory, join us for our webinar Beat the Odds: How Agile IoT can get You Past the Pilot, taking place December 9 at 2 pm.