What’s Missing from Most ITSM Change Management Processes?

Change management is one of the most necessary, misunderstood, and all-too-often misused IT service management (ITSM) disciplines.  If you’ve ever been an IT change manager within an organization, then you’ll know it’s viewed by some as a necessary piece of governance and by others as quite the opposite (i.e. something that “just gets in the way”).

I’ve written quite a few change management blogs in the past few years but hopefully this one will really get you thinking about how we currently do things and where current ITSM best practice could easily be improved.

(If this blog stops abruptly it means that I’ve just been struck by the lightning bolts sent down from the gods of ITSM best practice.)

Please read on to find out more about: starting with the “why” – and don’t you dare ask me why!

The Importance of ITSM Change Management

The move towards mobile and flexible working (and customers) is now in full effect, with measurable benefits, and with the shift to the cloud continuing, the way in which people are working is changing rapidly – along with their expectations. All this and more means that the rate of technology-driven change is showing no sign of slowing down.

Change managers are thus looking for better practices that help them walk this tightrope of “necessary versus not.” This is especially the case when a change management regime runs into the immovable force of something like DevOps thinking that seeks to speed up the time to change applications or services.

How your organization’s change management is working matters, it really matters, whichever way you look at it.

The ITSM Change Management “Missing Link”

There’s one best practice that’s all too often missing from change management policies, processes, and procedures, and one that’s totally missed by ITSM best practice frameworks such as ITIL.

Simon Sinek authored a compelling book on this missing piece, for businesses at large granted, but compelling none the less – “Start with Why.” In this book, he emphasizes how organizations can explain what they do, and how, but very few can articulate the “why.” And how starting with the “why” truly helps – in this case, how a change manager and their change management practices apply governance and invest time where it has the most effect and value.

What Do I Mean by This?

Well, many ITSM change management practices include classification or categorization schemes that document the what, the how, and/or the effect of a change. For example, they might typify and categorize a change request as being hardware, software, or peopleware related.  (By peopleware I mean that a change request could have an organizational consequence – organizational change).

They might relate the request to other information, such as problem or incident records. Then a change request could be standard, normal, or emergency and within these they might define increasing levels of impact, such as major, significant, or minor.

The change management process might also go further with the categorizations and use subcategories. It’s all useful, but we’re still missing the “why”! It’s why my blog is calling it out as the one thing missing from most ITSM change management processes.

Breaking Down Change

There are only four basic reasons why change happens:

• To correct something that has already failed or gone wrong
• To prevent something from failing or going wrong
• Because something else has changed, or is going to change, and you need to make a change to stay compatible
• Because you need to add, remove, or enhance a capability.

Almost every other reason (for change) that you can think of can be squeezed into one of these four basic “whys” (although I appreciate that the “why” itself” may not be basic).  And knowing the “why” behind a change and reporting the percentage “change mix” by a team, application, or technology, can really help a change manager to decide where to invest their time and to right-size change management governance.

An Example of Understanding “Change Mix”

With this added visibility, what if we have an application team with a change mix of “60-5-25-10” (as per the above four bullets)? What can this tell us or imply? Sixty percent of their change requests are to correct something after a failure. Five percent are to prevent a failure, and so on.

This mix is very telling. It implies that this team is struggling with their development activities and introducing risk and issues at a significantly high rate. The twenty-five percent rate of changes to stay compatible may also be an important indicator.

How about a different team, an infrastructure or technology management team with a change mix of “10-50-15-25”? Only ten percent of their changes are corrective. Fifty percent are preventive. They seem to have matters under some semblance of control.

Finally, what if we combine the “why” indicator with information about technology from a specific vendor. What if that technology had a change mix of “70-0-30-0”? What could this be telling you about the quality or reliability of the technology, or the influence other technologies have on this one? These are all invaluable insights you can use to make critical decisions about how much “red tape” to apply in respect of related changes.

The Impact and Benefits of: Starting with “Why”

Many traditional change management best practice sources cover the “what” and the “how” perspectives but they typically miss entirely the “why.” Change management will of course work without the “why” perspective, but how does this adversely impact the quality of your organization’s change management capabilities? Are you operating in a blinkered and even suboptimal way?

Starting with “why,” and making sure you capture any one of the four basic reasons for change as part of the change management process, changes the conversations a change manager has with those requesting change, and begins the process of promoting and operating change management as “change as a service,” rather than “as a necessary evil.”

As to how it helps, with both decision making and outcomes, as a minimum it provides context (for the change). It also helps to flip the focus from “inside-out” to “outside-in.” If you’re unfamiliar with these terms – they’re often used to denote the movement of thinking and/or doing from the supplier perspective to the customer/consumer perspective. It, in particular, helps decisions and actions to be in line with what’s expected (and needed) rather than merely being what the supplier thinks is best.

There’s also the potential to move people on from looking at outputs to the more-important outcomes. For example, thinking of changes in the context of what they will achieve rather than what they involve. As a minimum, it will help to understand which changes are most important at a business level.

Plus, of course, as per my above example – it’s healthy to know the change mix, i.e. which reasons are driving change requests more than others (and whether this is acceptable). And where too many changes are corrective, remedial actions or improvement activities can be applied to bring down the volume of changes that are ultimately a “cost of quality.”

Starting with the “why” thus offers a wealth of benefits to any change management capability. Do you start with the “why”? If so, how has it improved your change capabilities? Please let me know in the comments.