Change Management

I have introduced Change Management procedures in several companies, it is always the result of outages caused by changes the IT staff have implemented. Without proper communication, testing, and planning, outages are likely to occur, this results in lost revenue to the business, and undue stress on the IT staff.             

No one likes to do paper work, IT technicians, and programmers are no different. At first they see the change management process as bothersome paperwork that gets in the way of them getting anything done. Implementing change management is as much about education, and changing peoples perceptions as it is about managing change.

Misperceptions about Change Management are not limited just to IT, the business too will see this as a hindrance to reacting quickly and will try to work around the process. Implementing these processes takes time, IT associates have to grow comfortable with the process and the see the benefits of a more stable environment. Once the environment begins to stabilize, business leaders will buy in to the process.

So how do we begin? I have found it very useful to start with a stripped down simple process, get it well established and then, begin adding more substance. Make your process fit on one page, I call this a OnePageWonder.

The change process I use addresses the following areas.

Change Committee

The Change Committee is made up of key IT personal and representation from the business. The Change Committee reviews requests, and approves or rejects the change. Rejections are usually the result of a need for more thorough testing, a rescheduling of the change due to interference with some other process, or a need to take services down. There is generally a committee Chairman. The Chairman's role is to direct the change request meetings and to approve Emergency Change Requests.

Change Administrator

The Change Administrator's role is to document change requests, and communicate to the organization about upcoming changes. A group may serve this role so that the process is not dependant on any one person.

Change Request

The Change Request is the form used to submit requests and document the change. This may be a simple text form to begin with, but I find that a web based form attached to the incident management system preferable. This form should include the following.

Change Requestor - This is the person requesting that a change be made.

Change Technician - This is the person implementing the change.

Change Request Date - This is the date the Change was requested.

Change Date&Time - This is when the change is going to be implemented.

Duration of Change - This is how long it will take to implement the change.

What's Impacted - This is a list of all systems, processes, offices etc that might be impacted by the change.

Backout plan - This is a detailed description of what happens if the change fails and needs to be pulled out.

Documentation - This is the new or revised documentation associated with the change.

Test Plan - This documents how the change was tested and any relevant test results.

Emergency Change Request

The Emergency Change Request is virtually identical to the standard request form except it needs to be implemented outside of the regularly scheduled change window. These are usually the result of some outage and must be done immediately, this is an area of caution. It is very easy to slip into the habit of allowing last minute changes, avoid this if at all possible.

Change Request Meeting

A regularly scheduled meeting should be held to review change requests. Participants in the meeting should include all members of the Change Committee, the Change Administrator, the Change Requestor, and the Change Technician.

Change Review Meeting

A regularly scheduled meeting should be held to track the status of changes. I prefer to make this part of a daily status meeting. The purpose of the daily status meeting is to review any service impacting issues, changes that have gone in since the last meeting are reviewed and any problems caused by the change can be remediated. I make it mandatory for anyone implementing a change to attend this meeting. If a change caused a problem it is flagged by the Change Administrator and reviewed in the next Change Committee meeting.

What kinds of things require a Change Request

This will vary somewhat from site to site but in general anything that changes your production environment. Some examples of things that require a Change Request are, any production program change, hardware installations, OS patches and upgrades, network changes, any shutdown of production system other than regularly scheduled reboots. Things that don't require a Change Request might be user add/delete/changes,  installation of a new application on a user desktop. Remember this will change as your process matures, don't try to bite off everything right from start. Establish your process and gain acceptance throughout the organization.

Sample Documents

The Change Process Document

The Change Request Form

Home | Resources | Gadgets | FAQ | Catalog

Questions or problems regarding this web site should be directed to Ray.Valentine@ITSD4SMB.com.
Copyright © 2006  ITSD4SMB. All rights reserved.
Last modified: 02/22/07.