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: Change Management, Continual Service Improvement, ITIL, ITSM, Service Management