Computing the Change Success RateDon't let incidents and problems blemish the veracity of your change management process, writes ITSMWatch columnist George Spafford of Pepperweed Consulting.
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.
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 shouldnt 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 isnt 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.
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.