Dear authors of the Ignite | IoT methodology,

before I start my rant, let me congratulate you on the first publicly available IoT methodology. The increasing importance of IoT requires such a methodology. Your book and web site are an extremely valuable contribution.

However, I do have one major issue with your approach – and this is very close to my heart. As you are correctly saying, IoT projects are multi-disciplinary and thus an IoT methodology has to combine multiple skills and disciplines. Most experienced project managers will agree that this alone represents a huge risk. In addition, current IoT projects usually have to deal with a lot of new and (b)leading edge technologies, which further increases the project risks. Of course these big risks are coming with huge opportunities; but these risks will have to be managed effectively, nevertheless.

The issue is that in my opinion your simplified Plan/Build/Run methaphor implies a waterfall approach to IoT project management. To be fair, you are also stating in your introduction that Agile is one of the different options for the IoT project manager. However, you don`t seem to be making a strong case for it.

The Plan/Build/Run metaphor might work on an abstract management level, and it is not wrong in principle. However, I do think that it is an oversimplification, and a very dangerous one as such. The danger here is that management can easily get the impression that it would be possible to create a complete and detailed plan for such a high-risk undertaking like an IoT project – and that the only challenge then is to execute this plan step by step. If this is built into a methodology, then I am not surprised that I am still finding projects which follow this approach.

The summary of your Plan/Build/Run approach describes that an IoT project is like any other project, starting with an initial planning phase, followed by a phase that results in the initial release, followed by rollout and maintenance.

NO! PLEASE STOP THIS! A phase always relates to a period in time. Consequently, a planning phase has to be understood as a period in time during which all you do is planning, but no building. And the build phase implies that all you do is building, but no planning. I really do hope that this is not what you are implying!!! Plan/Build/Run should not be seen as phases, but rather as disciplines. Because in reality your have to actively plan until the very end. And the build process should hopefully also start from the very beginning.

Of course, the Agile approach also knows phases. However, the phases (i.e. periods in time) are not so much defined by the tasks which are to be executed. Instead, these phases are defined through other characteristics, e.g. goals and priorities, types of artifacts, team structure, etc. This is why these phases are called differently in an Agile approach.

Also, there was one other statement in your introduction which made me nearly angry: “fixed price projects are often using a waterfall approach”. Unfortunately, this equation “fixed price = waterfall” is supporting those laggards who still claim that you can`t do fixed price with Agile. Which in my opinion and experience is complete nonsense!

Don`t get me wrong: Design-to-budget is a completely legitimate requirement. However, fixed price is not a question of a finalizing the detailed design upfront, but rather a question of stringent prioritization throughout the project. And this is exactly what Agile was invented for. I would claim the exact opposite: using an Agile approach for fixed price projects significantly increases the chances for success!

Fair enough: There are still some (especially large) companies out there that frequently use the waterfall approach. However, in my opinion a new methodology should aim to improve the world. So why not make Agile the standard for IoT projects? My well-meant criticism is that instead of stating a clear position in favor of Agile for IoT, your are trying to be open for every everything. And you shouldn’t: The Agile approach aims to make risks manageable. The strength of Agile is exactly in highly dynamic situations with many unknowns – so where if not in the IoT should it be the default?

My recommendation: Make Agile the default for Ignite. And add a footnote for nostalgics that the traditional approach is also supported, but not recommended for IoT.

Best regards,

Christian Weiss