Contributed by Elizabeth English of Global Tech (United States), a Consultant Alliance member. This is a condensed edition of Global Tech’s guide; a link appears at the end. The Adoption and Change Management framework it describes is credited to Vallorie Weires of Enabling Technologies.
Providing a tool is not the same as adoption
It is one thing to give your people a new technology tool. It is quite another to get them to use it — and different again to get them to use it well. When end users fully embrace a new technology and make it part of their daily habits, they have truly “adopted” it. That gap between deployment and adoption is where the return on a technology investment is won or lost, and it is the reason a deliberate end-user adoption and change management (ACM) process matters.
Why you need a change management process
Some argue that good technology should be so intuitive that no training is needed. In reality, any tool with more than cursory capability rewards education — and communication and collaboration platforms in particular must serve many different types of user, so feature depth inevitably brings complexity. A structured ACM process helps an organization maximize use of the new technology, and higher, more confident usage is what maximizes the ROI of the money spent on it. A good process can influence project success and perception, improve IT’s reputation, increase engagement, reduce turnover, and ease the burden on support teams.
The difference is measurable. On one project, two groups in the same company rolled out the same technology: Group A invested in end-user training and communication, Group B did not. At go-live, Group B — despite being less than half the size of Group A — filed roughly twice as many help-desk tickets, along with far more (and more vocal) user frustration. Same tool; different outcome. The variable was the change management around it.
The four phases of ACM
The process has four stages, each building on the last: Discovery, Planning, Execution and Reinforcement. Every phase is designed around the user’s perspective rather than the technology, and it runs alongside the technical project — focusing on the human side of the change.
Discovery: understand your users
Discovery ideally begins alongside the technical evaluation of the new solution. The goal is to document who uses which tools, how and why they use them, and how their experience could be improved — surfacing the differences, commonalities, risks and barriers across the user population. The central technique is personas: profiles that group staff by common working patterns, challenges and goals. On one project that moved 10,000 users to a new cloud communications platform, eight personas were used — for example executives (frequent travelers who work across multiple devices and rely on assistants), remote workers (who depend on clear audio and video to join meetings on an equal footing), field staff (mobile, coordinating from outside the office), and shared answering roles (first point of contact, needing presence and easy call transfer). Defining personas lets the team make informed decisions about which devices to offer, what training will help most, and how best to communicate with each group — and it establishes the “What’s In It For Me?” (WIIFM) message for each audience.
Planning: turn discovery into a blueprint
Planning converts those insights into a communication plan and a training plan. There is no one-size-fits-all approach; the depth of both should scale with how much each persona’s daily work is affected.
For training, decide whether it will be voluntary or mandatory (and, if mandatory, how that is enforced), and offer a mix of formats to suit different learners — how-to videos, quick guides, in-depth guides, in-person and remote classes, instructor-led sessions, and self-service references. Just knowing that help is available reassures users, whether or not they attend. Work through resource creation (build, outsource or reuse existing material), governance and regulatory constraints, and the impact of training time on operations. The final plan should spell out who to train, when, in which format, what each session covers, what content must be created, and who is assigned to deliver it.
For communication, audience awareness is everything: a message that tries to cover every experience is one that people stop reading. Tailor communication streams to how each persona is affected — usually starting from one template and adapting it — rather than sending a single generic message that users learn to ignore. The plan should define the series of communications, who receives each, who sends them, timing, channel, and what each one contains (including the WIIFM for each group).
Execution: follow the plan — and stay flexible
If discovery and planning were done well, execution is largely a matter of following the plan: create or gather the training materials, stand up the training repository and schedule, and communicate the options to users. The key to this phase is having resources available to respond as issues arise — and building follow-up time into the schedule for the unexpected. On one phased migration of 10,000 users, the vendor pushed a major interface update mid-rollout: training materials, class curricula and already-trained users all had to be revisited. Adequate staffing kept the rollout on track, but it is a reminder to plan for change during the change. Execution is also the moment to fine-tune — adjusting communications and training as real-world feedback and help-desk patterns emerge.
Reinforcement: the most-missed phase
Reinforcement is, in most change projects, the step most often skipped — and, ironically, frequently the biggest factor in whether the project is perceived as a success. It covers non-technical Q&A support, user-satisfaction surveys with results shared back in a digestible form, ongoing updates to materials and training (which quickly become useless if left to go stale), and — above all — a genuine feedback loop.
From a user’s point of view, the feedback loop is simple: they raise something, and either it is acknowledged and acted on, or it is not. When you respond — even if the answer is “no, and here’s why” — users feel seen and keep contributing; when you don’t, they stop, and IT’s reputation suffers. Responding does not mean saying yes to everything; it means capturing input, demonstrating how you are acting on it, acknowledging all feedback, and scheduling for the long term. Assign someone to own this during and after the project, and continue it through the support team on an ongoing basis. The most critical component is simply setting expectations about what you will do with feedback — and then doing it.
The evidence
The case for change management is well supported by industry research. Commonly cited findings include organizations moving faster on digital transformation once staff and leadership share an understanding of the path ahead (Gartner); companies being materially more likely to financially outperform their peers with strong change management in place (Towers Watson); a large gap in realized ROI between organizations with effective change management and those with little or none (McKinsey); and organizations with excellent change management being several times more likely to meet or exceed objectives (Prosci).
Tying it together
A good ACM process is not about dragging users along for the ride — it designs the ride with and for them. The technical transition must be done correctly, but the project ultimately fails if the tool is not used well. Since the whole point of new technology is to improve the experience for the people who use it, focusing on those people — and on what they need to adopt the change — is what turns a deployment into a success.
This is a condensed edition of a guide by Elizabeth English, Global Tech (United States), a Consultant Alliance member. The Adoption and Change Management framework and diagram it describes are credited to Vallorie Weires of Enabling Technologies. Explore more from Global Tech: visit globaltech.net/resources →.