June 28, 2010, 7:34 AM — 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.