Understanding Change Management: One Process with Three Phases

Change is pervasive - everyone does it, or they wouldn't survive. Things come from outside to change us - as individuals, as companies, service providers, and more. The only thing that stays the same is that everything changes.

This perspective - of change being something the world does to us - is valid but not the whole story, and yet for some organizations it's the major, if not sole, focus of their change management thinking: "How can we best cope with the changes coming at us?"

"It's Why We Do Change Management"

But change management shouldn't just be about "best coping" with changes.

Instead, understanding why a change has been asked for, and what outcomes are actually required should be an essential input to:

Whether a change is approved, and

How, when, and with what priority a change is then implemented.

Therefore, if an organization is to really benefit from the best change management, their change management process needs to address the whole process - instigating, selecting, and prioritizing changes rather than just coping with them.

The Whole Change Management Process

Whether you want to use ITIL or not, you could say there are three parts:

Change Request. Someone wants - or at least sees the need for - something new or something different.

Change assessment. Should it be done (accepted, approved) or should it not be done (rejected).

Change control. Making the change happen, and happen properly, on time, within budget, etc.

Many IT organizations overly focus on the last part, but the best change management procedures will not just address all three parts, but also understand the need for continuity, integration, and feedback across the whole process.

This means a single mechanism - capturing requests, considering and deciding on them, and then taking that information through to implementation. And like all things IT service management (ITSM), this means addressing people, process, and technology together.

Three Parts But One Process

Of course, you could - and some do - effectively see this as three separable things.

One process creates the request, another assesses and then approves or rejects it, and yet another then implements the accepted ones. While this might seem to (sort of) work, something important is lost along the way compared to integrating and seeing the three parts, or stages, as aspects of one larger process.

The key issue, perhaps, is not one of process flow, shared data, or integration - although they are all, surely, relevant and valuable benefits are to be had. Rather, the key issue is a human one. Make it three processes, with handovers and separate measures of success and key performance indicators (KPIs), and you create a healthy environment for "us and them" thinking to flourish.

If, instead, the change process is an integrated one, then:

Initiators can see and follow their requests through to delivery, and can (hopefully) see how everyone is working together.

Change builders and deployers can communicate with the people who requested the change, and their ongoing involvement in the process means they can advise on what was actually wanted, rather than what has been interpreted as the requirement.

Quick and meaningful awareness of progress facilitates amendments to changes to cope with inevitably changing circumstances. If a change request is considered, closed, and passed on to an "implement" process then it becomes far too easy to see that approved change as the end product, versus seeing the required business benefit that triggered the request as the end product.

And most importantly, a single process with one set of success measures stands a much better chance of delivering business benefits, rather than only delivering to the targets of a small sub-process.

Successful change request and approval does not, necessarily, deliver business benefit. And the successful deployment of what had once seemed right, just because it was approved, can deliver actual business damage rather than benefit.

Glue and Integration

Keeping the integration and coordination, and involving all parties in all stages towards a single set of goals should be easier today than it has ever been. In the "information age," capturing, analyzing, and reporting on progress is something modern technology should help us do. But people need to make it fit by using the tools constructively.

So, take a look at how you capture and process requests for change. Can you see an end-to-end picture or do you measure and judge each part as a stand-alone process? If so, think about it again. See it terms of what matters - either everyone wins of nobody does. Get the dialogue, and involvement, going across the whole change spectrum - it might just deliver you some real business benefits.

Previous Article

10 of the Best ITSM and Service Desk Blog Sites

Every now and then someone will ask "What are the best sources of IT service management (ITSM) and service...

Next Article

Catch SunView at Pink 17 Live from Las Vegas!

Are you ready for Pink 17? The 21st Annual International IT Service Management Conference Pink 17 will be t...