This content is part of the Essential Guide: IoT in business: Deploy a successful connected enterprise
Manage Learn to apply best practices and optimize your operations.

Avoid tech's valley of death: Advanced R&D lessons on scaling IoT proofs of concept

You won’t find the tech valley of death on a map, but it’s real. It’s how startup and R&D communities describe the perilous gap between new technology and adoption, a place littered with the bones of good ideas that didn’t make it.

Industries like defense and aerospace, where new technologies are table stakes, face the valley every day, and have done a lot of research into how to successfully get to the other side. Here’s what IoT strategists can learn from them.

The IoT proof of concept

Crossing the valley means balancing patience with strategic action. Patience is important because even the best ideas take time to develop adoption and revenue; action because new technologies need continued investment during that time. For perspective, the typical time for new defense technologies to move from research to application is more than a decade. That’s an awfully long time to support a new technology with no guarantee that it will produce the results you want. That’s where proofs of concept come in.

These small-scope projects can quickly prove out key parts of a new IoT technology, informing whether a wider implementation is worthwhile. Proofs of concept should be kept as simple as possible, focused on testing a single, pivotal point of value. Get that proof, learn from it and then move on to the next. Of course, some of these proofs will fail. In fact, according to some surveys, most IoT projects — 74% of them — end in failure. This is where it’s important to understand why.

Why promising proofs die

IoT proofs of concept typically fail for two reasons: technology and market fit.

Technology failure
Unlike aerospace, IoT failures aren’t particularly dramatic; they’re usually about data processing issues. IoT relies on complex, AI-enabled analytics, so misses in input data or training for machine learning can produce startlingly bad results. In other cases, net new proofs of concept may fail to account for integrations with real-world legacy systems. One IoT proof of concept couldn’t even work in its own office as the walls were too thick and curved for a good Wi-Fi signal.

Even when technology doesn’t just fail outright, leaders can underestimate the complexity of the IoT projects. This can quickly put projects behind schedule and over budget, likely resulting in cancellation and a plot in the valley.

Market failure
Though technology can be a vexing issue, many IoT projects fail because of the market. This can mean target consumers simply won’t use a new IoT service, or that enterprise customers remain stubbornly attached to legacy business processes despite new, efficient IoT technologies. In either case, market failures can be tracked back to common sources:

  • Poor knowledge stakeholders. Research continually suggests that the chief factors in the success of IoT systems are deep knowledge of end users and market needs. IoT proofs of concept planned at a purely technical level are unlikely to succeed.
  • Value isn’t understood. This scenario happens when the business case for a proof isn’t fully articulated, or when successes aren’t communicated to the right levels within an organization, leaving key leaders to guess at what they’re funding. Clearly communicated value is especially important when spending by one business unit accrues benefits in another.
  • Lack of plan for scaling. IoT leaders need to be ready for failure, but they also need to be ready for success. A two-person team may be fine for running a small proof of concept, but is there a plan for scaling to wider scopes and geographies, with the talent to run that expansion?

What to do about it

The good news is that the potential solutions to each of these pitfalls are pretty straightforward. The same common sources of failure can also become blueprints for success.

Fixing technology failures:
To minimize the risk of technical failures, start on the edges of the architecture. Begin with limited dependencies on the core systems and business processes that you can’t control. This can help ensure that a proof of concept isn’t stalled by technical issues it can’t influence.

Next, be clear about the value to the organization you’re trying to prove. Is it efficiency? Customer satisfaction? New revenue streams? How will that value be measured and what does success look like?

Ultimately, there’s no way to eliminate all technical risk. So accept reasonable risk, then test and iterate quickly. If you’re successful, scale (best practices for scaling pilots for digital supply networks can be useful here); if you’re not, move on to another proof of concept.

Flipping market failures:
Many market failures stem from a lack of stakeholder alignment. This can be internal (wrong sponsorship) or external (wrong partners). One solution is to bring that collaboration up front. The planning for any proof of concept should include identifying and engaging the end users, enablers and other stakeholders outside of the IT organization.

Next, think about success in terms of value, not just cost or revenue. Proofs of concept can add value by demonstrating something new or by unlocking performance not easily described in dollars and cents. Carbon fiber and other advanced materials in America’s Cup boats and Formula 1 cars didn’t immediately save or earn money, but they did make for lighter, stiffer boats and cars, and set the stage for massive performance gains down the line.

Finally, don’t just blindly expand scope or geography when scaling successful proofs. Rather, think about scaling as another opportunity to improve by fixing things that barely worked and smoothing out rough edges.

You may not be building a stealth aircraft or a space-based laser, but success is no less important to your organization. With these simple guidelines, you can approach your IoT proof of concept with confidence — and avoid the valley of death.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.

CIO
Security
Networking
Data Center
Data Management
Close