Plan/Build/Run

Planning, building, and running an IoT solution will, of course, be different from solution to solution. However, we believe that there are some commonalities between IoT solutions which allow us to make certain assumptions in terms of what a generic, methodological approach should look like. We will first discuss some of these assumptions before discussing our approach in detail.

Assumptions

In the first part of this book we have already discussed some of our basic assumptions with respect to the key elements of an IoT solution, such as the focus on assets and related backend services (see the “Enterprise IoT” section in the introduction.) Another key assumption we are making is that an IoT-solution project will be similar to almost any other project in that it will involve an initial planning phase, a phase during which the initial release is built, and a phase during which the solution is operated, maintained and enhanced – hence Plan/Build/Run.

The project team will select a project management approach depending on the given situation. If the project implementation will be outsourced on a fixed-price basis, chances are that a more traditional, waterfall model will be applied. In this case, an RFI (Request for Information) will be issued as part of the “plan” phase, followed by a legally binding RFP (Request for Proposal.) Another team might decide to apply an agile approach, by leveraging SCRUM as a methodology, for example. In this case, the project specifications will be based on user stories; these constitute the main input for implementation sprints and are managed in a central product backlog. These user stories are usually relatively fine grained and are ideally produced on demand. However, most agile approaches also use higher-level specification documents to describe the overall solution from a functional and architectural perspective. So, in a sense, agile projects also involve a “plan” phase (sometimes known as a “sprint zero”). Depending on the type of agile approach chosen, the “build” and “run” phases of the project can differ. For example, some agile projects are closer to the traditional approach, focusing on major releases and including long test phases. This is sometimes also referred to as a “wagile” approach, i.e. a combination of waterfall and agile. Other agile projects very deliberately try to adopt an approach where sprint results are deployed continuously.

Another common approach to project management is the V-Model. This is popular, for example, with government-run projects in central Europe. And there are many others, from PRINCE 2 to the Rational Unified Process (RUP.) However, as a general rule, we believe it is fair to say that a generic Plan/Build/Run perspective can be applied to all of these different approaches.

Approach Taken

Given the need to support all of these different approaches to project management, the Ignite methodology focuses on what we believe is specific to an IoT solution, leaving it to the project manager to combine it with their project management model of choice.

In terms of project structure, the Ignite approach builds on the high-level structure illustrated in the figure below. The first thing we can see is that there is a distinction between the assets themselves and the IoT solution. Design and manufacturing of the assets is not typically within the scope of the IoT-solution project. However, it is essential to recognize that the interface between the organization responsible for the asset and the IoT-solution project is extremely important. This is true in situations where the IoT solution is integrated with the asset after the initial design of the asset (“retrofit”), as well as in situations where the asset is designed from the ground up to support one or more IoT solutions. In either case, the IoT solution is likely to depend on certain “on-asset” hardware and software which define the solution’s interface to the backend services.

Another key element of the Ignite | IoT Solution Delivery is the assumption that a typical project has an initiation phase and a main implementation phase. The initiation phase starts after the business case has been approved and the organization has given the go-ahead for the project in principle. During this phase, there is usually a relatively small team working on the project, i.e. this is before the ramp-up of resources.

This phase is followed by the main implementation phase. The Ignite approach for this phase is based on a concept that we call “workstreams.” This is a top-level structure that applies across the main project. In PMI terms, the workstreams would be the top-level work items in the work breakdown structure (WBS). In our experience, the term “workstream” better reflects the usually highly dynamic nature of IoT project management with all its different stakeholders and dependencies.