The One Change Management Measure that Matters (But No One Measures)

In one of my previous SysAid blogs, I said that one of the primary purposes of the change management process was “to ensure that a change delivers the intended result…if a change is implemented, but it does not deliver the intended result, this points to larger issues that must be addressed.”

But ask any Change Manager about what change management measurements they capture and report on, and you’ll likely get a list of “usual suspects” that looks something like this:

• Number of RFCs
• Number/percentage of approved/rejected RFCs
• Number/percentage of RFCs reviewed by CAB
• Number/percentage of successfully implemented changes
• Number/percentage of (detected) unauthorized changes
• Number/percentage of “emergency” changes …

And so on and so on.  But do any of these measures really matter?

Don’t Mistake “Activities” for “Results”

We have to distinguish between activities and results.

All of the above-mentioned measures are at least ‘nice to know,’ especially for change managers as they try to facilitate and manage the flow of RFCs and changes through the change management process.

But all of these measures are internally-focused. Outside of IT – outside of those responsible for the change management process – do these measures have any meaning? What do these measures mean to the business?

For example, consider “number of RFCs.” Yes, it’s good to understand the volume of change requests coming into the process. But how many RFCs are too many RFCs? And if there are too many RFCs, what is the course of action – ask everyone to not submit RFCs?

What about emergency changes?  How many emergency changes are “too many” emergency changes?  Even if this number is high, I would argue that this is an IT issue, not a business issue (although the service interruptions typically associated with emergency changes do impact the business).

Yet, in most change management implementations that I’ve seen, it’s these kinds of measures that are being reported to the business.

Newsflash – the business does not care about the measures of change management activities.  The business does care about the results from change management activities.

The Only Measure that Matters

The only change management measure that matters is business value.  What did the business achieve from the implementation of the change? Was the result valuable to the business? Is the business satisfied with the result of the change?

But yet, most change management implementations only report on the measures of the operational activities regarding change. While these measures may be meaningful to those involved with change management, they have little to no meaning to the business.

Here’s an example. Let’s say you’ve ordered a pizza to be delivered to your home. It’s one thing to have your pizza delivered on time and at the agreed price. Those actions, or activities, provide operational measures for the pizza delivery. However, let’s look at some other activities involved, like:

• Was the delivered pizza actually the one you ordered?
• Was the pizza hot?
• Was the pizza tasty?
• Were there any undesired effects from eating the pizza?

The answers to these questions are the results that indicate value with pizza delivery.

If your change management process is only measuring and reporting that the pizza was delivered, then something very important is missing. Your change management process should measure and report that the pizza was hot, tasty, and just what you wanted! Is there a process for that?

Well, Actually…There Is a Process for That

ITIL^® does describe a process for determining that a change actually delivered its intended value – the Change Evaluation process. The Change Evaluation process outlines a “consistent and standardized means of determining the performance of a service change in the context of likely impacts on business outcomes.” “Performance,” in the context of Change Evaluation, means utility and warranty, which leads to value. If a service has utility and warranty, that is, it does what it’s supposed to do in a way that meets the needs of the business, then it should be valuable to the business.

Have you ever formally implemented the Change Evaluation process? If not, it’s worth having a look, but I think the issue is more basic than designing and implementing a process.

Getting to Business Value

Value is an elusive entity. Value is very much based on perception and changes over time. And just because IT thinks something is valuable doesn’t make it so.

So how can IT measure and report on business value – the most important measure of change management? It starts by understanding what the business values. Here are some tips:

• Build business relationships – Identify the key stakeholders and influencers who interact with an IT service. Have frequent, regular conversations about their perceptions and the value of the service…and take notes.
• Map IT services to business goals – Goals are one way that the business articulates what is valued. Map how the outcomes from IT services relate to business goals; then ensure the measures captured by each IT service support the targets of the business goal.
• Develop business acumen – Perhaps one of the most significant obstacles for IT in measuring business value is a lack of understanding the business of the business. IT must be able to speak and understand the language of the business. IT must understand how the business uses technology.  Developing business acumen will help IT ask the right questions to understand value from the business perspective.

One of the ways for IT to demonstrate ITSM value is to capture and report on those measures that indicate business value. How and what the change management process measures and reports can have a significant influence on how the business perceives the value of ITSM. Don’t make your ITSM reporting all about IT; make what you report to the business all about the business!