So, You’ve Implemented a Robust ITIL Change Management Strategy …

Change Management FlowchartChange Management is an important function in most organizations.  It carries more weight than many of the other ITIL functions because it’s the biggest pain point.  It’s a well established fact that upwards of 80% of all outages are self-inflicted.  IT managers are constantly getting heat over deployment that didn’t go exactly as planned.  When you boil that down to lost productivity or missed business opportunities it amounts to a sizable amount of money.  These are just some of the reason Change Management gets so much well deserved attention.

So, you establish a Change Advisory Board.  There is a lot of preparation and documentation that has to go into any change before it’s presented to the board for approval.  Each change is categorized, analyzed, scrutinized, until everyone involved is thoroughly mesmerized.  The time required to get a change approve may also have increased five-fold.  The process is controlled through some rather expensive management software, well documented, well planned, and hopefully well executed.

The question is: After expending all this effort into the Change Management process, expending the resources in additional planning and documentation, and spending all the time in meetings, and prolonging the time required to get a task accomplished, did CM reduce service disruptions and save more money than was invested in the process? Let’s face it; if not, then throw the whole thing out and go back to shootin’ from the hip.

The stakeholders on the board probably didn’t review the detailed documentation that has been prepared.  There are probably only a few people in the entire organization who will ever read it.  The stakeholders only have a few important questions: why is this change necessary, what’s the impact, who or what will be affected, what are the risks, are they adequately mitigated, and is there a viable back-out process.  There are probably a few key people in each business unit who could review the implementation details and provide their respective stakeholder with a recommendation and/or list of concerns and remediations.

Is the CAB keeping any metrics?  Are you aware of how many changes of each category are being implemented? Were they on schedule?  Were the impacts more or less than expected?  Is there a way to relate an incidents as a result of a change to the change in your incident reporting system?  Is all this management making an improvement, or have you just spent more resources managing with no real gain?  When you make a change to the process, does it streamline the process and/or improve the results?

Change Management is good. CM in the context of ITIL framework is excellent  …  but we must always keep focused on the end objective – becoming more efficient and effective.  CM for the sake of CM is a common ill and needs to be tempered with CS (common sense).

One Response to So, You’ve Implemented a Robust ITIL Change Management Strategy …

  • ITIL is definitely coming to be more vital in today’s IT businesses around the world. Thanks for this post, it has actually been an excellent read and I have located it interesting. I wonder exactly how well ITIL is being observed by the various businesses these days? I understand that, in my encounter, it does not always go 100 % to strategy – but thats the reason why Itil is just a structure I suspect. It leaves some components for interpretation of the adopter which is where often points go a little bit of incorrect.