Why IoT projects fail in the planning phase (and what to map before you start)

Most IoT project delays don’t start during execution. They start in the planning phase — or more precisely, in the things nobody planned for.

After managing IoT and smart metering projects across several countries, I’ve noticed the same gaps appearing at the start of projects that later run into trouble. None of them are exotic. They’re all things that could have been mapped before the first sprint or milestone was confirmed.

The hardware lead time problem

Every IoT project involves hardware procurement. And almost every project I’ve seen underestimates how long that actually takes.

The issue isn’t that vendors lie about lead times — it’s that their quoted timeline assumes ideal conditions: no spec changes after the order, smooth customs clearance, and a first-time supplier relationship that works exactly as expected. In practice, at least one of those assumptions is usually wrong.

If you’re sourcing hardware from a country with complex import regulations, add at least two weeks to whatever the vendor quotes. If you’ve never worked with this vendor before, add three. This isn’t pessimism — it’s the pattern that repeats across projects.

The more useful question to ask vendors isn’t “what’s your lead time?” It’s “what happens if there’s a spec change after we place the order?” and “have you shipped to this destination country before?” The answers tell you more about the real timeline than any quote.

Compatibility that was assumed, not tested

The second failure mode is system compatibility. Almost every IoT project integrates with existing infrastructure — a SCADA system, an MDM platform, a billing system, a legacy meter installation.

In project kickoffs, compatibility is often listed as confirmed when it’s actually assumed. Nobody has tested the integration in a real environment. The client’s IT team says it “should work” because the protocols are compatible on paper.

“Compatible on paper” and “working in a real environment” are different things. The discovery that they’re not the same usually happens during integration testing — at which point the timeline has already been set and commitments have been made.

The fix is straightforward: before confirming any dates, ask explicitly who is responsible for validating compatibility, and whether they’ve actually done it in a staging environment. If the answer is no, that’s a dependency that needs to be closed before the project starts.

The HW/SW synchronisation gap

Projects that run hardware and software development in parallel — which is most IoT projects — have a structural problem that’s easy to underestimate.

The software team can often run in Agile, moving through sprints independently. But some of those sprints depend on having working hardware to integrate against. The moment the prototype is delayed, those sprints are blocked. The software team can’t do integration testing, can’t validate firmware behaviour, can’t simulate field conditions accurately.

A four-week delay in hardware prototype delivery doesn’t just delay one sprint. It delays every sprint that depends on integration work — and it tends to compress testing time, which means quality suffers at the end of the project.

The most useful thing a project manager can do here is make this visible before it happens. Map which software sprints depend on which hardware milestones. Share that map with both teams at kickoff. It doesn’t prevent delays, but it means nobody is surprised when a hardware slip affects the software timeline.

The field deployment reality gap

The final gap is between how the client describes their infrastructure and what actually exists in the field.

Clients describe their infrastructure as it was documented, or as they remember it. What exists in the field is often different: older firmware versions, non-standard installations, building access that requires coordination with third parties, connectivity that looks fine on a coverage map but doesn’t work in the basement levels where the meters actually sit.

A field visit before committing to a deployment schedule is almost always worth the time. Not a comprehensive survey of every site — just a representative sample that tests the real conditions the installation team will face. The issues it surfaces are always cheaper to solve before the deployment starts than during it.

What this looks like in practice

The planning documents that actually prevent these failures aren’t complicated. They’re mostly about making the right questions explicit before the project starts, rather than discovering the answers during execution.

A dependency map that separates hardware lead times, compatibility status, coverage validation, and vendor working styles makes gaps visible early. A risk register that includes the real warning signs — not generic risk descriptions — gives teams something to check against weekly. A timeplan that shows HW/SW dependencies explicitly means both teams are working from the same picture.

None of this prevents hardware vendors from delivering late, or field conditions from being different from what was described. But it means the project team sees those problems coming, rather than discovering them when the timeline is already committed.

If you’re working on an IoT project and want practical templates built around these planning gaps, I’ve put together a planning kit based on this experience: managedbyana.com/iot-project-planning-kit