Risk Reduction in IoT Projects

IoT Projects involve a number of elements that really need to fit and ideally be optimised to produce the best business result.

There is seldom any doubt that more information may result in better management however the ROI depends on what will be learned and done and exactly the investment required is to operationalise the information acquisition. 

Common risks stem from:

• Allowing off the shelf devices to determine your solution (or worse still your requirements) — as the exact match of sensors, qualities of service, configuration capabilities, diagnostics, etc. may not exist. An off the shelf device may notionally do what is needed but they often come with an overhead (i.e. the off the shelf devices might be overspecified and not optimised) 

• Expecting subject matter experts or business users to say exactly what information they want, with what accuracy, how often, with what reliability and to explain what they will do with, and what value it will be  

• things will be overspecified e.g. 5 nines delivered and paid for when 2 nines is completely adequate (and an order of magnitude cheaper) e.g. reliability, accuracy, etc. satellites, relays, adaptive spreading factor, etc.

• Relying on compelling slide deck presentations (that everyone interprets as addressing their needs) that duck the devil in the details so that what is implemented is too expensive, too poor a fit, etc.

• Assuming that knowledge of traditional enterprise IT technologies and practices will work in a domain where hardware, network and operating systems (firmware) can all be bespoke.

• Expecting network utilities not to seek capture and allowing them to convince you you should use a cellular network model instead of a wifi network model (as some once did with wifi).

Many people want to pretend that these things can all be worked out in the abstract but as with so many things in life, often a simple experimental ‘suck it and see’ approach makes sense and everyone is educated on the journey. 

These experiments only make sense if there is a guaranteed path to scaling and operationalisation.  A proof of concept not based on a long-term approach won't help validate the true costs. Essentially, thinking an agile approach can be applied to producing an end to end solution is mistaken. 

It is natural for people in large organisations to make decisions based on what seems safe, what is convenient, received wisdom, fringe benefits (e.g. corporate hospitality).  Often, over the long term, these decisions lead to:

• an order of magnitude higher operational costs e.g. when you lock into a proprietary network utility rather than your own private or hybrid network

• an order of magnitude higher establishment costs i.e. because you choose to use technologies or partners that are not specifically set up to enable bespoke solutions within the required financial and operational envelope.

We would suggest that people accept that there are both known unknowns and unknown unknowns and make a small investment to learn through doing.