ITSM Change Management

To most people in IT, change management will probably look something like this SOP (click here for the supporting templates - IT.CHM prefix). I call this the technical change process as it revolves around data centre activities. 

If service desk tickets provide management visibility to service desk activities, then technical change tickets provides visibility to the workings within the backend operations team. In many organizations, the technical change process is implemented around the same time as the service desk function but due to regulatory scrutiny(eg. SOx), it has a tendency to become very 
bureaucratic if left unchecked. It is important the technical change owner ensure the process strikes a good balance between optimizing the business risk and yet don't impact the business speed to market.

Some consideration when setting up Technical Change Management :

• Change Advisory Board(CAB) Structure
• The hierarchy of CABs should be a close mirror image to the organization structure. The highest CAB level must have business representatives. 
• A good starting point is identifying all the leadership teams within the organization and understanding how the IT infrastructure operates around their business processes. The members in each CAB must see the value in the request for change tickets(RFCs) up for their review. If they do not, the CAB needs to be broken down further. A typical setup in large enterprises:
• Enterprise CAB: 1 ECAB. Normally consists of the business leadership team. This includes the CIO. Changes to the enterprise architecture and any operational changes that can possibly affect the organization's overall image is reviewed at this level.
• Main CAB: Only 1 MCAB. Normally consists of the global service/process owners and the regional IT heads. Changes that has an impact globally are reviewed in this CAB. 
• Regional CABs: Multiple RCABs. Normally consists of regional service/process managers and the respective regional IT leadership teams. Changes that only impact the region are reviewed in these RCABs.
• Process
• Ensure that technical change management is tightly coupled with IT asset management processes:  
• A RFC cannot be created unless the asset exists in the inventory. IMHO, most change tools should have this as the first mandatory field instead of the standard CTIs
• IT asset coordinator attendance is compulsory in CABs
• Changes requiring inventory updates can only be closed by the IT asset coordinator.  
• Always design and modify the change process with this in mind: 
• Make the documentation work as painless as possible for the technical folks but no bypassing these 3 important steps:
1. The appropriate risk assessments were conducted 
2. The appropriate authorities gave approval before the change started.
3. There is documented proof for Step1 and 2.
• Some possible solutions:
• Create templates for similar type of changes
• Create a pre-approval changes list: Change requestors creates a normal RFC at the beginning of the year for the routine, low impact changes (eg. facility maintenance,  virtual server provisioning) and request that it goes onto the pre-approval change list. Subsequent RFCs are created as informational RFCs and need not go through the approval process for the rest of the year. 
• If change management is really affecting the business speed to market its products/services, it might be a good idea to consider engineering the change tasks into the IT system itself (with all Service Design considerations taken into account naturally)
• For project that will introduce changes to the production infrastructure,  have the project manager coordinate the creation of the required RFCs as early as the project planning stage. These RFCs can be broken down into logical chunks (normally within 1 change cycle) and the detail tasks fleshed out closer to the change date. 
• KPIs
• Technical change management is not working if expedite and emergency tickets is trending above 15% over a few months. It would be wise to identify what's causing the high number of 'non-normal' changes and take steps to remediate the problem.

Now, if you take one step back from technical change management, you would notice that RFCs can come through many other ITSM processes. Some of these RFCs don't quite fall into the typical 5 days resolution SLA tickets, technical change management nor the PMO process. These could be requests for policy or procedural change, corrective actions after a major incident or audit and many more 'gray area' change requests. Tracking the implementation of these 'gray area RFCs' are just as important hence a process such as this (I call it Service Change Management and here is its template -prefix IT.SCH) helps tidy up the loose ends. Of all the change management processes, Service Change Management is best implemented after the service request, technical change and PMO processes are stable.

Updated: May 2012