In change management there is no middle
Hansel and Gretel left a trail of breadcrumbs to find their way out of the forest. You need to do the same in IT.
by Mark Patterson, ITworld - As the old saying goes, the only thing that is constant is change, and that is doubly true in Technology. IT professionals are inundated with upgrades, patches, hardware refreshes, new hires and layoffs, mergers and acquisitions, ad infinitum. We are still in a period of rapid change in IT. The data center of 2010 is very different from the data center of 2000. While basic business processes have not changed drastically over the years, the technology used to support business has changed very dramatically.
Changes in IT can be huge (as in a major ERP deployment) or minor (such as imaging a new machine). Regardless of the size of the change, all changes require planning and preparation, and the better you and your team do the prep work, the better the change will be.
In all changes, there is a crucial and critical stage, which is when the change is actually applied. Up until this point, you are planning, preparing, training, configuring, etc. At some point, there is the "Go" decision, and it is time to pull the trigger. This is the point that makes and breaks projects, and careers.
All applications of change boil down to the following sequence:
State "A" → Apply Changes → State "B"
State "A" is your environment before any change has happened. State "B" is your environment with the change successfully applied.
When performing a change or upgrade, you start in State A. You do everything you need to do to apply the change, and you push through to get to State B. If, for some reason, you can't press through and apply the change (if, for example, an upgrade script completes with errors), you must return to State A. There is no middle. There is no half way.
Applying a change in IT is like riding on a water slide. Once you start, you are committed -- you are going all the way to the bottom. You can't stop half way down, and you can't suddenly decide to change to another slide.
IT, however, has a critical advantage over water slides: if you do it right, you can always hit the "reset button" and go back to the top. Every change in IT should have that reset button.
You do not want to be half way through an upgrade, have a crucial update fail, and then be stuck with nowhere to go, and no way back. Hansel and Gretel left a trail of breadcrumbs to find their way out of the forest – you need to do the same in IT. The ability to go back must be part of your change management plan.
How do you do this? Well, the more complex the change, the more complex the reset plan, but at its most basic, you must preserve State A so that you can go back to it. You can preserve it by having a backup or snapshot of the environment prior to the change. You can also have your upgrade programs and scripts have a way to undo the changes they make.
Each type of change has its own way to preserve the old state. Here are some examples:
- When applying an operating system upgrade or patch, back up the machine first. Ideally, make a snapshot. If the upgrade fails, apply the snapshot and you are back to where you were. One of the benefits of virtualization technologies is that snapshots are really easy to make.
- When doing a server refresh, keep the old servers racked and ready until the change has been successful. If there's an error with the new machines, reconnect and turn on the old.
- For router or switch updates, save the configuration first. If errors happen during the update, you can re-apply the saved configuration.
Business applications, such as ERP systems, are more complicated, of course, but the rule still applies. There is a crucial upgrade application period, usually done over a weekend or other period of reduced business activity. During this period, a precise set of actions is performed that transforms version A of the system into version B. There should be a series of tests to perform by IT personnel and key users at the end of the upgrade to ensure that the upgrade was successful. If the tests fail, and the errors can't be corrected in time, then the course to take must be to reset, to go back to "A." It is far better to lose face and be able to continue business on the old version than to have the company be hamstrung with a messed-up upgrade.
Of course, it is better to have a great plan, test the heck out of it, and have the upgrade be successful. But even with all the testing and dry runs in the world, there is still Murphy's Law, and it always bites you when you commit yourself without proper backup.
So, remember, when applying a change in IT, there is only State A and State B. If you start going from State A to State B and something screws up, you must be able to get back to State A. There is no middle.