How To Prepare a Backout Plan

Yesterday I talked about why you might need a backout plan for some of your changes. Creating such a plan is one of the least favorable activities of many technically-focused people. That is why the Change Manager should be accountable for getting it done. It should be included with the rest of change documentation, ready to be used if necessary.

A good backout plan should include:

  • low-level, technical instructions,
  • specific communication instructions, with contact names.
The list of technical instructions is created by reversing the order of activities from your implementation plan and describing how to back out from each of the executed steps. It may be relatively straightforward if most of your work is achieved by restoring the most recent backup. Consider a sample backout plan for such a scenario:
  1. Notify the Service Desk about backout plan initiation.
    • (Call them, send an email or raise a ticket - state it specifically.)
  2. Disable user access to the system.
    • (How? List the actions.)
  3. Restore backup taken before the change implementation
    • (List the actions needed.)
  4. Conduct system health checks.
    • (List them all.)
  5. Enable user access.
  6. Notify the Service Desk of successful backout.
However, often the plan will be more complex than it would seem. There might be many more restoration steps, involving various databases, file systems and other areas of the IT infrastructure. The basic template still applies. It needs to be detailed and tailored to every organization and every change. Needless to say, every action should have an owner, so make sure it is clear who does what.

Note how I insist about communicating with the Service Desk. Communication aspects need to be in the plan to maintain control over the situation. Moreover, the business needs to know IT is in control. The Service Desk should take care of projecting the image of control towards the business by issuing regular communication if business impact is severe enough. They will also take calls from dissatisfied users and inform them about the resolution status.

As I mentioned in yesterday's post, it is your insurance policy. It is up to you if you buy it or not. I recommend having it for every complex change, because business continuity and IT credibility is at stake. I challenge you to prepare such a plan for the most complex change you have coming up in your pipeline. Then let others know how professional you are.


Post a Comment