Observe and Research

We begin to determine the problems that need to be solved by observing top-of-mind challenges within the lines of business and opportunities for success. We also explore emerging threats external to our company or organization. At this first stage, we are looking for potential stakeholders for projects who possess visions of what the future might look like.

To get our arms around the state of business processes, we document the current environment and interactions that take place. As we do this, we seek to identify opportunities to improve efficiencies, quality of goods, quality of services, quality of production, and/or safety. We also analyze any tools and technologies used in these processes and document how workers use information and respond. We begin to understand the importance of such tools and technologies in successfully executing necessary business processes and uncover any vested interest or reluctance to change that the users might have.

In addition to interviewing individuals, we might simply watch their actions in normal and abnormal situations, including their interactions with co-workers and systems. We might also capture these interactions through video recordings that then can be used for further study and to augment the written record of our observations.

When we document the problem solution process, including current activities and outcomes, we can present the process in the form of a journey model. A typical model that might lead to an IoT project begins with a description of how workers are informed of the status of a specific process and the problems and abnormal situations that might impact that process. Workers then decide what appropriate action is necessary if a problem is confirmed, perform some sort of action to fix the problem, and see a response confirming that the remediation action has occurred.

As an example, let’s look at a worker monitoring the soldering of components to a circuit board on a production line. They visually determine if the components are in or out of alignment. Their action could include stopping the production line, determining where the misalignment is occurring, correcting the cause of misalignment, and restarting the production line. The response would then be a validation of the return to normal production. Figure 8-2 shows how we might illustrate this model.

If the focus is only on improving existing internal processes and/or meeting current needs, we might lose sight of innovations that are happening elsewhere. Interviews with line of business leadership are often a great place to gain a better understanding as to what competitors are up to since having a current understanding of innovative initiatives in their industry is usually part of their day job.

To gain a more complete understanding of external influencing factors, a PESTEL analysis might be performed. Such an analysis weighs political, economic, social, technological, environmental, and legal factors. These factors can drive increased momentum toward more automated IoT solutions.

Relevant political factors helping to provide momentum might include tax incentives for modernization. Economic factors in play could include consideration of increased labor costs and the need to maintain or grow margins. Social factors might be driving the workforce to gain technical skills that rely on IoT-based solutions. Technological advancements could be driving a need for faster innovation to stay competitive. Environmental factors could include demands for sustainability and the need to reduce waste in processes. Legal factors might include the introduction of new regulations and laws related to safety and products.

You might determine that some independent research is in order, especially as competitors begin to enter new business areas and PESTEL-related factors influence the need for IoT solutions. Where can you find such information?

Start with quarterly financial statements and presentations to investors. Pay attention to IoT-related vision statements by leading executives and how they respond to business analysts’ questions on earnings calls that could lead to such projects. Be on the lookout for statements regarding the impact of competition and PESTEL-related drivers that are discussed during these calls.

You should also research industry and government sources of information that can provide insight into additional drivers. Pay special attention to conferences where other similar companies and organizations are speaking about their IoT initiatives and attend those conferences. Though technology vendors sometimes present compelling use cases, presentations of initiatives by business stakeholders within similar companies and organizations to your own can provide you with a great deal more insight into challenges in implementation and the true nature of the business drivers and benefits obtained. Attending such industry and technical conferences can help you determine where you should focus your own initiatives.

Problem Definition

In the previous phase, we began to uncover problems that could be worth solving and that could drive IoT initiatives. In this phase, we better define these problems and look at them through various points of view. We’ll also begin to understand what each group sees as benefits in solving these problems. And we begin to prioritize the importance of solving the defined problems.

Problems solved by IoT initiatives can impact many different stakeholders beyond the frontline workers. Business sponsors likely have their own unique set of challenges and objectives. Senior leadership in the company or organization and their partners might each have unique views regarding challenges and the problems that need to be solved. Figure 8-3 represents various points of view that could be present.

For each targeted group, we should fully understand their business goals and any tasks and solutions in place to achieve those goals today. As we gain that understanding, we should document limitations and inefficiencies that are present. We will also want to gain an understanding of each group’s desire for change and any alternative solutions currently under consideration.

In some situations, we might uncover problems that are exacerbated by inadequate skills or extraordinary physical effort required to overcome current solution shortcomings. Though training might overcome some of these problems, we should also be on the lookout for unusual worker turnover where additional training has not solved problems.

For each group, the perceived value and range of benefits in solving a problem could differ. For example, some might see a problem as one of efficiency, while others might see the same problem as a quality improvement problem. This could lead to a divergence on the vision of what ideal solutions might look like. So, the input from each targeted group might include not only broad benefits from improvement in business processes that solve a specific problem but also benefits that will be personal to each target.

You might think that in most organizations only consideration of potential return on investment drives the selection of the most important problems to focus on. However, this is frequently not the case. The time that it takes to get to a viable solution and a positive return on investment can be the determining factor when the window of opportunity for solving the business problem is short, there is a very limited budget, management is exerting pressure to solve the problem, and/or the problem is seen as an extremely dangerous competitive threat.

Sometimes, problems must be solved regardless of the ROI. For example, C-level executives might have issued forward-looking statements to investors that promise delivery of a business solution built upon IoT. Regulatory requirements might also drive the need for creation of an IoT solution to address mandates present in some industries.

Several of these factors might cause us to deprioritize certain initiatives. A project might be viewed as too costly or risky, regardless of the ROI that might be obtained. Skills could be lacking to implement or use the proposed solution, and the culture in the organization might not be ready for adoption of the technology or the solution. There could be issues regarding availability of quality data due to a lack of devices, sensors, or other infrastructure.

In many companies and organizations, multiple considerations in combination impact the determination of priorities in project funding decisions. Identifying that mix of prioritization considerations during this phase will be critical in helping you to determine which problems to focus on solving.

In this example, the company is prioritizing efforts that will increase revenue. Cost containment might also be important but is of secondary concern. So, minimizing downtime on the production lines is listed as the top priority, though we’ll likely need to add sensors to the lines or purchase new equipment to gather the metrics that we’ll require.

Ideation

Ideation is the start of solving the identified problem or problems in the initiatives. In IoT initiatives, a goal of this phase is to gather many solution ideas and determine a solution worthy of developing a prototype that will then be tested for validity in front of stakeholders and interested parties.

A variety of techniques are commonly used during the ideation phase. Often, the ideas are generated through facilitated discussions. Brainstorming techniques can be used to bring about a free expression of ideas. The focus is on gathering a large quantity of diverse ideas. No criticism of an idea or idea ownership is allowed. Group members in the exercise are ideally a heterogeneous mix of individuals (not just experts). Everything is written down and captured.

The facilitator has the important role of guiding the discussion. They might occasionally solicit different points of view intended to drive consideration of new and diverse ideas. A best facilitation practice is to ask open-ended questions. The session might begin with the question, “How might we solve the defined problem?” A question sometimes asked to spur insightful discussions is, “How might our toughest competitor solve the same problem?”

Using our earlier prioritized initiatives from our manufacturer example, we would begin by soliciting input on how we might minimize downtime on our production line. During brainstorming, ideas on how to solve this problem can be written by team members on Post-it Notes of different colors, or they might use software-based applications featuring the equivalent of Post-it Notes to share their ideas. Each team member has a uniquely colored notepad so that we can determine where the ideas are coming from (to encourage broad participation) and so that team members can track their ideas as solutions areas are defined.

A sample of some of the ideas that might be gathered in our example scenario includes video training of workers, rotation to different lines during shifts to prevent boredom, automated gathering of assembly line speed statistics, measurement of increased vibrations or abnormal variations in speed caused by equipment problems, and better understanding of bill of materials including quantities on-hand for goods production.

The facilitator will see that these and other ideas gathered fit into broad solution themes. Solution themes in our example include training of personnel, staffing model changes, better capture of metrics measuring output, earlier indication of potential production line problems, and earlier indication of supply chain shortages. Figure 8-4 illustrates how the Post-it Notes are aligned into these solution themes.

The content on the boards containing the sticky Post-it Notes is usually captured by taking pictures of the results with a mobile phone camera (if an electronic whiteboard application that can capture these results wasn’t used instead).

Some of these ideas and solution themes shown here will not lead us toward pursuing an IoT project. That’s ok as the primary goal is to solve the problem at hand, not force fit a technology solution. A vote is taken among the participants regarding the most important solution themes, and that will guide us regarding the next steps to pursue. If IoT projects don’t make the cut, we’ve just determined that funding for developing and putting an IoT solution into production later could be unlikely to occur anyways.

This brainstorming technique used during ideation is also used during other phases when design thinking techniques are used in an agile sprint. We discuss the agile sprint later in the chapter.

Further evaluation of these solution themes generally occurs before the type and scope of a prototype are determined. Proposed solutions are typically broken down into their process steps. Variants in how those processes will be executed are explored. We also document the necessary resources that are available and the resources that we must add for the project to be viable (or indicate work-arounds that might also prove to be adequate).

Let’s assume that “Automated Output Metrics Measurement” received the most votes among the team. Upon further exploration, we see that the way in which needed information is gathered today is through manual input of data into spreadsheets by production line managers. The total products produced is gathered from a counter at the end of each shift. Data regarding uptime and line stoppage reasons is manually input and subject to error based on the skills and attentiveness of the production line manager.

We’ve theorized that a more automated approach to gathering this data will help us increase production since we will be able to fix problems that are occurring much faster. We’ll also eliminate some of the waste that currently occurs because we throw away many of the products produced during production line problems.

As we evaluate the technical capabilities needed, we might decide that additional sensors can help us better measure what is really happening. Alternatively, or additionally, we might also determine that there is an opportunity to introduce cameras and use image recognition on the production line to monitor the line and trigger more immediate actions when needed.

As documented here, the pros and cons of a solution idea for solving a problem is being evaluated for technical feasibility, user desirability, and business viability. Other factors such as adaptability, sustainability, and scalability might also be evaluated.

We might also decide to evaluate each alternative by using more perspectives than simply pros and cons. One way to do this is by evaluating the strengths, weaknesses, opportunities, and threats associated with each alternative in what is often referred to as a SWOT analysis.

You can see that we’ve called out reasons why we might want to go forward with this alternative in the “Strengths” quadrant describing positive immediate outcomes from successful deployment and the “Opportunities” quadrant describing positive longer-term impacts to the company. But we’ve also called out reasons we might not want to go forward with this alternative in the “Weaknesses” quadrant by documenting the perceived shortcomings of the approach and in the “Threats” quadrant documenting the challenges that could impede the project and limit its success.

We now can compare the relative strengths, weaknesses, opportunities, and threats in the two alternatives. But how do we determine which alternative is the best one for our situation?

The better understanding that one has of the trade-offs, the more likely one is to pick the right prototype creation strategy. Based on the scoring recorded in this table in which we see that one of the alternatives received a higher score, we would likely choose to proceed with the option that both adds sensors and image recognition to the production line.

Prototype Creation

The purpose of prototype creation is to enable testing of the validity of ideas gathered in the previous phase. At this point, we have hypotheses about our potential solution(s) to the problem that we identified. Prototypes can come in a variety of types and sophistication, with the cost and sophistication of prototype creation generally aligned to the degree of commitment to solving the identified problem.

Innovators use prototypes to experiment as they formulate solutions. They expect failures but continually learn through prototyping in the most cost-effective manner possible. They see solution development as an evolutionary process but are not afraid to throw away efforts that early-on prove to be extremely difficult to implement or are impractical in other ways.

Prototype creation sometimes goes through a series of stages. An initial stage might be the creation of a storyboard describing how and what the solution to the identified problem will deliver. How the solution will change business processes might be defined. Needed functional components in the solution are identified.

Mock-ups of the functional components can be created once there is agreement regarding the definitions in the storyboards. These might include versions of the visual interfaces that will be provided. Some of the available technical components might also be used for functional illustration.

A next step could be a technical proof of concept. In this step, we further identify data and integration challenges as well as skills gaps. Up to this prototype development phase, throwing away portions of previous efforts might have had little consequence in the overall cost of creating the solution. At this point, we begin to make a more significant technical investment with the notion that we’ll continue to evolve this prototype over time.

Our technical prototype can be used to demonstrate what the final solution could look like from a functional standpoint. Some also use this effort to determine the operational impact and other potential gaps in the proposed solution.

Figure 8-5 illustrates a typical series of steps in prototype creation.

Testing

During each stage in prototype development, testing is used to solicit feedback from stakeholders and other key parties, especially the frontline users of the proposed solution. We use testing to validate our hypotheses about the value that our solution will deliver. Going into testing, we should have criteria established that define the outcomes that we are expecting to see if our hypotheses are correct.

In early stages of prototype development, stakeholders and key parties view storyboards and mock-ups. They are then interviewed and/or share their observations in discussions or surveys. To get broader feedback, focus groups are sometimes created. When there is a lack of consensus, votes might be taken on components and the overall solutions to assure that choices are made that will have the broadest support.

Testing can help identify the must-have components of the solution since the lack of any such components would be pointed out in the feedback received. Satisfaction that the solution requirements are being met will influence the participants’ views on quality of the effort made by the team and of the solution itself. Features added that go beyond the basic requirements might improve perception of the solution or might have little impact (other than adding cost). It is important to document all of this in the feedback and capture suggestions for improvements.

During the prototype development phase, organizations will sometimes have multiple teams creating prototypes in competition with each other. This can provide a means to get to a more comprehensive solution faster. In our earlier example, one team might be adding sensors alone to a production line and building out that prototype. A second team could be adding sensors and image recognition to a second production line.

Testing and evaluation of competing prototypes provide us with comparisons of the solutions but also enable us to judge the quality of work by each team. One prototype might be chosen over another if it meets all key requirements and is perceived to be the best solution or is more cost-effective. Sometimes, the best features or components from each prototype are determined and then merged into a single solution.

The Agile Sprint Approach

Agile sprints have become a popular technique used in early prototyping and testing of potential software and applications improvements. The sprints generally take place over short periods of time (2 to 4 weeks) with requirements driven and prototypes reviewed by a small group of stakeholders and interested parties. Each iteration of the entire process previously described in this chapter is compressed into this short time frame.

In preparation for the sprint, the facilitator does research into potential problems that might be addressed, observes current solution practices, and determines who the likely stakeholders and interested parties will be. The sprint begins with the facilitator leading this group of participants through the initial problem definition and ideation phases. A diverse group of six to ten people takes part.

Just as in longer engagements, the facilitator briefs the group on the openness of the process and reminds them not to feel limited by constraints and to set aside any critiques. Both the problem definition and ideation phases often utilize the same brainstorming techniques. These phases commonly take place on back-to-back days. The same group of participants is usually present for both.

At this point, a prototype is started and developed, usually over no more than a 2-week or 3-week period. The prototype is then “tested” in front of the participants to validate whether it might provide the solution that the participants were looking for. This discussion can drive further iterations of this process or lead to a decision to move forward with an implementation.

In 2005, this process that we describe here was summarized in a “Double-Diamond” figure by the Design Council UK. The Double-Diamond visually represents where the scope of what is being considered widens and where it narrows. Figure 8-6 is our representation of the Double-Diamond using the nomenclature we’ve used in this book.

During observation and research, the scope of our effort widens. As we define potential problems to solve, we eventually narrow the scope, often to a single problem. As we gather ideas about solving that problem, our scope widens again. In the prototype creation and then testing, our scope is narrowed, eventually to a single solution as we move toward a production implementation.

Regardless of whether the agile sprint drives prototype creation and testing, or design thinking drives it at a slower rate, funding for a full implementation and operationalizing the solution will require additional considerations. We discuss these in the next section of this chapter.

Measurable Return on Investment

We noted earlier in this chapter that return on investment is just one of the considerations used in determining which projects move forward. That said, once projects move beyond the testing and prototype phase, ROI analysis frequently becomes necessary to justify making the investment in an operational version of the solution. This is particularly true where the CFO has a role in approving these projects.

The potential business value from an IoT solution might initially be viewed by some in an organization as speculative prior to the deployment of the operational system. Such estimates of business value are most believable when coming from responsible business leadership. Often, a range of estimates is provided that can be described as conservative, pragmatic, and aggressive with pragmatic being considered the most likely scenario based on business judgement.

A typical illustration of when ROI occurs over time in an IoT project is shown in Figure 8-7. Initially, the cost of development and TCO far exceeds business value. Later, TCO becomes primarily support-related and bringing additional IoT devices online, while business value continues to grow. The crossover point where ROI is positive (business value exceeds TCO) is sooner when using aggressive business value estimates and later when conservative estimates are used.

In Figure 8-7, positive ROI occurs just after the start of Year 2 in the project. TCO is growing at a diminished rate, while business value growth continues to increase.

Operational Considerations

In Azure-based backend cloud deployment servicing IoT solutions, operational aspects are greatly simplified compared to earlier on-premises deployment of these resources. Given that most companies were adopting a Platform as a Solutions (PaaS) strategy for IoT solutions when this book was written, let’s look further at key tasks and roles of key players aligned to such a strategy.

Identifying the key tasks and roles needed prior to deploying a production version of your IoT solution is important for a variety of reasons. As we estimate costs associated with full deployment, personnel costs need to be identified. In addition, understanding the skills that need to be developed will impact cost, time to solution, and hiring that must take place.

Key tasks that must be executed when full deployment occurs include managing day-to-day operations – monitoring the infrastructure, performing change management, application release management, and performance tuning – and assuring the protection of data. Operationalizing the architecture is frequently represented by a RACI diagram.

Implementation Strategy

The earlier stages of the design thinking approach we described previously in this chapter should have convinced key stakeholders that there is business value in the proposed IoT solution. We should now have a good idea as to what our IoT solution will deliver. The financial and operational considerations we described in this section of the chapter will also help us in developing our implementation strategy. Even so, many risks could remain when we approach operationalizing our project, especially if this is our first IoT solution. Our implementation strategy will help us mitigate those risks.

For example, the design complexity and cost of our IoT solution could raise concerns about the potential outcome. Developing a phased approach that clearly lays out the scope of deployment within the project phases, deliverables at the end of each phase, and likely cost and business value of each phase can help to alleviate those concerns.

Within the project phases, developer and deployment skills might be required that are not widely present within the organization. Such concerns can be addressed by providing an education and hiring plan or identifying technology partners that will assist in the development and deployment during these phases.

In a highly competitive environment, competitors could be developing similar IoT solutions that match or exceed the capabilities that you have planned. Monitoring these developments and having flexibility in making some adjustments in response within the project phases could be well received by key stakeholders of the project.

Deployment of our proposed solution could also have significant impact on existing business processes. Having well-thought-out change management plans is critical to mitigating concerns about this impact. Such plans often include activities that are designed to gain support for the new processes among workers and alleviate the concern of sponsors. Training can provide education on how day jobs will be impacted and generate enthusiasm for the changes.

Preparing an Implementation Roadmap

To gain needed funding for the IoT project, you might need to sell the value and viability of the project to senior management by providing an implementation roadmap. The roadmap should contain an easily understandable message about the problem to be solved, its potential business value, and the expected time to solution that will demonstrate its value.

Multiple roadmaps are often developed to address the concerns of different audiences in different levels of detail. Business and technical roadmaps each focus on answering the questions relevant to those audiences. An executive roadmap presentation presents the information we just noted at a very high level, conveying just enough information such that the executive(s) can make an informed decision.