Project Initiation

What usually happens in parallel to the development of the detailed business plan, is an evaluation of the ideal organizational set-up and execution strategy. In addition to the important time-to-market factor, one has to look critically at internal execution capabilities. Again, this comes back to the “machine camp” versus “Internet camp” discussion in the introduction – Which direction are we coming at this from? And where do we need to end up? Will we be able to develop the required culture and capabilities internally?

Based on these kinds of questions, the steering committee will have to make a decision about the best way of managing each IoT opportunity. Typical options include internal projects, external acquisitions, or spin-offs. Also quite common is a mixture of these, that is, to set up an entity that consists in one part of people with strong roots in the larger enterprise, and another part of people that came in through acquisitions. Also, the term “acqui-hiring” has become popular recently, describing a strategy of acquiring companies, less for their products and customer base than for their team and talent.

Careful attention has to be paid to organizational set-up, especially for IoT opportunities that are developed by leveraging existing internal organization. In particular, the interfaces and relationships between the solution team and the existing asset organization are essential.

At Bosch, there are more and more cases where “podular” organizations are set-up on the business unit level as well. “It is easier, if there is already a home port for the ideas within the organization,” says Ms. Silke Vogel. “This way, the employees, who have worked on the idea refinement and business model development, can drive the projects in the execution phase as well.”

IoT Center of Excellence

If the company sees IoT as a long-term transformation, then the setting up an IoT Center of Excellence (CoE) should be considered to guide and expedite this transformation. Based on the description of the typical functions of a CoE [AE1], an IoT CoE could look as follows:

• Support: An IoT CoE should support business lines to realize IoT opportunities through the provision of IoT consulting services. These services can include IoT business case creation, IoT project setup, and IoT project execution coaching. As authors of this book, we are slightly biased, but we would naturally recommend the Ignite | IoT Methodology as one possible foundation for such services.
• Guidance: An IoT CoE should help to define the necessary standards, methodologies, tools, and knowledge repositories. Some of these will be highly vertical-specific. However, things like best practices for setting up things like a remote communication infrastructure for mobile assets could be standardized (see Ignite Technology Profiles for examples)
• Shared learning: Training and certifications, skill assessments, team building, and formalized roles are all established methods that can be applied to developing IoT capabilities.
• Measurements: An IoT CoE should create IoT-specific metrics and maturity models that help make the progress of the transformation more transparent.
• Governance: They should support the Steering Committee with the cross-project coordination and other detailed governance tasks. Especially in the connected IoT world, there will always be many cross-dependencies between projects that need to be managed carefully.

Naturally, running a dedicated IoT CoE will be a significant investment, and many companies report mixed results from their other CoE initiatives. It is important that the CoE is seen by the projects as value-adding, and not as a disturbance. There are usually two options for the setting-up of the CoE: a dedicated CoE resource, or a virtual CoE with members who are embedded in operational teams but are allowed to spend a certain percentage of their time in supporting the CoE. The latter has the advantage that the CoE experts are coming from a hands-on project background with a lot of experience, but has the disadvantage that these highly respected experts are often drowned in project work and can’t really fulfill their part-time CoE role as much as needed.

IoT Platform

Finally, enterprises embarking on the IoT journey should consider investing in the setup and operation of an IoT platform which can be shared by the different IoT projects. Such a platform could comprise of the following:

• Remote asset connectivity, e.g. based on the M2M platform of a telecommunications carrier or an MVNO (Mobile Virtual Network Operator) (see Technology Profiles, M2M/IoT Communication Services).
• IoT application development and runtime (see Technology Profiles, Platforms & Enablement)
• IoT data management infrastructure (see Technology Profiles, [Big] Data and Process Management)
• IoT security infrastructure, e.g. central identity and certificate management (see Technology Profiles, Security)
• Standards, e.g. for communication protocols, etc.
• Asset interface repository, e.g. a central Wiki to describe the functional and technical interfaces of different device and asset types that play an important role in the organization

Theoretically, providing such an IoT platform should be seen as a blessing by everybody needing to get a project off the ground quickly. However, we should definitely be aware of the inherent risks of such a central platform approach. One of these is that the platform might actually not work (e.g. because it is over-architected and not field-tested). Or it might not be ready on time. Or it might be inefficient and too difficult to operate. These are just some of the real risks involved in developing a central platform. On the other hand, if this needs to be done for each individual project, there is also a real risk that the project team won’t get it right half the time. So the sensible thing to do would be to observe those initial projects that seem to be developing the best platform approach, and then identify the parts of these projects that can be generalized. So it really is a question of maturity and timing.

Summary and Conclusions

As we explained at the start, some of the processes and methods described here are very generic and need to be adapted to the vertical needs and specific circumstances of the individual organization. For some companies, the elaborate way of developing a detailed business model as described here may seem like overkill. However, we have seen many examples where such business model development took significant time and many iterations – especially for solutions that need to be embedded into existing, large-scale, complex ecosystems.

Particular attention needs to be paid to the organizational structure of the project. IoT projects almost always require multi-skilled and multi-cultural teams. Aligning the “machine camp” with the “Internet camp” is a challenging task. One possible approach is described as follows by Joe Drumgoole, Director at MongoDB, Inc.: “The Internet of Things provides a framework for both these communities to interact. If [large players] can create a bridge between those worlds, they will be successful but I think success will come in the context of early wins with a small number of partners. Lead with the Internet people and use them as a foil to provoke the manufacturing people into action.”

Another important thing to consider is that business plans for early-stage start-ups or projects rarely survive the first year without major modifications. So supporting an Agile (this does not mean unstructured or uncontrolled!) development approach will be a key success factor for most IoT initiatives. We will address this in more detail in the next section, the Ignite | IoT Solution Delivery methodology. This methodology is designed to support the next phase for those IoT projects that have managed to come through the strategy selection process with sufficient funding to start implementing their ideas and vision.