Posted: Mon Jan 24, 2005 8:43 pm Post subject: Setting incident priority
I'm trying to setup a manual to determine priority for our servicedesk. We are an internal servicedesk for a local government in the Netherlands. We are always having big trouble to set priority correct. Theory of this sounds easy but when trying to work it out in a practical way it seems gut-feeling is the biggest decisionmaker. This gut-feeling is feeded for a large portion by the way the customer acts. So if customer makes it sound like it's terrible the incident gets high priority 9 out of 10 times.
I would like to make this more structured. I thought this was easy but it's not. The biggest problem is that the servicedesk can not detirmine the urgengy and impact of every workprocess in the company. Besides that a certain workprocess might have only normal priority most of the time but at certain days (for example when payments must be done) it is high priority.
So far I came up with a Impact-table thats based on the impact it has on the end-customer (Civillians in our case).
For the urgency-table I was thinking about the number of employees affected by the incident.
But however I put it, these tables raise just as many questions as answers. It gets stuck by the information our users give us.
Some people always say their working processes are disrupted so badly they cannot do anything anymore. How a servicedesk can determine this is really the case? The priority tables don't seem to help in this.
We usually start by asking the business to decide what it's critical business applications/processes are.
Then we agree with them at a managerial level which ones they consider should be responded to as critical...when staff cry wolf, we action their job at a high level, because they may not be crying wolf...but this information is fed back to the business managers who made that agreement to educate their staff.
Then the SD staff assign priority/serverity relating to how impaced those business aplications/processes are - which comes down to, what systems are impacted, how severly, how is this effecting the business, and how many users are impacted.
eg, if the payroll system is down, and it's payroll day, that's either urgent or critical, depending on how the client management team defined it, but if the whole network is down, and everyone can't work that's critical.
It seems like the decision on priority is being made at the user level, where it needs to be agreed first at the managerial level, then educated to the user community.
You need agreement and support from managers so they can re-educate staff who try to jump the queue.
The SD Team need a list of business critical applications to refer to.
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Sun Mar 13, 2005 4:58 pm Post subject:
there are a lot of variables that feed into this kind of a problem - and there is probably a limit to what you can achieve without going 'upstream' so to speak.
The 'Guest' post made a very important point about the role of Service Level Management in defining urgency.
Urgency is the priority weighting an incident will receive on the basis of the service disrupted - regardless of what the end-user is telling you. It should be negotiated with the business customer for the service in question.
Which goes to another higher level issue - what is your incident classification based on? I've noticed there seems to be pretty much two approaches taken:
1) classifying incidents against CIs - that is the thing, what ever it is that is judged to be the locus of the incident - where the disruption occurs, like cpus, hard drives, MS Office, etc, or
2) classifying incidents against services - that is the business capability being disrupted - eg, email forwarding, monthly client account reconciliation, etc.
Personally I think the worst-case scenario is when the classification schema mixes the two - but that may just be my personality
My feeling is that one serious problem with CI based classification is that you cannot easily assess the urgency in terms of Services - that is, how do you get from a CI going belly up, to an agreed urgency that was previously negotiated with business customers.
So to cut to the chase - without some maturity in your configuration management (a mechanism for seeing the relationship between CIs and Services at the front end of the incident management process) and some maturity in your service level management - you cannot objectively assess urgency - and urgency as a result will be whatever the end-user reports it to be.
Impact can be a little simpler - but bear in mind that it should be objective. Like starting with a simple measure of how many end-users are affected.
And this works better with CI based classification - obviously if a monitor on a desktop dies then 1 user is impacted (usually), whereas if a switch goes out, it may be every users on a sub-net. But again configuration management data will be required if you want to know objectively how many end-users are connected to that sub-net.
In the end you can only improve this part of incident management incrementally - and there is unfortunately no real substitute for knowledge of the business at the Service Desk.
And there is a cultural issue here as well - if you see Service Desk staff as call-centre cattle, you really can't move forward that far on this issue. Their people-skills and knowledge of the business are critical.
One thing I struggle with constantly is getting others to understand the difference between a process and a skill set - usually the problem is that people think they are implementing ITIL processes, when in fact what they are doing is creating a new kind of skill-based IT 'hero', the person on whose tribal knowledge and customer handling skills the whole outcome rests. However the reverse can be the problem too - there are points at which skill sets are a critical adjunct to process, and accurately assessing the severity level of an incident (partly by getting the right information from the reporter) is one of the sill dependent aspects of Incident Management.
As an aside - at one time, we added a "requester-urgency" field to our incident reports. This was not used in determining severity levels, but it was there for the analyst logging the incident to use a a subjective judgment of how 'bothered' the end-user was, based on their own expertise and experience in handling people. It was also the field the end-user could fill in when submitting through the self-serve web site. During the life time of the incident, the Analyst could use this field as a guide to how to 'handle' the end user when interacting with them - it turned out to be quite useful if only because it served as a reminder of the difference between psychological severity and an objectively set severity based on business rules.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum