Operationalizing the Solution

At the point that a solution is deemed ready for more widespread use and adoption, we must consider what it will take to make this possible. Many organizations identify and begin to solve operational challenges during their DevOps development cycles or when they deliver a limited production environment prior to moving into full production. As part of such efforts, they identify critical tasks and procedures that need to be put into place to deliver needed levels of service and support.

When we earlier put together the message used to sell the project to senior executives, we estimated staffing costs required to bring the solution into production. As we begin monitoring the incremental development and production efforts, we should uncover more information about who these key individuals are and the tasks that they must perform. We might also need to evaluate additional staffing needed to perform tasks that we had not earlier anticipated. A typical approach used during these evaluations is to identify who is responsible (R), accountable (A), consulted (C), and/or informed (I) for a variety of tasks (often referred to as RACI).

For example, the key activities identified for cloud-based PaaS deployment of software and AI solutions could include day-to-day operations, monitoring the solution, application and platform change management, application release management, performance tuning, and data protection. The people we might focus on in our evaluation include stakeholders and frontline workers, analysts and data scientists, cloud administrators, data administrators, developers, and IT managers.

A RACI diagram is used to indicate the key activities for this group of people. An illustration is provided in Figure 7-1.

The activities and people designated in RACI diagrams are influenced by the type of technology infrastructure utilized in the production deployment. For instance, a more extensive list of IT-related activities and staff would be required for deployment of an on-premise solution than that which we denoted for a cloud-based PaaS deployment. We would need to add systems administrators, storage administrators, network administrators, and data center managers to the list of critical staff. Activities such as infrastructure configuration, software patching, hardware and software updates, and data center infrastructure coordination and planning would be added.

In our supply chain optimization example that we have referenced in this book, we also indicated a need to deploy intelligent devices to track supplies and their utilization in the manufacturing plants. A typical RACI diagram focused on IoT edge deployment is shown in Figure 7-2. Here, we designate day-to-day operations, device monitoring, device maintenance, device software releases, network monitoring (including within plants), and device protection as key activities. People included in this evaluation include stakeholders and frontline workers, analysts and data scientists, device administrators, device software developers, and plant managers.

RACI diagrams can also be extended to illustrate the delivery of specific levels of service and denote the individuals and their responsibilities in delivering them. Examples of areas of service-level focus include resource availability (and related technical implementations such as high availability and disaster recovery) and infrastructure security (including infrastructure, software, and data security).

Levels of detail provided within these diagrams can also vary. Some organizations choose to build RACI diagrams for each of the major activities that they identify and then break those activities into detailed tasks for which they also provide RACI diagrams.

Our next step is to document the procedures that are to be put into place to perform required tasks. The procedures are defined by considering previous procedures already in place within the organization, knowledge gained in prototyping the solution, and previous experience obtained by scaling other prototypes into full production.

The procedures are generally refined and tested during DevOps cycles or during a limited early production phase of deployment. Scalability testing likely also occurs during this time by simulating workloads and situations that will be likely when the solution is in full production.

Change Management Considerations

Innovative software and AI projects, by definition, drive change. Managing change is an important aspect of assuring successful rollout of such projects. Best practices have been documented by numerous people and organizations who have expertise in change management over the past 70 years. Examples of such methodologies that gained a popular following include those defined by Kotter, Lewin, McKinsey, and Prosci.

The Design Thinking workshop is a critical early piece of the change management process. Remember that we gained support that change was needed and formulated a vision of the potential solution during the workshop. During the subsequent building of the prototype and then development of the solution, we began developing skills needed for successful deployment and management.

As we go into production, we must revisit the skills present in our frontline workers and among the management who will use the solution. If there are skills gaps, we will need to implement a training and rollout plan that closes the gaps and monitor success in utilization of the solution. As part of this effort, a popular best practice is to identify those with early expertise and assign them to act as mentors for those less experienced during the rollout.

During the rollout, one of our goals is to continue to build solution utilization momentum. Senior management can help drive positive momentum by offering meaningful rewards and recognition to those successfully applying the solution. Those who resist change should be provided with additional guidance and training, and it should be made clear that they need to adapt and utilize the solution if they are to be viewed as a positive contributor to the business.

Figure 7-3 illustrates when the key change management tasks that we denoted are initiated. We use this diagram to show when the tasks are executed relative to the Design Thinking workshop, prototype development, production development, and production rollout stages that are described in this book.

You probably noticed that we illustrated many of the stages by using arrows that point in both directions. As many of these projects tend to evolve over time and roadblocks to success can emerge, there is sometimes a need to revisit earlier stages.

We believe that initiating change management steps as early as possible within the stages will result in more well-thought-out steps and greater maturation over time. As a result, the steps will have a greater positive impact on the organization.

Some experts suggest developing a communications plan during the production rollout stage. We believe that it is important to have ongoing communications procedures defined throughout each of the stages to convey changing project plans, project status, and solution focus. During production rollout, the communications plan should be fine-tuned with focus on the arrival of the solution for general use as well as its impact upon the broader organization.

We can utilize the earlier identified sponsors to assist in our communications to frontline workers during production rollout. We might also enlist additional key managers to support our communications efforts and help broaden the solution adoption.

No doubt, there will be some resistance to the changes that occur. We should have a plan ready to address such resistance, whether the resistance comes from some in management or frontline workers. Such resistance to adoption is sometimes uncovered as we assess the project’s success.

Assessing Project Success

As the project solution rolls out, it should be continually assessed as to whether it is addressing the business problem that it was meant to solve. Doing so is important if you hope to gain momentum leading to widespread adoption of the solution beyond a core group of believers.

Geoffrey Moore described the challenges in gaining adoption of highly innovative solutions in his book Crossing the Chasm. It is interesting to note that in 1991, when he wrote the book, Moore identified AI as one such technology that had failed to gain wide adoption and was seemingly stalled. As you probably realize, the status of AI adoption changed significantly over the past decade when languages, tools, and frameworks emerged aiding its development and usage. The number of trained and skilled individuals capable of using such tools also exploded, and they were enabled by the widespread availability of cloud-based resources and compute power.

Moore pointed out that a technology adoption life cycle can be defined in discrete phases. He described people and organizations leading adoption within these phases as innovators, early adopters, an early majority, a late majority, and laggards. Peak adoption occurs during the early and late majority phases.

A goal of most software and AI projects is to have the production solution gain usage beyond the groups of innovators and early adopters within the organization. A fair and balanced assessment that looks at the state of the project and how it has evolved along the way should be undertaken.

It should be possible to claim success if the answers to these previous questions are of a positive nature.

When you do find responses of a positive nature during the assessment, be sure to also gather endorsements from key executives, stakeholders, and frontline workers, data regarding solution adoption related to the success, and the ongoing measurable business impact attributable to the solution. All this information should be included in reports and presentations regarding the results of the project and should prove valuable in convincing skeptics within your organization.

Some might argue that software and AI projects are never complete as continual improvements will occur and question whether there will ever be a right time to present this information. We believe that when adoption reaches a point where stakeholders and frontline workers attest that the solution is delivering the significant business results that were hoped for, that is a great time to present this content.

You can use this as an opportunity to point out that a key to assuring success of the project was the Design Thinking workshop at the beginning. You might gain new sponsors for future Design Thinking workshops and ensure that it becomes part of the problem-solving methodology present in your organization moving forward.

Summary

If there was a bad miss in what was delivered in the project, a Design Thinking workshop might be held at this point to revisit the problem definition and solution. If the project proves successful, this is a great time to make sure that the workshop becomes part of the organization’s problem identification and solution development methodology going forward.

Thus, we have come full circle in the book. A diagram illustrating the circular nature of traversing the key stages that were covered, including where Design Thinking workshops fit, is illustrated in Figure 7-4. Though we might need to revisit earlier stages within a cycle, as we gain experience using this approach, it becomes a repeatable engine for uncovering and solving problems.

Our hope is that this book provided you with guidance on how to identify problems in your organization and determine potential solutions. We also hope that it provided some practical thoughts on how to make these solutions real as you move beyond the Design Thinking workshop.

As a final thought, we would like to share this. Though software and AI proponents sometimes view the technology as something that only needs to be implemented to prove its value, it is far more optimal for an organization to understand the business problems present that need to be solved before starting any development efforts.

It is our hope that you now agree and can see the tremendous value in adopting a Design Thinking approach as part of your project development life cycle.