« ARS: Discovery & CMDB | Main | ARS: Reporting using Mid-Tier and CR 10/CRXI/BOXI on Seperate Server (Windows) »
October 25, 2007
ITSM Incident Priority & Priority
ITSM Incident Priority & Priority Weight
In the Incident Management configuration, weights are applied to the impact and urgency values (behind the scenes). When a support staff member selects an impact and urgency of an Incident, the Incident Management application adds the numerical weights together in order to calculate the priority weight, then assigns a descriptive priority (such as "Critical").
You can increment/decrement the Priority Weight to provide a more granular level of prioritization. If increasing or decreasing the Priority Weight causes the weight to cross a priority weight threshold to the next level of priority (say, from High to Critical), the Priority field is updated to reflect the new priority.
The default weight values (Impact + Urgency = Priority) include:
| Impact* | Impact Weight* | Urgency* | Urgency Weight* | Priority* | Priority Weight* |
| 4-Minor/Localized | 0 | 4-Low | 0 | Low | 0 |
| 4-Minor/Localized | 0 | 3-Medium | 10 | Medium | 10 |
| 4-Minor/Localized | 0 | 2-High | 15 | Medium | 15 |
| 4-Minor/Localized | 0 | 1-Critical | 20 | High | 20 |
| 3-Moderate/Limited | 3 | 4-Low | 0 | Low | 3 |
| 3-Moderate/Limited | 3 | 3-Medium | 10 | Medium | 13 |
| 3-Moderate/Limited | 3 | 2-High | 15 | High | 18 |
| 3-Moderate/Limited | 3 | 1-Critical | 20 | High | 23 |
| 2-Significant/Large | 5 | 4-Low | 0 | Low | 5 |
| 2-Significant/Large | 5 | 3-Medium | 10 | Medium | 15 |
| 2-Significant/Large | 5 | 2-High | 15 | High | 20 |
| 2-Significant/Large | 5 | 1-Critical | 20 | Critical | 25 |
| 1-Extensive/Widespread | 9 | 4-Low | 0 | Low | 9 |
| 1-Extensive/Widespread | 9 | 3-Medium | 10 | High | 19 |
| 1-Extensive/Widespread | 9 | 2-High | 15 | Critical | 24 |
| 1-Extensive/Widespread | 9 | 1-Critical | 20 | Critical | 29 |
Balancing Impact & Urgency
Using independent weight values for both Impact and Urgency allows the support organization to fine-tune how much relative value is placed on the customer's interpretation vs. the support staff's interpretation the request's importance. For example, if the customer reports something as at a low urgency, but IT recognizes it as having a big impact, weighting the impact values accordingly will ensure the final priority recognizes IT's better ability to determine the scope/impact of the problem.Slowing Down Support Staff
This is something I thought of while working a couple of test tickets yesterday. Using the numeric spinner to increase & decrease priority actually slows down the support staff's ability to change the priority. It isn't trivial spinning that number 20 times (or whatever it is) in order to increase it to the next priority threshold. This has the effect of dampening the ticket's priority, keeping it from bouncing from one extreme to another (perhaps as SLA's are trying to keep up).Priority Granularity
Having a priority weight allows the support staff to choose the proper impact and urgency, and then make it "more" of the resulting priority. For example, if the resulting weight of a "High" priority ticket is say, 20, then the support staff can make it a "High" / 23, which would indicate to other staff members that it's more important than a standard "High", but doesn't justify an overall priority of "Urgent".In conclusion, I don't think it's that big of a deal, really. Once the support team becomes familiar with the default values for Impact & Urgency weights and understands that they drive the priority and priority weight. They should also understand that in order to change the priority you can either increase/decrease the priority weight (making adjustments independent of Impact/Urgency), or change the Impact/Urgency values. It's not hard to do.
Posted by caropepe at October 25, 2007 08:36 PM