When you hear that a system 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 and 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’s 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 unplanned 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
A hardware failure
Mitigation to avoid the risk occurring
- Configure and test the device in the lab prior to the change being implemented.
- Prior to the implementation, arrange the following for the change window: easy access to the vendor for phone assistance, and a configured and tested spare device is to be available.
Treatment if the risk eventuates
- If the device fails during implementation, speak to the vendor to try and resolve.
- If fault can’t be resolved with the vendor, use the spare device.
- If spare device fails, roll-back to the old device.
A couple of points to note:
First, a roll-back isn’t the initial treatment.
Second, 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, while not the desired outcome, you have reached the best outcome and can feel confident that you’ve done your job in planning and executing your change.
