Computing the Change Success Rate

The ITIL change management process is tasked with balancing the risk of making a change against the impacts to the business of not making a change. While this process has earned a bad reputation when not properly implemented, it is an enabler that can increase speed and agility by reducing levels of unplanned work associated with failed changes.

A key metric to track for oversight of the process is the change success rate (CSR). When employed correctly the process becomes effective. We should see correlations between improvements in the change success rate, a decline in availability related incidents and thus reductions in unplanned work. In pursuit of this metric, we need to establish how it is computed.

People basically accept that the CSR is a percentage created by dividing the number of successful changes by the total number of changes multiplied by 100. Like many things, the devil is in the details because a great many definitions exist about what constitutes “successful changes” and “total changes”.

In terms of successful changes, some groups will say a change is successful if it “fixes” what is broken and others will add in that changes shouldn’t create incidents or problems. While the latter part is acceptable, the former is not because it mixes processes versus isolating change.

Change management is fundamentally a process designed to manage risks. Incident management is tasked with dealing with deviations from standard operations or things that may threaten standard operations by opening an incident record in the configuration management database (CMDB). In situations where the root cause is unknown and/or a major incident is underway, a problem record may be opened also. Both of these processes have their own metrics.

With change management we need to focus on the changes – not the incidents, problems or other process areas. We need to understand if the changes were planned correctly and were then implemented according to plan. To better focus the metric on change management, a change is successful if it was implemented according to plan without creating Incidents and problems. We do not want to cause overlapping measures by requiring that the related incident be resolved. Resolution isn’t the point of the change management process.

If incidents and problems are not resolved by a change, then those respective records remain open and they can be related through fields in the CMDB. For example, if the change record RFC123 is opened in the CMDB it can be related to incident record INC001, INC002 and PRB004. If the change is implemented per plan without any issues but the two incident and one problem records that required the change are not resolved, then that is not a failing of the change management process. In fact, the change was implemented successfully based on our aforementioned criteria.

Total Changes

An additional element to consider is the definition of “total changes” because that number is in the denominator of the CSR. If the total number of changes reflects only the number of requests for changes (RFCs) submitted through the process then the CSR will likely be unreliable.