How to build an (IoT) prototype, and do it right?
Sometimes it is hard/impossible to define clear functional requirements at the very beginning of an IoT project.
The business owners have a high-level concept of what is needed; design meetings are not very productive due to a lack of common understanding between business and technical participants. Finally, everyone gets tired of that initiative and project is closed. Yet another failed IoT initiative.
How is that situation related to building the prototype?
Based on my experience, the best way to keep people engaged is to show them something “that works”. That is totally fine if that “thing” works in a way that does not meet business goals. Once there is something tangible, people are more motivated to think about the actual use cases. Once they think about the actual use cases, they will be able to define business/functional requirements more precisely. Once developers get more precise requirements, they can improve the prototype.
Repeat this cycle, and you’ll have a successful IoT initiative.
How to define the initial version of the prototype?
- Use your understanding of the business domain and try to “predict” how to meet the business goal. Focus on the business outcome during every decision you make.
- Do not emotionally attach to the initial idea - its sole purpose is to initiate a dialog between business owners and technical team members; the initial design is meant to be totally redesigned from the business perspective, and that is OK.
- Lay technical foundations for future needs - leverage your technical domain knowledge to design a technical framework that will meet current and future needs; improve this framework during every development cycle.
- Avoid chasing perfection, yet do not be afraid to change something “that works” if the modification will improve the business outcome.
Internet of Things initiatives are challenging for many reasons, the best way to overcome them is to start the “actual work”. Try to avoid building something for the sole purpose of demonstration under the assumption that “we will make it right next time”. Every development cycle should build on top of what was already created.
I am not saying it is “that easy”, but it is “definitely doable” :)
