In the technology world, the word “adoption” is often used to describe those who are using a piece of software. It’s a global term that is designed to encompass the metrics used to measure success of the initiative. As organizations spend millions of dollars purchasing and installing software, those dollars are lost if no one uses the software.
Change and change management is a much broader way of describing the same activity. Adoption is a subset of change that focuses on the use of an implemented system. Change can refer to software use or how to change the direction of an organization, how processes are being incrementally improved, or how individuals change personally. (See What is Change Management, and Why is Everyone Else’s Definition Different than Mine? for more.) Between the broad term, change, and the narrow term, adoption, there’s a difference in focus that can sometimes get in the way.
It’s All About the Technology
Perhaps the greatest challenge to technology adoption projects is that it’s perceived to be a technology project, and the adoption and change aspects are considered secondary or even optional. The project manager or leadership believes in “build it and they will come” instead of carefully considering how to help people make the behavior change.
It’s common to hear that the training – which is only a part of the change effort – gets cut from the project at the last minute because of budget overruns in the deployment. To control cost, the overall project success is put at risk. When you’re measured as a project manager by on-time and on-budget, it’s easy to leave on-value to chance. (See Why the 70% Failure Rate of Change Management Projects Is Probably Right for more.) Too often, the people implementing the project aren’t measured on the outcomes expected from the project – they’re only measured on their ability to deliver the project.
When you’re focused on getting across the goal line of delivering the project and not on the end results, it’s easy to cut the things that are difficult – or impossible – to see. Training becomes a checkbox. Did you do training? If you did anything for training, it gets a checkbox, and the system can count as being completely deployed. The question is rarely whether people were effectively trained on the new system. It’s too hard to know when the system is first deployed, and everyone wants to close the project down. (For more on evaluating training efficacy, see Kirkpatrick’s Four Levels of Training Evaluation.)
Communication, another traditional component of change management, is similarly a checkbox. There’s often the question about whether the communications were done without asking how effective they were, because measuring communication efficacy seems daunting. Because it’s not a critical component that is deeply measured, the minimal amount is done, and the focus remains on the technical aspects of project – even if they’re not the ultimate drivers of success or failure.
Adoption is shifting the focus and awareness from the technology to the use of the technology to drive the desired outcomes. No need to deploy something that no one can or will use because it can’t drive the right outcomes. Adoption starts with communication and training. Change extends this to tools and techniques for shifting behavior to the new desired behaviors.
In the end, adoption is just a stop on the path towards change management and taking a wholistic look at how to change the behaviors to lead towards different – better – outcomes.