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.