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.

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.

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.