One of the advantages of working with BMC FootPrints is the lack of definition “out of the box”.1 The tool provides easy configuration for fields, priorities and statuses, and workflows within multiple workspaces, but there are few defaults (besides sample workspaces that are not very usable). This lack of out of the box configurations has exposed me to an infinite variety of choices used by different organizations.
One organization used the term Severity. This has the advantage of abbreviating to “Sev”, so incidents can be described as Sev1, Sev2, etc. Nevertheless, most organizations stick with Priority.
I have seen these range all the way from 2 (Critical, Normal) to as many as 7 or 8.
The table above shows the more common configurations. In my experience the use of terms (High, Medium, Low) is more common than numbering (P1, P2, P3), but the latter is also used.
One of my clients had used numbering, P1 through P5, but they had overused P1 so badly they had to insert a new P0 to achieve the purpose of P1–fortunately they have since fixed the issue. (This reminds me of the project “prioritization” of a former employer. Everything on the list was “High Priority”. They effectively said everything was the same priority, and they were all low.)
I encourage the use of “Normal” instead of “Low”, because no user wants their issue perceived as “low priority”. I have also seen a customer take this advice but swap it out for Medium instead of Low. Most organizations track Service Requests with Incidents, so we usually want some mechanism for differentiating them, but note that new priorities are not required (see Urgency below).
I also find it common to create a separate priority level Project, for handling projects (or extended service requests) that are scheduled past normal Service Level targets. A Project choice is particularly useful when Service Level measurements are tied to Priority (my colleague, Evans Martin, has written about this already.)
I have also seen duplicated sets of Priority choices tied to different Service Levels depending on which team was assigned the work, or regional organizational differences. For example, an software issue assigned to a development group might have a separate set of service levels but remain assigned in the same Service Desk system for tracking purposes. In this case they might have choices like P1, P2, P3, P1-Dev, P2-Dev, and P3-Dev.
Impact describes the level of business impact. Usually this is described in terms of the number or percentage of users impacted. I had one customer who described the percentage of configuration items (CIs) at its facilities that were impacted (see column 5 below).
|High||10+ People||Organization||Entire Company||80-100%|
|Medium||2-9 People||Department||One/Multiple Sites||50-80%|
I have seen organizations describe the number of people affected (column 2), but most common are the choices ranging from Entire Organization to Individual. The choices in between need to reflect your own organization. One customer who ran fitness outlets needed to distinguish corporate sites from fitness centers.
The default configuration High/Medium/Low (column 1) is too ambiguous in most cases, but I have seen it used.
Many organizations separate VIPs from non-VIP individuals. VIPs will often map to Priority similar to Departments.
Urgency describes how quickly the incidents should be resolved. In the simplest case this can be High, Medium, and Low, but as with Impact this is usually too ambiguous to be useful.
|Low||4-8 Hours||Service Request|
|Over 3 Days|
I have also seen Urgency described in Resolution time frames. There are two issues with this: the time frame is easily confused with Service Levels (which they are not), and the time frames are also ambiguous especially in situations when no downtime is acceptable. I find Down, Affected, and Request to be useful.
The combination of column 4 in Impact and column 3 in Urgency results in sentences that read in English: the Company is Affected, or the Individual is Down. I like this because the intent is clear.
The mapping from Impact and Urgency to Priority can usually be described in a table like below. There are no right or wrong answers here, and it varies by organization and by choices for Impact and Urgency. In the table, Impact runs in the first column and Urgency runs in the first row.
In some cases multiple choices of Impact or Urgency will always map to the same priority. For example, VIP often maps like Department. Although I encourage simplicity, sometimes it makes sense to break them out in order to make the choices clear. (You could also stack choices, such as “Department / VIP”).
You will also need to decide whether to allow overriding these choices. If so, you will need to add a third field (called something like Override or Priority Override) to your mapping table.
- Start the discussion with minimal choices for Impact, Urgency, and Priority. Add choices only necessary.
- If the tool has default choices, start with those.
- You may have Service Level Agreements tied to your Priority that need to be factored in.
- Avoid duplicating terms across fields, such as using High/Medium/Low in both Urgency and Priority.
- You need to decide whether customers / users can choose the Priority. I don’t encourage it, because the user may not be qualified to understand the Impact. Moreover they will always choose critical. Nevertheless, many organizations do allow it.
- Decide if you want default choices for Impact and Urgency. Doing so may limit the usefulness of Priority (IT agents are lazy and often leave the defaults).
- As discussed before, you may need a policy for when and whether Priority can be changed.
1 Several customers preferred more options out the box. I can understand the desire for more the “standard configurations” provided by other vendors, but at the time it seemed strange and undesirable.