Do Change Management a favour: Rank your changes

[SimonMorris]

Over at "ITIL and Me" Michael is kvetching about Change Management.

Do Change Management a Favor - Say No

He writes..

Then the question was asked "What about if a Change doesn't fit as Emergency, but doesn't get submitted in time for Normal?" My answer was simple; it gets rejected.

As soon as I finished my simple answer, I could hear the crickets chirping.

In an organisation that I worked in previously, where I managed Change I had a similar (frustrating) experience. We would clearly define, and agree on the definitions of a Normal change and have a provision for Emergency changes.

We held a Change Advisory Board meeting on Thursdays, giving change requestors a clear deadline by to get their requests written and submitted by.

I lost count of the number of times that we considered Normal changes as Emergency, with the only justification being that either the requestor didn't meet the deadline, or the requirement came in too late for consideration in the CAB.

At this stage we had to decide whether to compromise our standards, or be pragmatic and review the change anyway. An imperfect situation. What about a situation where two change requestors rush to complete their documents for the 10:00 CAB meeting. One makes it by 5 minutes, and the other misses it by 5 minutes. Is one really more valid than the other?

Really frustrating.

I have a suggestion for Michael - the Change approval routine where the CAB meets once a week has pros and cons. It's a great opportunity to discuss changes, and get a cross-section of views from different representatives - How many big changes are implemented without the opinions of the user community being represented?

However, I'm not sure it scales particularly well. You start to run into a situation where there is a finite amount of time allocated to the meeting, and volume of Request For Change documents increases, lowering the amount of time to properly consider each change.

Or worse, you end up with mammoth meetings where all the fun (??) goes out of the task, and the level of participation decreases.

Remembering the purpose of Change Management:

The purpose of the change management process is to control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.

.. and one of the aims

Optimize overall business risk - ti is often correct to minimize business risk, but sometimes it is appropriate to knowingly accept a risk because of the potential benefit

In my previous organisation I used to promote Change Management as being able to "regulate change", meaning that we could slow the rate of change believing that by doing so we would remove some of the risks associated. In retrospect I think we probably did the opposite. We forced ourselves to evaluate changes in batch mode in the Thursday CAB meeting, dedicating less time each week to each individual RFC (because of the increasing volume).

It interesting that none of the aims of Change Management is to slow or regulate the rate of change

I now think that this is a much better approach. The aim is to identify and remove (or recognise and accept) different levels of risk for each RFC.

Lets start by assigning each RFC a risk rating (an integer) of zero. By examining the Risk and Impact rating that the requestor assigns to the RFC we can start to increase the risk rating.

This change affects an application with a high criticality? Add 10 points. You want to change a CI that other services depend on? Add 20 points.

(Here is the point I am working towards) You want to implement this change in the next 3 working days? Add another 20 points.

What we end up with is a much more granular method of ranking Change Requests. The CAB meeting can either set a threshold of changes to review (any with a risk rating of more than 40 points) or just review the top 10.

The requestor putting his change request in very late may not be the most important factor in deciding whether to accept or reject a change.