Change Management and Adoption

In the broadest sense, change management and adoption reflect the processes and techniques necessary to land and accept change. Attention to these matters is critical but often diminished; managing change is time-consuming and hard work. In light of this, we expect the techniques and exercises shared in this hour will prove helpful for even the most experienced change management experts.

What is change management? Think of it as the steps a user community and their supporting tech teams must navigate to learn about, understand, prepare for, and embrace a change in how they operate. This process for change seems easy enough, as we see in Figure 23.1.

Adoption, in particular, speaks to the final phase or step in the change management process illustrated in Figure 23.1, where a user community actually uses or adopts a change, or a tech team actually interacts with and deploys technology that will support a user community. Such changes could include new ways of operating, along with new or updated technologies and solutions that enable those new ways of operating.

As all of us know from experience, adoption is arguably the most difficult leap for people to make. We like to hang onto our old ways of operating. In a complex ever-changing world, we often treasure the few things that remain static for a while—such things give us comfort and indeed act as an anchor when everything around us is changing.

But everything eventually changes. And when those things that give us comfort eventually succumb to change, the process for understanding and adopting what’s next becomes paramount to successfully changing.

The Four-Phase Change Process

There are numerous models and methods that help people and organizations navigate and think about change. Burke-Litwin’s detailed 10-component change model and Kotter’s well-known 8-step model for change are two of the long-time heavyweights for change. PROSCI’s model for change is a simpler and highly effective 3-phase process for change, along with their 5-step methodology for individual change.

For our purposes here and as illustrated previously in Figure 23.1, we have organized the change process into four phases that generally align to most of these popular change management models. The phases include creating awareness, providing purpose, driving readiness, and adopting change. These four phases are covered next.

Methods for Creating Awareness

Nearly all change management experts agree that awareness is a key and early action for landing change. In our case, awareness is synonymous with understanding who will use or be affected by an upcoming change and what that change entails. Helpful techniques or exercises for awareness are illustrated in Figure 23.2 and include the following:

• Big Picture Understanding can help us understand the broader community that will use our new product or solution or in some other way be affected by the change. In these ways, we can craft more targeted awareness campaigns and collateral.

• Fractal Thinking can give us a sense of what is echoing down to us from higher up in the organization, company, industry, or broader ecosystem. With this understanding, we can create awareness campaigns and initiatives that resonate with different levels of the organization.

• Stakeholder+ Mapping is useful for mapping the user community’s key leaders, sponsors, mentors, coaches, and other such enablers. Including what these people say and what we believe they are thinking can give us another level of insight too.

• Persona Profiling and grouping can help us better understand whom to target for a particular change. Don’t forget to include both the affected user communities and the various tech team roles and personas who support the product or solution.

• Use a Cover Story Mockup to drive excitement and connect a user community or tech team to a new tech-enabled business vision.

• Consider the Snaking the Drain and Sacrificing the Calf techniques to influence awareness, work through past missteps, and reduce resistance.

• Finally, Make Our “Awareness” Ideas and Collateral Visible and Visual to drive a faster shared understanding and connect on multiple levels with the communities and tech teams involved in the change.

For some audiences, we might even explore the underlying problems or situations to connect and obtain deeper buy-in. Techniques and exercises we used in Hour 9 that could prove useful in creating such awareness include Problem Tree Analysis, Problem Framing, and Problem Stating.

As we generally conclude our work of Creating Awareness, we may move into the next change management phase where we are tasked with providing purpose and answering the often unspoken question “What’s in it for me?”

Techniques for Providing Purpose

As we consider change management at an individual level, we eventually arrive at the place of purpose and WIIFM, or “what’s in it for me?” WIIFM is perhaps the key component to the entire change management process since it directly reflects how change occurs: a person at a time and a day at a time. People without a good sense of purpose or WIIFM will rarely support an upcoming change. Worse, these people might passively avoid the change or actively rally against it, sabotaging good change management practices along the way.

Helpful Design Thinking techniques for providing purpose help us answer another question too: “Why me?” Illustrated in Figure 23.3, consider the following:

• Map the change to the user’s “Day in the Life of” (DILO) analysis or Journey Map in such a way as to create excitement through problem solving, improving the user journey, simplifying key DILO tasks, and so forth.

• Use Verbatim Mapping to showcase the kinds of issues, problems, or opportunities that have been shared that highlight the problems underpinning the need for change.

• Publicize Looking Back feedback and other learnings from early prototypes and testing that validate the usefulness of an upcoming change.

• Work through the visual Force Field Analysis “for and against a proposed change” exercise with the community or tech team that would be affected by an upcoming change initiative. Then use the resulting for-change analysis as a way to objectively promote and support the WIIFM for change.

• Use the Force Field Analysis exercise’s “against-change” analysis as feedback for influencing the business case, OKRs (objectives and key results), design, prototyping, testing, and so on of an upcoming change initiative.

• Apply the Fixing Broken Windows technique alongside other change management techniques as a way to proactively remediate problem areas today that will help us be more successful tomorrow.

With a better understanding of the “Why me?” and WIIFM, user communities and their supporting tech teams need to begin thinking through the kinds of readiness-related items and techniques that need to be addressed before change can truly land or be adopted. We call this third phase Readiness, and it’s the topic of our next section.

Driving Readiness Through Design Thinking

Beyond creating awareness and providing purpose, change management also reflects an organization’s readiness for and ability to change. We need to understand how prepared for change a user community is so we can then engage in a set of activities intended to bolster that preparedness. Steps include understanding the size or magnitude of the change and gaining an understanding of the business organization’s readiness for the change.

In a parallel sense, change management also speaks to the tech team’s ability to support the change from an underlying technology and process perspective. New solutions nearly always mean new technology solutions and infrastructure, data technologies, application and integration platforms, user experience tech, and so on.

Design Thinking techniques and exercises we can use to help us drive readiness, as illustrated in Figure 23.4, include the following:

• Consider how Analogy and Metaphor Thinking can help us align around a shared understanding of the change, the process for changing, and therefore the gaps that organizations and teams will face.

• Prototypes and Mockups can help us see and interact with upcoming changes in an early and safe kind of manner where we not only know what to expect but have an opportunity to influence the design and implementation of that change.

• Testing in all its forms, especially SIT and UAT and Design Thinking–inspired Structured Usability Testing and Solution Interviewing (covered in Hour 19) helps organizations and teams highlight readiness gaps.

• Training delivered in a just-in-time manner is paramount too. Training needs to be accessible to the entire community, consumable by the entire community, presented in different video and written forms and formats as needed, available offline for reference later (and for future community users and tech team members not in the role today), and delivered not too early but not too late.

• Tools and similar enablers are also an important aspect to driving readiness. Consider the role that wikis, frequently asked questions (FAQs), support organizations, Buddy System Pairing (outlined in Hour 22), community leads and mentors, power users and user groups, and so on play to help the overall community work through questions, resolve issues, and onboard future users and tech team members.

Change needs to be planned so it lands well within its user and tech communities. And as we have mentioned, the change itself must be consumable by each respective community. General preparation and readiness questions include the following:

• Does the community truly understand how the new product or solution aligns to the organization’s or team’s overall organizational vision?

• Have we asked the community its perspective on readiness and the gaps that need to be addressed prior to adopting a planned change?

• Have we evaluated readiness for changes to existing business or tech-related processes?

• How will existing organizational structures, roles, and specific teams be impacted, and therefore what needs to occur from a tactical readiness perspective?

• Have we considered how other systems and technologies may be impacted by our change initiative and therefore what might need to be accommodated from a broader readiness perspective?

• Do we have a set of defined and measurable objectives and key results (OKRs, discussed in Hour 17) that we can lean on specific to readiness?

Remember that readiness is the final step prior to adoption. Any changes that need to be made to enable adoption, including incentivizing new behaviors, are ideally made in this phase. The earlier we think about the upcoming change, the better off we will be when that day finally comes to adopt the change, discussed next.

Four Techniques for Adopting Change

When it finally comes time to help our user community or tech teams adopt a change, we use the following techniques, the first three of which have been outlined previously and together create a repeatable recipe for driving adoption:

• Forcing Functions for Adoption

• Gamification for Adoption

• Context Building and Mapping

• Making Change Consumable

Let’s briefly look at each of these adoption-related techniques next, illustrated in Figure 23.5.

Techniques for Timing Change

In previous hours, we covered techniques for timing change including Time Pacing and the Inverse Power Law. These and other techniques covered here can help us determine when a user community or tech team is primed for change based on its readiness, its preparedness for adoption, and most importantly its bandwidth to consume or adopt the change. After all, a ready and prepared business community, for example, may not have the time to accommodate a change until a particular period within its business cycle.

Historical context is important too. We need to consider the organization’s or team’s track record when it comes to managing, handling, and adopting change. Key questions include

• Is there a dedicated change management team assigned to most projects or initiatives?

• Does the organization or team follow a structured change management and adoption methodology?

• In the recent past, have changes been viewed as negative or positive experiences?

• Does the current change initiative reflect a shared vision and understanding across the organization or team?

• More tactically, does the current change initiative reflect a strong WIIFM or other reasons to change?

• To what extent do employee behaviors or operational processes need to change to achieve the desired outcomes?

• Is the organization or team capable of changing its behaviors to the extent necessary?

• Does the organization or team have the bandwidth and capacity to accommodate this change given other changes in flight?

• Are there competing priorities that might interfere with this particular change initiative?

• Does this change initiative change the organization’s or team’s structure or required roles?

In light of the preceding questions, we can then turn next to several Design Thinking techniques covered in previous hours that affect the timing of change and are illustrated in Figure 23.6:

• How might the Culture Snail for Pace of Change illuminate past difficulties or rough spots as the organization or team changed a person at a time a day at a time?

• In what ways might Bias Recognition and Validation help the organization or team be more planful or careful on the change journey?

• How is the community currently handling stress or recent organizational or team traumas? To what extent does the team embody AntiFragile behaviors?

• As an organization or team, do we need to go about Fixing Broken Windows to showcase to our community that we understand their needs? Or in some way show how we are all in this together?

• Does it make sense to Time Box any remaining critical items to ensure they are planned for and completed?

• If we look at the organization or team through the lens of the Inverse Power Law, are there high-magnitude changes or forces on the horizon that must be accommodated?

• Finally, with regard to Time Pacing, are there frequency or duration matters at play that we must better understand before we commit to the timing for this latest change initiative?

Surely other timing factors may be at play. Consider the recent past and what the communities have recently navigated. Review today’s priorities and changes currently in flight. Finally, look ahead at what is coming. Within these horizons using the preceding techniques, identify the required block of time necessary to successfully integrate the current change initiative.

What Not to Do: Change Management Can Wait

We cannot leave the work of change management and adoption until the days before a new product or solution is introduced to its users. A large government agency did just that, though. In response to an early awareness campaign revealing a reluctant user community, the agency did much of the work designing a new employee-enabling portal solo. It prototyped solo, working through portal options provided by two different portal vendors. After selecting a portal platform, the agency developed and tested the solution solo, using project team members to develop and execute test cases.

The government agency also pushed change management far into the project plan. To be sure, there was little attention ever paid again to creating awareness. The project was practically a top secret mandate after the initial round of awareness feedback showed no one in one of the agency’s organizations wanted to change. The agency never formally shared with its other organizations that the project existed. No vision was painted, no WIIFM was ever formulated and shared. The agency skimped over awareness and failed to share the purpose of the new employee portal too.

Late into the project, the agency commenced a bit of work to facilitate readiness. A team was asked to pull together a set of videos and training collateral to help prospective users become familiar with the portal’s interface. Project team members created the videos, demonstrating poorly understood use cases. Upon seeing these videos, user community employees would snicker at how poorly the project team even understood the real purpose of the portal.

A subset of the user community was asked to engage in User Acceptance testing using the test cases built by a team who would never actually use the portal. The few who showed up also snickered as they executed high-level UAT test cases. And several weeks before the portal was to replace an old collection of websites and online checklists, training was scheduled for the breadth of the portal’s intended users.

The portal project team used two of the oldest forms of Forcing Functions on the prospective user community. First, the team shared that if users failed to show up to training, their managers would be notified. Second, they offered the half-day training over the course of a single calendar week; if users missed the training, there would be no other chance to attend it again.

The portal training team reinforced during training that the old websites and online resources would be retired when the new portal was released. There would be no parallel testing, and there would be no other communications related to retiring the legacy systems and resources. The high number of employees who ignored the training mandate or happened to be sick or on vacation that week never had the official opportunity to hear about the forced retirement of their favorite tools.

A few managers held meetings to ensure their teams knew that the portal was coming and that the old tools would be retired. Other managers sent emails the weekend before. When the fateful day finally arrived for the portal to be released, it was met by its new users with everything from discontent to impartiality, resignation, and contempt. The agency missed its opportunities to create excitement, to deliver something of value, and to put into the hands of its employees something that could truly help the citizens for which the agency existed. Instead, the portal became just another example of botched change management and missed opportunities to drive adoption and realize value.

Summary

In Hour 23, we reviewed a simple four-phase change management and adoption model focused on creating awareness, providing purpose, driving readiness, and adopting change. For each of these phases, we then outlined a number of Design Thinking techniques and exercises shown to be useful in making our new solutions “sticky” and enduring. We concluded Hour 23 with an important “What Not to Do” related to what happens when we push change management out to sometime later in the future and miss our opportunities to socialize and land change early in solution design, development, or well before deployment.

Workshop