::caropepe.com::

ITSM Incident Priority & Priority

10.25.2007 · Posted in BMC Remedy

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.

Comments are closed