Showing Service Management Value: Change Management

So far in this series we have reviewed the value of Incident and Problem. When we start to talk about the value of change management some might suggest that this process is a ‘must have’ as it seeks to control the successful implementation of changes to minimize any potential impact on the business.
Not that I had this problem but did you ever pass a test where you scored 99% and someone asked “what about the other 1 percent?” Your rate of successful changes should be a value where someone is wondering what that missing percentage of failed changes is made of.

The reality is that an output of the change process could be incidents. Some might suggest that the percentage of incidents caused by changes could be as high as 80%. This could be many unaccounted for incidents
To be consistent with the previous posts if we were to look at the costs from an internal IT perspective what we would want to focus on would be not what the cost of implementing changes is, rather what the cost of failed changes is. In other words incidents as a result of a change.

Ok, I know you are thinking to yourselves, this is a bit of a stretch. If I was the change manager what is the benefit of showing what I cost IT? If you are asking this you are right on the money. This metric drives the incident and potentially your service desk teams to ensure that your changes are updated accurately as frankly they want the cost to be the result of someone else. It is in their best interest to associate any incident to a change correctly to show where the cost came from.
Let’s look at an example:

Note: these numbers have no value other than to show mathematics you can apply to your organization
Priority
Volume
Duration (average)
Total Duration (minutes
1
100
4hrs
24000 mins
2
200
8hrs
96000 mins
3
700
24hrs
1008000 mins

Staff
Salary/Year
Cost/min*
People
Total Salary
Tier 1
50K
.40
10
500000
Tier 2
75K
.60
10
750000
Tier 3
100K
.80
10
1000000



*Based on 40hrs/week and 52 weeks per year
If we were to suggest that:
Each priority 1 incident required the following:
          ·       2 Tier 1 @ 0.40/min = 0.80/min
          ·     2 Tier 2 @ 0.60/min = 1.20/min
          ·       1 Tier 3 @ 0.80/min
Cost per minute = 2.80

Each priority 2 incident required the following:
          ·       2 Tier 1 @ 0.40/min = 0.80/min
          ·       1 Tier 2 @ 0.60/min = 0.60/min
Cost per minute = 1.40

Each priority 3 incident required the following:
          ·        1 Tier 1 @ 0.40/min = 0.40/min
          ·        1 Tier 2 @ 0.60/min = 0.60/min
Cost per minute = 1.00


So assuming that we have the following incidents as the result of changes last month
Priority 1 – 1 incident which lasted 3.5 hours Cost = 3.5(60)(2.8) = $588.00
Priority 2 – 3 incidents which lasted a combined total of 29 hours Cost = 29(60)(1.4) = $2436.00
Priority 3 – 7 incidents which lasted a combined total of 74 hours Cost = 74(60)(1.0) = $4440.00
For a grand total of $7464.00

While a 99.5% success rate is nice we would like to be in a position to quantify even if it only pertains to the utilization to IT resources.

In my experience one of the challenges of keeping the closure codes updated is tying the incidents to the changes after the fact. In organizations which are not reviewing incidents, problems and changes regularly you may see that your change success rate is fairly high despite the fact that the incidents are not decreasing. By relating the incidents to the according change you can at least improve your reporting, begin a strategy for improvement, which if nothing else improves value.

Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn


Labels: , , , ,