There are times in life when you need to surrender. Give up, admit your defeat. Nobody likes it, but it is a fact of life. It is also a fact of ITSM life. Today, I would like to talk about an example, that everyone will experience sooner or later: a failed change.
 |
| Image credit: rosmary, Flickr.com |
It is not the best moment of the week, when after long hours of preparations and intense work during an implementation window, your change fails. Moreover, it breaks other things as well. Sometimes it is evident right after implementation, but sometimes you find out hours or days later. Sometimes you can apply an emergency change to fix a a pretty apparent root cause, e.g. missing one of the items on the implementation checklist. However, in many cases it will not be possible and you will need to back out the change.
A key to successful backout is to have a plan. Yes, a backout plan, the thing that is often overlooked. After all, you want your backout to be an honorable surrender, not a panic escape. In order to limit damage to the business, and your reputation, you need to stay in control of the situation. To do that, the team of engineers need to know what to do and the Service Desk needs to keep the business informed.
A backout plan is intended to keep you in control. It is your insurance policy against Murphy's Law. Let's be honest with ourselves: we do not insure everything. I have talked about the risk of overdoing things already. Do not prepare a formal backout plan for every change. Just make sure the team can verbally describe how to go back in case things get messy.
You do need a more formal plan for more complex changes, though. Check back tomorrow to see how to do it with little effort.
0 comments:
Post a Comment