Project Change vs Project Adoption
The purpose of this article is to highlight the difference between project change management and project change adoption.
Adoption is covered under the People segment within the LEAD domain of the MPM model.
Adoption is covered under the People segment within the LEAD domain of the MPM model
Change Management – Two worlds and Two Definitions
Change Management – IT definition
The Information Technology (IT) world often views change management as a change in scope. It’s all about controlling project scope, which is what the project does or considers, or the features of the project result or outcome. The technology definition of change management means the process for controlling requests for changes in that scope.
In some well-respected sets of global standards and guidelines on project management there is no mention of how change affects the end users and how to plan for it, the kind of change discussed by John Kotter.
Change Management has two definitions
Change Management - Business Definition
What then is adoption? This is the second definition of change management, from a business user’s perspective.
Adoption is when the end-users who are most affected by the outcomes of the project actually adopt those changes into their regular routines. So rather than the changes being on the periphery, they are integrated into how the business users perform their daily critical transaction and replace the old steps for doing things.
Even if it’s very small project and it is just you or your team, you’re still going to do things differently once your project is implemented. You’re going to need to make some changes to your routines. This change in your routines I term “adoption”.
Credit: Andrew Grossman
Adoption is working with business teams to help them with change
I use the term adoption to distinguish the business definition of change management from the IT definition of change management.
And while adoption involves doing things differently and it’s always a bit of extra time and effort to take on new steps, adoption can be invigorating, exciting, and collaborative.
Packaged Software and Change Management
I have recently witnessed some projects which do not attempt to understand adoption at all, because, as their reasoning goes, it’s a commercial off-the-shelf (COTS) package, like an ERP, so the users have to change to fit the tool.
To them the users just have learn to use the new system and the implementation team sincerely believes that any end-user complaints are just resistance to change. But that’s horribly wrong.
The project needs to help the business with Adoption
Three Steps to Help the Business
In fact, the end-users are complaining because they can feel the pain of the change coming since they know that no one has asked them: (1) how they currently do things and, (2) offered a contrast with how things are going to work in the future and then, (3) gone through an exercise of how to bridge that gap with updated steps or training.
Going through these steps is the only way to uncover the anomalies and idiosyncrasies of transactional processes that if not understood early in the project will come back later to bite later.
And these steps don’t take that long. The irony is that it takes a lot less time to do these steps early on than it does to handle all the frantic calls, meetings, emails, and frustrations that happen later.
I don’t really understand the resistance of the implementation teams to going down the path of understanding those three steps above, except that they don’t know how to do it, or maybe they’re afraid of what they are going to find out.
So, they push ahead and just hope that after implementation the end-users eventually stop complaining and things will settle down.
The problem with this naïve approach is that the cost to the affected organization is real, both in terms of time it takes to figure it out after go-live and the financial problems caused by doing things inconsistently or needing to redo them, and it can all be avoided with some simple steps up front.
Summary
In Summary change management has two definitions: an IT controls one and an business one.
The IT controls definition is the exercise of controlling project scope while the project is in progress.
The Business definition is the exercise of adopting the project outcomes into daily transactional steps.
A project, no matter the size, if the desire is to make adoption invigorating, exciting, and collaborative, needs to understand how things are currently done, contrast this with how things are going to work in the future, and then determine how to bridge that gap with updated steps or training.
Action Steps / Apply This Knowledge
- In a current or future project (or even a recent one), list the critical affected processes. This is a finite set.
- For each critical affected process identified go through the three steps above.
- Add any missing pieces to ensure adoption occurs.
- Prompt engineering guidance for AI GPTs such as chatGPT: “I’m a business leader launching a project whose purpose is Y, and delivering X. What are some potential gaps in personal training, knowledge, or process documentation that could block successful adoption of the solution that I need to be aware of?”
Learn More to Do More
Business evolves through change initiatives otherwise known as projects. The key to managing these change initiatives so you have more time, and less stress is to use simple strategies and tools.
Check out the Learning Hub’s other Articles with Actionable Steps, organized with a busy leader in mind, by topic or main idea, and with some AI GPT (e.g. ChatGPT) prompt engineering suggestions under the Action steps: https://simplepmstrategies.com/learning-hub-index
Lead-change-without-adoption
© Simple PM Strategies 2024