Oct
1
WRITTEN BY:
David Davis
Thursday, 1 October 2009
When you hear that an implementation had to be rolled-back, it’s easy to jump to the conclusion that all didn’t go to plan or that a disaster occurred. In actual fact, it may have been a case of good planning.
Risk and issue planning is a key project management tool to better predict the outcome of any activity. The point is not to plan for a single outcome or desired state, what I call the ‘happy path’, but to identify all possible paths/detours (risks) that your project could take. To enter a change window without this level of planning is akin to taking a journey without a map, a spare tyre, or a road-side assistance policy.
Each risk should be mapped out, with accompanying mitigation plans that will, hopefully, navigate back to the desired state. However, some risks can never be mapped to the ideal conclusion you hope for, but instead a pragmatic course of action that is acceptable to all parties.
Most change activities are undertaken within restricted timeframes, with safety margins applied that allow for operations business continuity. This means everything must go to plan; you don’t have time to scratch your head and wonder why things aren’t working and what to do about it. When things don’t go to plan, one of those pragmatic approaches I referred to, may be to roll-back.
When a roll-back occurs in this context it can only be viewed as a good outcome because it was planned for. On the flip-side, an un-planned roll-back can mean things didn’t go well.
Here's a simple example of mapping one possible path you could take if a hardware installation goes wrong, how to get back on track and when to roll-back.
|
Risk
|
Mitigation to avoid risk occurring
|
Treatment if risk eventuates
|
|
Hardware failure
|
1. Configure and test the device in the lab prior to the change being implemented.
2. Prior to the implementation, arrange the following for the change window:
a. easy access to the vendor for phone assistance
b. a configured and tested spare device is to be available.
|
1. If the device fails during implementation, speak to vendor to try and resolve.
2. If fault can not be resolved with vendor, use the spare device.
3. If spare device fails, roll-back to the old device.
|
A point to note: roll-back is not the first treatment. Secondly, agree with all necessary parties that the last resort is a roll-back. So, if during the change window this risk becomes an issue that results in a roll-back, whilst not the desired outcome, you have reached the optimal outcome and can feel confident that you have done your job in planning and executing your change.