Hi Everyone. I hope you are enjoying the day so far.
My name is John Savage and the topic I will be covering today is the rather difficult journey of getting your IoT concept to a concrete project in production.
A significant number of people in this room have a deep understanding of one or “slices” of the IoT stack, but bringing all the components together into a working solution remains one of the biggest challenges in the IoT space.
There are many varying perspectives on IoT and even what an IoT project is, so to set the scene, this discussion is in the context of organisations embarking on an IoT journey that have finite resources . If you’re google, you can probably afford to figure this out as you go along!!
We are a custom software development house that acts as an SI in the IOT space.
We bring together multiple partners and provide a single unified solution to our customers.
An example is an industrial IOT project in automotive manufacturing whereby we are driving the project entirely and coordinating the efforts of four external suppliers in partnership with Dell and Intel
We have turned down more IOT projects than we have started. Here are some of the things we look for.
The main challenges we have seen in IoT projects over the years have fallen into one of these three categories and I’ll go into a small bit of detail on each.
While these may appear to be common-sense pitfalls on any projects, they seem to plague IOT projects in particular. So lets look at these in more detail…
So for starters, don’t let the techies rule the roost! And this is spoken as a true techie myself.
We have a phrase at Action Point, which is “IoT is a great solution looking for a problem”. IoT itself has become a big thing primarily because of how “easy” the hardware and software building blocks and connectivity have become. Plus, it’s really cool for a software guy to dabble in hardware and vice versa!
But, at the end of the day, someone has to pay the bills. Make sure there is a clear understanding within and throughout your organisation as to why you are building the solution.
And note that direct revenue may not always be a goal. For example, we worked with AGA Rangemaster to build an IOT solution for their ovens and the explicit objective was to raise market awareness of their product in the 20 to 35 year-old demographic.
Essentially, make sure the objective is clearly understand from an ROI/business outcome first and then let the technology row in behind.
Action Point’s input into an IOT project is often the first technical input and there can be quite a significant “expectation management” activity with the non-technical people that have driven the project to date.
The IoT space is filled with amazing 10 minute demos that show how a number of hardware and software building blocks can just be plugged together to build an IoT solution. However, to build a commercially ready end-to-end IOT solution that survives when it meets the real world, you will need a lot more than what these solutions have to offer and significant effort is required to coordinate all the moving parts.
The practical elements of implementing an IoT project and bringing all the components together is extremely complex and will impact all elements of your business. As a non-techie, you need to be prepared to scale back on what you have heard is possible and understand the power of building a Minimal Viable Product.
An MVP is an initial fully functioning system that proves the techies can do the job, while also giving non-techies the chance to see a working system in order to prove the viability without huge risk.
From the side-lines, IoT projects look easy. Can we think of anything else that looks easy until you try it?
You will need to balance your technical teams detail oriented approach with your non-technical and commercial teams’ top-down approach in order to ensure you get the best from all members.
Find the Balance.
Now that your team is perfectly balanced, who will drive it?
Sometimes the key stakeholder in an IoT project is actually quite unsure of what they are getting into. For example manufacturers hear an awful lot about IIOT and Manufacturing 4.0, but what are the concrete benefits for them? Traditional Software projects enable new functionality or products so are quite easy to conceptualise. However, many IoT projects focus on gathering more data… but Why? What is the exact benefit they are going to get? And Manufacturing are the easy stakeholders to work with!
Another tentative stakeholder is the one that is not in the room. The general public in large civil projects such as smart cities. Sometimes Smart City projects have to take a “If you build it, they will come” approach, but for those of us with finite budgets that’s a scary proposition.
Smart Cities are also an example of a common IOT issue where the operational stakeholder (i.e. user that gets value) is different from the financial stakeholder (the guy that pays). If there is a conflict between the operational and financial stakeholder groups, how does it get resolved?
Ultimately job of the stakeholder is to guide and fund the project. If this role is not a driver, then the project can be in serious trouble.
So you have to help the stakeholder get comfortable. And what is the one question a stakeholder will ask to put his mind at ease?
So how much will “it” cost?
We have been building custom software for over a decade and are well used to the “how much will it cost” question. Once we’re 15 minutes into our initial conversation we know it’s coming and we always have the same line back, which is “ we don’t yet know what it is, so we can’t say until we work closely with you”.
IoT projects differ from the usual business-process projects in that “it” is very often a vague vision or accidentally huge in scope. As such, for IoT projects, we refer to the “budget journey” rather than the “budget process” and here’s why.
An example project is a smart lightbulb company that we met almost a year ago. They came extremely well prepared for an initial meeting. They had a sample lightbulb that had an embedded chip in it that supported all required functions and they had loads of very specific screen mockups of the app they wanted for the client.
They described the app in detail and it had screens for doing all the really cool things like grouping bulbs, fading them, changing colour, defining moods and so on.
“Lets build a mobile app that connects to a smart light bulb” – that’s easy right?
We had a 1-hour conversation with them that changed their world.
As you can see from the slide, there were a lot of aspects to explore once we stated talking through the full product lifecycle. I won’t go through all of these, but two in particular jump out.
The first is the question of exactly how does the App connect to your lightbulb. This would have a significant cost impact on each unit. If it were to use Wi-Fi, it would almost need a screen so it can be configured onto the home users WiFi, which is impractical. If it were to use Bluetooth, it might not have the range for all bulbs in the room, let alone the house. Sigfox would work great for energy consumption reporting but might be too slow for quick control/dimming commands. If a wireless mesh network was used, then some sort of gateway would need to be sold into each property with bulbs. WiFi, Bluetooth, Sigfox or Gateway. All a have a significant manufacturing impact.
The other major question that was a surprise was customer service functionality. If this system is being used by the general public, they will have queries, so how will you answer these? You’ll need functionality that will allow the CS team to see all information relating to a customer’s activity. Even your business model impacts here because if there is e.g. an annual charge, then the CS system will need to support billing queries.
As you can see, there is a lot to consider and while not all are relevant to every project, it is only with hard-won experience that you can quickly enumerate all your potential cost centres on the project so you can even begin to quantify budgets and priorities.
So…. Estimating the scope of work in an IOT project is difficult because it’s full of unknowns.
Does anyone know what this is?
Yes/No?? It’s the Drake Equation which was put forward in the 60s to try to estimate how many alien civilisations could exist in the universe.
The real value of the Drake Equation is not in the answer itself, but the questions that are prompted when attempting to come up with an answer. It gives you a very solid structure to use when contemplating an otherwise impossible question.
So…
Is there a “Drake Equation” for your IoT budgets? We tried and it was a whole lot more complicated than the neat equation on the previous page, so by some measures it is more complex than estimating how many ETs are out there!
At the highest level, there are 7 major components to consider, which largely correspond to the common IoT stack you are familiar with. The real challenge is that these are not independent factors. For example, you can get away with really cheap inefficient software at the edge if it is balanced by the cost of more expensive edge gateways and much more connectivity bandwidth.
A lightweight Analytics requirement might enable significant quantities of data to be dropped at the edge, but a comprehensive Analytics requirement might need all data to be warehoused.
Layer on top of this the complexity of a project goal that could be simply be to prove a concept or to build and deploy a system into a city of 100,000+ people and you begin to see the complexity involved in understanding the overall cost of an IoT project.
So estimating a project budget can be a bit of a beast… one might even say an elephant….
So how do you eat an elephant? One bite at a time!
We can’t overemphasise the power of an MVP approach to building an IOT project. But do your MVP right! Make sure that each step in your MVP delivers something fully usable.
If your MVP focuses on just the hardware or just the cloud, then you are not going to deal with the main IoT complexity, which is how all the layers interact with each other. It is only when you try to build a very narrow piece of functionality that goes from end-to-end will you truly know you have cracked the IoT nut.
In Summary, I hope that I have given you some insight into where the complexities in IOT projects lie. I purposely didn’t do a deep dive today into any particular technology because its not necessary. The building blocks are there, the experienced partners do exist. Each layer of IOT is easy and accessible, that’s one of the reasons it’s so exciting. The real challenge lies in how to bring it all together into a single coherent solution… that is commercially successful!
The final piece of advice I would leave you with is that the IoT space is one where you absolutely have to bring in “partners” rather than “vendors”. Your requirements will almost certainly change and you need to work with people that will join you on that journey and enable your success.
Thank you for your time.