IF you’re coming from the “Top IoT Hardware and Development Companies in Europe” post – there is no list in this post. It’s more focused on the general topic. of pilot projects.
“Who is paying for my time?”
When you’re looking at pilot projects, there are plenty of things that can go wrong. The chief piece of information value to the tech team is: Who is paying for my time?
Once that is cleared up, work can begin on the technical side. Those developer hours are often contested. And both sides need a paper and audit trail.
“The client comes with a perception – that everything is “easy.” You’re experts. If you’ve already done it before, the same scope should fit my project. I’m not paying for developer time on a product that already exists …”
You will have egotistical clients and difficult managers. The tech world is not immune from this universal fact. Someone wants something that is impractical within their budget, time or quality constraints. It takes a lot of tact to be able to deliver negative information. Often they do not want to hear you, because they don’t trust you with their “baby.” Communication is key – but even more so when nobody knows how to build it.
The technically minded CEO knows that no two projects are ever the same.
Risk is the big one…
Risk is a big one for corporations. In software a 10 unit rollout will pretty much define the behavior of the product at scale. In IoT, a 10-unit pilot often can’t surface the problems that only show up at scale.
Large companies are optimized for repeatable processes with predictable unit economics. A remote location or marine IoT pilot is almost definitionally unrepeatable. Every site has different environmental conditions, different access logistics, different connectivity options.
“Corporate IoT pilot projects have a famously high mortality rate, with over 70% of initiatives never making it past the proof-of-concept phase.”
Google AI
Hardware has no hotfix
This idea that hardware has no hotfix is layered. Deployment is putting a box on a pole, electrical pylon or roof in the real world. A box is subject to everything mother nature can throw at it. Inside the box, the hardware has to work in an environment of radio signals just as complex as any highway traffic system; a soup of electronic noise. A rural location has a lot of foliage and heat during summer months and damp cold weather in winter months. Electronics don’t like either.
Connectivity
Connectivity is the product, and it’s the hardest thing to pilot cheaply. Cellular/LoRa/satellite and sensor calibration under real environmental conditions. Power constraints under daily duty cycles are things you can only validate on site, but “on-site for marine, undersea, or remote sites is exactly where testing is most expensive.
This means:
Pilots can’t be handled by a standard sales/delivery playbook. They need a communicative engineering-led engagement. It is always a problem having business people doing technical things, but even worse are the political players. That is oil and water. Big companies are organizationally bad (and time expensive) doing pilot projects because of their corporate structure.
IoT pilot cost doesn’t amortize the way a software POC does. You can’t reuse most of the learnings for the next site if every site is physically different. It is hard to sell this idea to a sales team that is working on a commission or percentage basis. Internally, a pilot with a long, uncertain path to “prove it works” is hard to defend in budget cycles measured in quarters. A marine deployment might need 12-18 months just to see one full seasonal/environmental cycle.
Hardware has to survive reality
Hardware has to survive an uncontrolled real world. We’ve made mistakes with enclosures, product design, siting positions, energy consumption. You can over build and under build products. Sometimes both at the same time, by using the wrong materials or in using the wrong design layouts. A recent example was ambient heat generated by the placement location of a unit (under a vehicle), interfering with a temperature sensor that unit contained, resulting in faulty reads when the vehicle was in motion.
We’ve made wearables unwearable due to building a unit that fits general use, but not the specific use case of in-patient hospital gowns not having pockets. Clients have made bad assumptions on scope and scale, requiring far less data, less often, than initially projected, resulting in complete project redesign when time is money.
Mistakes make us better at what we do; delivering customer driven IoT projects on time and in budget, while honing in on the “needs” of each specific project, but we need to own those mistakes and figure out workarounds. This requires agility and “trust” in the “team.”
Why does this differ to more financially secure giant companies? Because their risk profile, career ladders and business models are configured to avoid failure (at all costs), to assign blame to other departments, moving accountability down and out, instead of upwards and in. Stakeholder politics and R&D are a bad combination.
Reputational risk is asymmetric: A failed pilot with a marquee client in a visible sector (marine, defense-adjacent, water, energy) is remembered much longer than the (expected) successful ones. They play a different game. Shit sticks to your fur in the corporate world far more than in engineering teams, where failure is often a key learning model. Think – failure is highly visible, success is usually hidden until full rollout, there is an assumption of “competence”(We trusted You!!!), flaws are magnified and it is a blame game.
“Bravado, chutzpah and buzzwords light the path to zombie projects, a hill of mismatched hardware and the sucking quicksand of recriminations, swallowed by a quarterly report.”
findyiot.com/blog
