Therefore, when properly implemented, a successful Change Management process should have the effect of reducing the number (and severity) of Incidents associated with Change. Ideally, there should be zero Incidents caused by Change.
In fact, this is the entire purpose of Change Management, to reduce the risk associated with change . That 'risk' referred to is the risk of the occurence of related Incidents (or put another way, downtime.) Without the ability to measure and thereby manage this risk, the entire point of the process is missed and no real value is provided to the organization.
How do we measure Change related Incidents you ask?
First, we must begin by managing and registering Incidents at the same configuration level as that of Changes. This means that, there should be only one level of tracking for Configuration Items (CIs). This may sound like common sense but you don't know how many organizations out team has encountered where, Changes were being registered and managed by one set of configuration items and Incidents by a totally different one.
For example, if you track changes to a system at the individual component level (server, network components, app, database, etc,) then you should not track Incidents only at the system level (or worse, by the team that resolves them.) Meaning: also track and register Incidents at the same level as changes are registered and managed.
Also, there should be a one for one relationship between Incidents and CIs and Changes and CIs. No matter how convenient it may seem to ignore this advice, to do differently is only inviting confusion somewhere down the road.
For starters, you will have no idea whether or not your Change Management process is successful because you are unable to determine which Changes caused which Incidents. Without this information, you are also unable to identify weak areas in the process and make improvements.
There is no meaningful way to determine how much rigor or slack to apply to different types of Changes because you are unable to determine their relative 'risk'. The result? A stagnant process that is unable to mature.
Additionally, under these circumstances, the process is likely to become just one of those policies that everyone is forced to comply with but nobody really understands the benefits or the purpose. The danger is that, over time, the process is likely to be abandoned altogether.
Our perspective? That the true value in any process comes from proper design, implementation management and measurement. However, these activities should always be done in accordance with the objectives of the process.