What Is Change Management For?

Whenever I look at the tools, processes and metrics that IT organizations implement for their change management processes I see a huge difference between what I think change management is for and what they appear to value.

When I think about change management, I see two distinct purposes:

1. To facilitate the rate of IT change that the business needs
2. To protect the business from the adverse impact of IT changes

These two purposes are equally important, and if change management doesn’t do a great job of both of them then it really isn’t being very effective. Most IT departments I work with focus almost exclusively on risk management (protecting the business from adverse impact of change), often causing the speed of change to be so low that it leads to customer dissatisfaction.

So, here’s an exercise for you. Have a look at your change management metrics and mark each one a) or b), or both. I suspect that the vast majority of your metrics relate to risk reduction (b) rather than to rate of change (a). Another similar exercise you can do is to review the activities in your change management process flow and assign each of those to one of these purposes. You are likely to find the same issue.

Many IT organizations have change management that is so bureaucratic and slow that it becomes unpopular with the business. Part of the reason for this is that they haven’t gone to their customers and asked in a straightforward way for the business to give them guidance on how to prioritise the two purposes of change management. If they did so then I’m pretty sure they’d be surprised at the result.

If you decide that you want to change the balance of your change management then here are some things you can do about it?

1. Talk to your customers. Understand their priorities. Make sure they understand you have to balance speed of change against risk, but that this is business risk and they have to accept responsibility for it. Then agree on how you are going to prioritise these in the future. You may find that these priorities are different for different services, or for different business units. This is perfectly acceptable, but you may need to modify your processes to support this difference.
2. Talk to the people who request changes. This may be developers, project teams, business managers or something completely different in your organization. Make sure you understand their drivers and priorities, and how you can help them to succeed. See if you can work together to improve the overall flow, rather than working with conflicting processes. One of my customers actually appointed a single process owner for both the software development lifecycle (SDLC) and IT change and release management. Execution of these processes remained separate, but the tools, activities and metrics were integrated and harmonized across the entire service lifecycle.
3. Learn about Agile and Devops, speak to practitioners of these approaches and see if you can adopt any of the ideas into how you work. I’m not suggesting that you should completely tear up and throw away what you are doing, but simply that you should see if you can adopt parts of some alternative practices that are working very well for other IT organizations.
4. Review your change management process activities to see if you can simplify them. You can often greatly speed up change by reducing the number of people who have to approve each change, but make the remaining change approvers accountable for the success of their changes.
5. Review your change management metrics. Make sure you have an appropriate balance between risk management metrics and speed of change metrics, and then start tracking these.

In the end you only have to achieve two things with change management, you can throw away all the CABs, RFCs, tools and activities if you can just guarantee to support the rate of change that your customers want while protecting them from the adverse impact of change. My challenge to you is to dare to change how you work so that you can delight your customers.

If your customers think of change management as that great process that helps them to achieve their business goals then you’ve done a good job, if they think of it as that bureaucracy that makes it impossible for them to be agile then you’ve still got a long way to go.

Image credit

Like this article? You may also like: Defining Metrics for Change Management.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.