Demystifying Change Management

Sometimes, IT people will mention "Change Management" when discussing deadlines and schedules relating to the IT part of web site deployment. To some, this can conjure up visions of "Mordac the Preventer of Information Services" from the Dilbert comics. It's really not like that.

Wikipedia informs us that "The objective of Change Management in this context [Information Technology] is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to controlled IT infrastructure, in order to minimize the number and impact of any related incidents upon service."

Change Management isn't some top secret bureaucratic plot to keep change from happening in IT. It's all about managing change. Think of it as an editorial board for IT stuff.

A Little History

When IT departments start out, they are usually small and agile. It's easy to make changes and coordinate those changes with the other person (or two) in the office so other systems or processes aren't adversely affected. As the departments grow, coordination becomes more complicated. At some point, changes are made in one system which cause another system to malfunction. It's not done intentionally nor out of incompetence; it's just that better coordination and accountability is needed to avoid problems.

This is where change management comes in.

In many organizations, here's how the process works:

1. Someone, usually outside of the IT Department, requests changes to a process or application.
2. The IT person(s) assigned to the project make the required change in a test system.
3. The requester tests the changes in the test system. If the changes work properly, the acceptance is documented. Otherwise the process goes back to step 2.
4. The changes are presented at a change management meeting. This is done to allow others to learn about the change and speak up if they believe the new change will adversely affect other systems.
5. If there are no objections, the changes are approved in put into production on the "real" system. Otherwise, more testing is done to make sure no adverse affects will occur.
6. The requester does a final test and acceptance is documented or the process goes back to step 2.

There is usually paperwork involved which is kept on hand for a predetermined period. In some organizations those documents are reviewed by auditors on an annual or semi-annual basis.

Testing is extremely important and probably the most important part to the Marketing people. When asked, test promptly and thoroughly and respond. This will make the process go much more smoothly and changes will get done more quickly. Having a formatlize procedure in place to document testing an acceptance is good for Marketing too, because it helps ensure things aren't rushed into place before they are ready.

Change management processes vary from organization to organization. Marketing folks: get with your IT counterparts and ask them about change management in your company and how you can help them get through the process more smoothly. What you learn will benefit everyone.

Image credit: apesara