“Priority is the function of context,” says Stephen Covey. So how do you position the value of change management in the right context so that it gets the priority it needs?
Think about what you describe when you make the case for change management. How is change management viewed by your project leaders? Is it seen as an optional add-on rather than a vital contributor to the project’s success? Do you spend the conversation talking about change management activities, like communication and training, or do you focus on change management’s contribution to overall project results and outcomes?
You might be surprised to learn that the key to discussing change management’s value sometimes means not talking about change management at all, at least not at first. To position change management as a priority, you have to start first with what senior leaders and project leaders care about: achieving organizational benefits and project objectives. With these five questions you will change the conversation from “What resources do we need for change management?” to “What resources do we need to capture the 50%, 80% or 100% of our project’s objectives that depend on people?”
Question 1: What Is the Project Trying to Achieve?
This is a two-fold question and one that goes surprisingly unasked. It isn’t just useful in outlining the value of change management; it is also critical for project teams and leaders to understand in general. After all, if you don’t know what you are trying to achieve, how will you measure the effectiveness of your project?
You can get more concrete answers to Question 1 by asking these next two questions.
Question 2: What Are the Organizational Benefits of This Project?
Organizational benefits are the higher-level reasons for implementing the initiative in the first place. These benefits could include increasing revenue, achieving compliance with regulations, or strengthening customer satisfaction.
Question 3: What Are the Specific Objectives of This Project?
Specific objectives are the outcomes this project will produce. These are usually specific and measurable outcomes that ultimately lead to achievement of the organizational benefits. Examples of project objectives are “all users tracking their sales leads in the new CRM system” or “customer response time shortened from three to two days.”
Connecting the people dependency
Once you have defined the benefits and objectives of the project, you can move on to tying those objectives to people. There are two elements to achieving each project objective and organizational benefit that you’ve defined in the questions above. One part of achieving the benefit is the technical solution: building the software, installing a new system, etc. The other part of achieving the benefit is the people side: the individuals impacted by the project changing how they do their work. A combination of these elements, the technical side and the people side, is required to achieve the project objectives and organizational benefits.
So how do you figure out how people-dependent these benefits and objectives are? Take a look at each benefit and objective and ask the next two questions.
QUESTION 4: WHich portion of this benefit depends on adoption and usage?
Some projects have very low dependency on people adoption and usage for their objectives because the change is primarily technical in nature; for example, increasing server storage. On the other hand, many projects have a high level of dependency on people adoption and usage. For example, “streamlined communication” will depend highly on the people who need to adopt the new communications practices actually doing their job differently.
QUESTION 5: WHAT percentage of this benefit will we get if no one changes how they do their job?
This question is what we call the “null hypothesis,” and it allows us to fully understand just how people-dependent a project’s objectives are. Depending on how people-dependent a project is, you might get no or very little benefit from the project if no one adopts and uses the solution. The answer to this question is usually between 0 and 20 percent. For your strictly technical benefits and objectives, this number could be very high, between 80% and 100%. But for most of your benefits and objectives, you are likely to only capture a very small portion (between 0% and 20%) if no one changes how they do their jobs.
In reality, it’s unlikely that no one will change their behavior at all. However, by asking the question, “What if no one changes?” you can cement how important driving the people side of change is to the project. It also gives you a baseline for how you can increase the percentage of benefits you’ll capture by increasing adoption and usage with change management.
So What Now?
You’ve painted a picture of how much achieving a project’s benefits is reliant on people changing how they do their work. And notice that we haven’t even mentioned change management! We’ve simply changed the conversation to help people realize that to achieve expected benefits, you have to drive adoption and usage. The following questions usually are: “what does adoption and usage mean for my project?” and “how do we increase adoption and usage?”