- Start by registering all changes - This is simple. Once you have roughly defined what constitutes a change (i.e. vs. service request) for your organization, create an RFC form template to capture basic change details such as: Name of change owner, IT component being changed, related components, planned change date, change results (including actual implementation date). The RFC form can be as simple as an Microsoft Excel spreadsheet, a word document, a Lotus Notes database form or an entry into your existing Service Desk tool. The idea is to create a system where everyone can view prospective changes.
- Use the same naming system used by the service desk - Very important!. No need to create a new naming system. Using the same naming system currently being used by the servuce desk is the best way to quickly categorize and record changes. In essence, this is your current list of Configuration Items. It may not be perfect but, it's a system that everyone is familiar with and allows you to be able to begin registering your changes relatively quickly. By using this information, you will be able to match Incidents to Changes and by dong this you are better able to trace the source of Incidents and make improvements to your Change process (so as to reduce incidents caused by change)as it matures. Over time, you may wish to expand the categories for both the Incident and Change Mamanagement processes.
- Determine 3-4 broad categories of Change - This activity is important but less so than the first two when getting started. Remember, what's important is getting people used to the idea of registering their changes. It may be best to wait and monitor changes before trying to divide them into categories according to potential impact on the business. Once you do that and then build a system of categorizing those changes according, you will have a better sense of which changes should require approval and the level of that approval. In general, you'll have some changes that are pre-approved (Standard), some to be approved by the Change Manager, some to be presented to CAB, and perhaps some that require an even greater level of approval. And that brings us to the last point.
- Build a simple CAB to review changes - Again, not as important as the first two items in this list. However, it is a good idea to start to assemble a group of stakeholders to review complex changes (those, not categorized as Standard or approved by the Change Manager). Initally, the CAB should include a static group of attendees, representing each of the infrasture teams (including the Service Desk). Over time, the group will expand to include other stakeholders. This group should start by meeting once per week to review upcoming changes. To keep the meeting from getting bogged down in discussions of the details of each change, the Change Manager should ensure that the participants should have access to the list of changes prior to the meeting. This should allow the Change Manager to keep the meeting flowing by limiting discussions to only those changes for which there is no agreement. As the process matures, the meeting can become as robust or as streamlined as necessary.
Obviously, there are many other important activities involved in establishing a fully functioning Change Management process.
So don't delay. Get your Change Management process up and running today!