IT Change Management Process Best Practices

In IT Service Management there is a process called IT Change Management. The IT Change Management process is based on the ITIL framework. The IT Change Management process standardizes changes to the IT infrastructure by managing the change lifecycle. Standardizing the change management process is important to be efficient, accurate and to minimize the negative impact on customers, IT services and operations. Having a rigorous change control process is an important factor to be considered as having a mature IT operation. Following a structured change process also allows the changes to be scheduled to avoid multiple change implementation to be in conflict. Prioritizing changes will make sure that changes with the highest priority will be implemented first.

IT Change Management Requests

Changes to IT infrastructure are initiated through the Request for Change (RFC) process. The request for change form is a formal request for the implementation of a change. The request for change form provides all of the information required to review and approve changes. Requests for change can be initiated for several different reasons.

  • Reactive to incidents – Changes can be initiated to eliminate problems in the IT environment which has failed and caused incidents.
  • Proactively prevent incidents– A change can be implemented to eliminate potential problems in the IT environment before it fails and cause incidents.
  • Compatibility changes – A change is initiated because an associated service has or will change. The change is focusing on keeping a system compatible with the associated system.
  • Capability enhancement – Changes can be initiated by the business as part of deploying, upgrading, removing or configurating IT services and applications.
  • Operational changes – Low-risk routine changes are initiated during normal operational activities.

Type of IT Change

  • Standard Change – A low-risk change which occurs frequently and has a low probability of failing. A standard change is pre-approved change which follows a standardized implementation process. Since they are pre-approved, they do not need additional Change Management approval. However, if a standard type change starts causing incident trends, they will be reviewed to modify or revoke the standard classification.
  • Normal Change – A change which follows normal process flow. Requires approval from approvers associated with the impacted system, the Change Management team and the Change Advisory Board (CAB).
  • Emergency Change – A change needs to resolve an outage or a pending outage associated with an incident. The incidents that drive emergency changes are most likely critical or high priority under the Incident Management direction. Approval of the emergency change requires approval by on-call senior leadership and the Change Manager or designate.

Managing IT Change Management Risk

Customers expect their IT services to be stable and be available to perform their function without unexpected results. Customers also want their IT services to evolve with their changing business requirements. When we say evolve, it means the IT services may require one or more changes to upgrade functionality, enhance service and improve stability. Changing IT services introduces risk. A failed, partially successful or poorly designed change may impact stability. As an IT professional, minimizing risk when introducing a change is critical.

IT Change Risk Assessment

When a change request is created, risk must be assessed. Initially, the risk is assessed by incorporating a risk calculator. A risk calculator is part of the change request form. It asks a series of question to help the change requestor assign a risk level to the change. Through the series of questions, the change risk can be quantified by the impact it will have on the services and probability of the change to fail. The following are examples of questions to assess the risk level.

  • Does the change impact more than X amount of people?
  • Does the change affect more than one location or site?
  • Does this change need to be done during business hours?
  • Will this change be performed outside of the established maintenance windows?
  • Do you have a backout plan for this change?

IT Change Management Roles

As with all ITIL processes, there are defined roles and responsibilities in IT Change Management.

Change Manager – This the process owner for Change Management. As a process owner, the Change Manager has the responsibility to ensure the change process is following the approved Change Management process. The primary responsibilities are defined as;

  • Ensure the official approved Change Management procedures are current, available and everyone involved in the change process has been trained.
  • Ensures that all change related activities are being performed as per the established change procedure.
  • Is the principle that facilitates the change advisory board (CAB) and their meetings to review higher impact changes.

Change Coordinator – A change coordinator is part of the change management team and has delegated authority from the Change Manager to review and process change requests and other associated activities.

Change Advisory Board (CAB) – Technical experts, leaders, and decision-makers can comprise the makeup of a Change Advisory Board. This is a group of people with the responsibility to review changes to the IT environment. They have the authority to approve, reject or request additional information on proposed change requests. The CAB is lead by the Change Manager who ensures the appropriate staff are involved and processes are followed.

Change Requestor – The change requestor completes the initial change request and provides all the documentation needed to review and process it. Typically, the requestor of a proposed change request will represent it at the CAB meeting and answer questions related to the change.

Change Approvers – When a change is proposed to an IT system, approval is needed from specific stakeholders of the impacted system. The specific change approvers are based on the specific system. Examples of change approvers can be application owners, business leaders and IT groups such as database, network or other areas depending on the system being changed.

IT Change Management: Measuring Success

Change management activity on IT services can cause instability, service outages and faults that generate incidents. All this change activity and resulting data can feed into Key Performance Indicator (KPI) reporting tools. KPI reports are the raw data for specific measurement. There are so many available change management KPI metrics to measure change management processes that you may become overwhelmed. Many companies will publish daily, weekly, monthly and annually KPI reports. These raw KPI reports may be useful to IT management monitoring how the IT change management process is performing. However, the business and ultimately our customers typically want to receive reports at a higher summary level. Individual KPI reports tend to be over detailed and very specific to the point where management and the business may not find them useful. They value reports that summarize the status of IT services to validate if they are stable, highly available and are error free after upgrades and customizations are applied. With so many KPIs available to us, how do we produce reports to let us know if our IT change management process is successful? Is the IT change management process achieving the outcome we are striving to achieve?

IT Change Management Critical Success Factors (CSF)

Combining specific KPI reports and summarize as groups can help us determine if we are meeting the IT change management outcomes we desire. We can determine our outcomes by building Critical Success Factors (CSF). Every company and departments within companies have different values of what outcomes of IT change management are most important. To start building CSFs, you need to meet with stakeholders such as IT engineers, business partners, IT management and possibly customers. Listen to their feedback and understand what is working and what may need improvement. Examples of improvement areas which may need a CSF are;

Change quality

A CSF for change quality is focused on the effectiveness and efficiency of each phase of a change request life-cycle. A company could have an overall change quality CSF for the entire change life-cycle process. However, the most effective change quality CSF would allow the ability to drill into each phase. One or more CSFs could be created for the following change request life-cycle phases.

  • Change request forms – Measurements can focus the number of change request reworks and reason codes for rework.
  • Successful implementation plans
  • Change communications
  • Change validation testing
  • Change back out plans
  • Changes causing incident and outages.

Specific KPI reports used to build a CSF for change quality could include feedback surveys, outage reports, change needing backup restores, unsuccessful change data, number of incidents and such.

Change duration

A CSF group for change duration is focused on the time and energy into creating, processing, approving and scheduling request for changes. The overall change duration measurement includes total time from opening the change request to closing the change after implementation. An effective change quality CSF should also allow the drilling into the durations between each phase of the change request life-cycle. Being able to drill into the duration of each phase can uncover where the process and resources are constrained.

IT Change Management Key Performance Indicators (KPIs)

Feedback surveys

Post change and related incident feedback surveys can point to issues with the change management process. Obtaining both a rating score and comments will provide very useful data for making improvements.

Change request backlog

Change request status currently in the initial request to implementation stages. Reporting on the number, percentage and current stage of backlogged change requests is very useful. Backlogged change requests can identify resource constraints and process bottlenecks that need to be reviewed.

Average change completion duration

This is a measurement of average change completion duration measured between the initial change request and change closure. Useful variations include duration between stages such as initial request, approved, scheduled, implemented and closed. Also measuring the change completion duration by change type, risk level and IT system category can be useful.

IT service outages caused by change

Percentage of changes causing IT service outages due to the implementation of planned changes. IT service outages should include unplanned outages. Variations of outage data could include the number, percentage, and duration.

Urgent change data

Ideally, you want all changes to follow the standard change process. Expediting a change request as an urgent change exponentially increases the potential risk of the change to fail or create quality and performance issues.

Unplanned outage due to changes

Changes to IT services routinely include planned outages to IT services during the change window. Unplanned outages mean that the IT service becomes unavailable or degraded due to the change and was not expected. Unplanned outages due to changes generate incident and can be measured.

Unauthorized change activity

Unauthorized change activity is a significant risk factor. All infrastructure and IT service changes must be managed through the change management process. An unauthorized change can be detected through the consolidation of the Configuration Management Database (CMDB). A change in infrastructure for which there is not a change registered is considered as unauthorized.

Changes scheduled outside the maintenance window

Implementing changes during a maintenance window for an IT service introduces less risk. A maintenance window is an agreed reoccurring period of time where IT and the business plan for IT service downtime.

Backed-out changes

If a change has issues being implemented completely or fails the validation testing, the change may need to be backed-out. Measuring the number of changes that were rolled back relative versus successful changes is a good measurement of the change process. Understanding what percent of change need to be backed-out and why can leaded to many change improvement projects.

Incidents caused by changes

If a change causes one or more incidents, it is important to associate incident tickets to the change record. Understanding what changes caused incidents will make it possible to identify specific change issues needing to be addressed. Through continues improvement initiatives these issues can be corrected leading to a reduction of unplanned interruption or degradation to IT services.

Rate of change activity

Is the volume of change requests growing? What periods of time are the busiest? Measure the number of changes opened and closed in a given time period.

 

 

 

 

 

 

Be the first to comment

Leave a Reply

Your email address will not be published.


*