Branimir Valentic Changes to IT services fall in the category of common activities. No matter how efficient the Change Management process is, it’s no secret that mistakes happen during change implementation. Some occur for good reason, while some mistakes are hardly explainable. That puts greater significance on the efficiency of the Change Management process.
An efficient Change Management process means that you have control from the beginning through the end of change implementation. Let’s focus on the end of the implementation. What if change implementation doesn’t end as expected? What if it goes in the wrong direction and you need to back out to the state before the implementation began? Both ITIL and ISO 20000 have answers to that question.
What are they?
No matter whether you implement ITIL or ISO 20000, one of the basic postulates of the Change Management process is that there shouldn’t be changes that are implemented without authorization. That could be on a local level (e.g., a network admin authorizes standard changes) or on the highest level in the organization (e.g., Board of Management for major changes). The article ITIL V3 Change Management – At the heart of Service Management can help you understand the basics of the Change Management process and authorization of changes. Before authorizing the change, the change authority (the person or group who is empowered to authorize change of a particular type) needs to ensure that there is a plan to revert to the initial state if change implementation is unsuccessful.
So, a formal procedure that will describe what needs to be done to get back to the initial state is called a remediation procedure. There are several options that could be part of the remediation procedure:
- Back-out – These are activities you need to perform to restore a service (or a certain Configuration Item, i.e., CI) to the previous state (or baseline).
- IT service continuity plan invocation – Activation of that plan will take place in the event that back-out activities don’t help, or in case you stuck with the change implementation and there is no way to go back.
- Other activities – This could be, e.g., reassessment of that change and then setting up a new action plan to remedy the situation.
One of the important items, if you need to activate the remediation procedure, is to have a configuration baseline that will enable the restoration of a known configuration.
When planning the remediation, particular care should be taken when setting and agreeing to (usually, with the customer) triggers and timing for the remediation procedure. I witnessed a situation in the telecom industry when a customer (a telecom company) approved a change to be implemented between midnight and 4 AM. But, the agreement was that, if it’s obvious that the change implementation has difficulties, or it’s obvious that it won’t be implemented on time – the remediation procedure needs to start. And, unfortunately, it didn’t happen once that procedure needed to be activated.
What’s the point?
The point is to have any risks associated with the change implementation under control. Namely, every change (OK, we can exclude certain types of standard changes, e.g., password changes) carries some level of risk. Once you start the change implementation, you’d like to be sure that everything is under control. Planning remediation activities will help you detect possible risks and define appropriate actions.
Another important issue is that if you’d like to have the change (as much as possible) under control, the remediation procedure needs to be tested. Once you are familiar with the procedure, and you have gone through all the necessary steps – you can start the change implementation with much more confidence.
If it happens that the remediation procedure was activated, it’s important that (when you are finished with the remediation activities) a thorough review is made. In this way, your organization will learn something; i.e., even though something happened that was undesirable, you learned a lesson. This way, similar situations in the future can be prevented.
The benefits of having remediation and back-out in place
It seems that having a remediation procedure increases the efficiency of the change management team, as well as that of the Change Management process. And, that’s correct. But, having a Change Management process in place that includes a remediation procedure (and related back-out activities) means that you manage the process. A managed process leaves less room for surprises.
ISO 20000 sets a direct requirement to plan a procedure to remedy unsuccessful changes, and ITIL recommends a remediation procedure as a part of change assessment. No matter what you are implementing, a remediation procedure not only helps you once a change goes in an unwanted direction. It also helps you before the change even starts, and the benefits of that usually multiply – for you, as well for the customer. Who would want more?
Use these free ITIL/ISO 20000 Gap Analysis tools to compare your Change Management process with ITIL recommendations and ISO 20000 requirements.
