provided by: 
Originally published at Internet.com 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.
We must understand the total number of changes taking place in the environment. For most organizations I work with, the total number of changes dramatically exceeds requests for changes submitted via the change management process; especially at the outset of implementing the process.
There are many reasons that people may choose to bypass the process and not report changes but these changes all represent risks to the organization. By failing to account for them in the "total changes" metric we then do not accurately reflect the volume of changes taking place and the CSR metric can not be relied upon.
To capture the total number of changes the following is required:
* The systems in scope must be clear and formally documented. * What is critical to monitor on each system must be formally documented. * A change detection tool must be used to capture all changes both accurately and timely. While manual detection is theoretically possible, automation is essential to do this every eight hours at least and because it requires tedious detailed analysis, the possibility for human error is high.
In summary, the change success rate is a deceptively easy ratio to draw on a white board during a meeting and then program in a report writer. The details underpinning the numerator and denominator require thoughtful consideration, communication to stakeholders and consistent execution.
No single metric can reflect the health of a process and the CSR metric is no exception. When correctly designed and implemented, the CSR will give us an important perspective into the health of change management, which can then be combined with other metrics to influence employee behavior and give management needed information to make decisions.
George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. George's professional focus is on compliance, security, management and overall process improvement.
Author: George Spafford
Read article at Internet.com site