SLA's and Incidents

General discussion on all aspects of the IT Infrastructure Library (ITIL)
Post Reply
User avatar
tolman101
Senior Itiler
Senior Itiler
Posts: 44
Joined: Sun Sep 25, 2005 8:00 pm
Location: Sweden

Fri Feb 19, 2010 8:32 am

Is it appropriate for an incident priority to carry associated resolution timeframes if the service levels for a particular system are already described in the agreement documents for those services?

For example; System A may have a service level of 24/7 4 hours. This would mean round the clock support with 4 hour resolution time. System B may have a service level of 8/5 8 hours. This would mean office time support with an 8 hour resolution time.

You might therefore conclude that if a low impact incident is received on System A a high priority should be assigned due to a short (4 hour) lead time in the SLA. But then what happens if System B has a complete stop but resolution time of 8 hours in the SLA. You could argue that this system requires a lower priority due to the SLA requirements but the impact to business is certainly bigger.


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

Fri Feb 19, 2010 9:27 am

tolman,

your concerns are valid.

Firstly I can't imagine deferring a high impact, high urgency incident to resolve a low impact, any urgency incident just because it is on a tighter SLA. Well I can, but it would be very poor service.

I hold the view that incident resolution has to be managed on the basis of getting services restored as quickly as possible for the customer, entirely irrespective of any SLA.

Priority is entirely about using limited resources in the most effective way for the business. If you have the resources available when an incident occurs then you just get on with fixing it right away, without looking at the SLA. If you don't have enough resources for the outstanding incidents then you assign to the ones with the highest impact/urgency factor every time.

An SLA should be more focussed on overall performance than on individual events. (There is at least one long thread on the pros and cons of placing individual incident resolution promises in an SLA).

An SLA not a licence to defer work.
"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
rpmason
ITIL Expert
ITIL Expert
Posts: 105
Joined: Thu May 24, 2007 8:00 pm
Location: USA

Fri Feb 19, 2010 1:50 pm

Diarmid wrote:Incident resolution has to be managed on the basis of getting services restored as quickly as possible for the customer, entirely irrespective of any SLA.

Priority is entirely about using limited resources in the most effective way for the business. If you have the resources available when an incident occurs then you just get on with fixing it right away, without looking at the SLA. If you don't have enough resources for the outstanding incidents then you assign to the ones with the highest impact/urgency factor every time.

An SLA should be more focussed on overall performance than on individual events.

An SLA not a licence to defer work.
Once again, I want to copy and paste a Diarmid quote and hang it on my wall.
Ruth Mason
USA
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Fri Feb 19, 2010 2:42 pm

No charge Ruth 8) But correct my typo first. I like to pretend I have immaculate English :roll:
"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
tolman101
Senior Itiler
Senior Itiler
Posts: 44
Joined: Sun Sep 25, 2005 8:00 pm
Location: Sweden

Fri Feb 19, 2010 3:32 pm

In reality I couldn't see the SLA based incident priority working so I thought it worth asking the question. However, going by your view Diarmid it would seem that there is no need for the prioritisation activity to take into account any SLA. How therefore, would one go about describing what constitutes a high impact/urgency incident over one that is not of high impact/urgency?

The old classics are of course numbers of users impacted, potential financial loss, perhaps even risk to health or confidence in the company. All of which could be a bit fluffy and very much a judgment call.
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Fri Feb 19, 2010 3:58 pm

Impact and urgency should always be quantified as much as possible. There will always be an element of judgement because it is not easy to quantify accurately at short notice. However that is only a real problem when two or more incidents occurring around the same time all seem very important. The better you understand your customer's business the better you are able to make the judgement.

Ideally the business will decide each time, but because of the timescales that is not usually practical. Certainly if you have doubts in a particular situation and it is possible, you should quickly consult someone in the business who has the knowledge (and preferably the authority also) to advise or decide. It is not always wise to just accept the view of the user who reports the issue; much better to get a descriptive account of what it means to them.

One thing the business can do is define the order of criticality of their services. They may have to do it anyway in order to sequence disaster recovery actions. But even that is not clear cut because the timing of an incident pays no attention to the average importance of the affected service(s) and also because some things are significant within minutes, or less, while others might be okay for a day or two but longer could be fatal.

Your SLA, combined with service descriptions, could contain information relating to how priority is to be evaluated and under what circumstances special consultation or notification is required and could identify contact and authority sources. But it would be dangerous to infer too much just from the comparative service levels specified.

I know your list was incomplete and I won't bother with other ideas, because they will all be more obvious to you in your particular organization, but the one I have some trouble with is the first. I have seen cases where number of users affected was taken to extremes and a single user ignored despite their immediate task being vital to the whole organization (like completing a major tender proposal by an imminent deadline. That's the extreme case but ten people dealing with their customer enquiries (say, benefits enquiries) could take precedence over fifty staff filling in their time sheets.
"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