cost of incidents due to failed change

An open discussion on issues related directly or primarily to the service or help desk.
Post Reply
User avatar
dilukd
Newbie
Newbie
Posts: 2
Joined: Fri Jan 20, 2012 7:00 pm

Sat Jan 21, 2012 2:05 pm

Hi,

I've just been asked to look at a way of calculating the cost of incidents caused due to failed changs.

Has anyone ever done something similar and able to share your experienced and how you went about calculating this..?

Cheers


User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Sun Jan 22, 2012 12:51 pm

You need to become very clear as to what you are wanting to achieve.

Failed changes will either not have been implemented or will have been regressed and therefore they will not cause incidents. Except in the situation where they were intended to resolve a problem (i.e. a potential cause of incidents), but even here it is hard to say that the failed change caused the incvident, because the problem had a lot to do with it.

Now if you mean incidents caused by changes that have not failed (although the fact they cause an incident may lead to them being regressed and thus failed), you may want to distinguish between fualty changes (design and testing issues for example) and poorly executed implementations (planning and communications issues for example).

Once you have sorted out issues like these, you simply have to extract the cost details of the relevant incidents from your overall incident cost report.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
User avatar
dilukd
Newbie
Newbie
Posts: 2
Joined: Fri Jan 20, 2012 7:00 pm

Sun Jan 22, 2012 2:40 pm

Hi Diarmid

Apolgoies. I don't think my initial message was quite clear.

What i'm looking to cost out is your second point which is changes implemented which subsequently result in an incident and are then rolled back.

So guess i'm need to understand how to cost an incident i suppose. to help with the above. You've mentioned a incident cost report. This is something we don't do in our organisation at the moment. Would be something of interest to understand more of this, if you have anymore info on how costings work.

Cheers
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Tue Jan 24, 2012 6:43 am

dilukd,

I thought that might be the case.

I see great risks if you start costing some incidents, but not all. It makes a big difference to whether the costs you come up with are 0.17% of your total incident costs or 73.45%, and, if you don't know, then you are likely to misjudge how serious the issue is and either over- or under-react to the report.

I'm not sure there is a simple formula for calculating (estimating might be the best you can do) the cost of an incident.

you can look at:

- staff unable to work (but more normally they will rather resort to lower value work and you need the difference)
- lost business (this has to be based on known factors, not some salesman's say so)
- investigation and repair costs (this is more under your control because it will mostly be service management staff doing it)
- opportunity costs within each of business and IT services

It might be possible to have some rules based on the importance of the service (at the time if it is periodically more or less important), the duration of the incident and the number of people affected. This will not be accurate but has the merit of being practical. With careful design and frequent review, it should be "ballpark" accurate for most cases and the really exceptional ones are likely to be getting screamed about at the time and therefore you could adjust your calculation in those cases.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Post Reply