Posted: Tue Oct 03, 2006 4:08 am Post subject: Setting Incident Priorities
Looking for some help, we have been setting incidents as priority 1,2, 3. As you would figure every thing is getting set as Priority 1.
Every one agrees that can't be but is there a rule of thumb that I've missed somewhere. The service desk can call something a priority 2, but if the support staff doesn't agree , tehy handle it when they want to. Then again when the client is the one responsible, it gets to be a continual pinging for uspdate, status etc. Any thoughts folks?
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Tue Oct 03, 2006 6:54 am Post subject:
Mike, priority=impact x urgency. What is your exact (formal) definition of levels 1, 2, 3? Have you / your organisation defined this in terms of impact (#users, money etc.) and urgency (effect on business?).
Joined: Sep 16, 2006 Posts: 3500 Location: London, UK
Posted: Tue Oct 03, 2006 4:28 pm Post subject:
Here is the rule of thumb which we created
for Priority 1 to 5
1 - Any outage or security issue
2 - Service degradation or any Internal Service outage
3 - Any incident not 1 or 2 which is n
4 and 5 are for issues which are not dservice affectig but need to be looked at
The problem is/may that your customers will say 'make this a priority' and your service desk and teh service management community has not received support from mgmt about the new ratings
You need to tell the SD that if it is not an outage, it cant be a P1.
In addition, the customers need to understand the priority scale. The SM need to pass the SLA about the new prioriies to the customers
also get the MGMT of te SD to support the Sd staff _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
As the guys mentioned earlier, priority is the result of the combination of the impact and the urgency of an incident and it rates from 1 to 5 in general, for sure this can be changed accroding to your considerations (you can have Urgent, High, Medium, low as priorities or a rate from 1 to 3 like you currently have).
Usually customers tend to request a high priority for their requests, the Service Desk assigns the request the corresponding priority based on the criterias defined in the SLA with the customer or within the support agreement (depends where priorities and escalation procedures are defined in your case). Part of the support staff tasks is to re-categorize the incident or problem passed to them(incident or problem management activities), thus assign a new priority based on their assessment of the impact and urgency. In such a case, the support staff are accountable for any latency in the resolution or wrong priority assessment in case of a Service Level breach.
Further to suggestions about deriving the Priority from Impact and Urgency, you should also formalize this process and automate it to certain extent. The Urgency should be specified by the User. But the Service Desk should be able to over ride the Urgency by analyzing it. They should be able to specify the Impact.
Based on these two values, the Priority should be derived. Weighted methods for doing this can be helpful.
The service desk can call something a priority 2, but if the support staff doesn't agree , tehy handle it when they want to.
for this, you will need to formalise a SLM process. Once the priority is defined, the ticvket should be worked upon by the support team in the specified time frame. If it does not happen, then the ticket should be escalated functionally.
Hope this helps.
Nikhil _________________ Regards,
cMango.. The Services Management Company
The taste of low quality lingers long after the satisfaction of low price.
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