Severity Code:    A simple code assigned to Problems and Known Errors, indicating the seriousness of their effect on the quality of IT service. It is a common name given to the means of recording priority for resolution.

See also: Impact, Priority, Technical Severity, Urgency

© Crown Copyright with Value Added Product Status.


Priority and Severity are discrete, yet related concepts. Priority gives order to the work queue performed by a finite resource pool, while Severity is an assessment of the degree of impact to the end-user. Both are from a variable set of qualitative perspectives and as a result, using severity as a reporting parameter can be problematic. ITIL uses severity to assist in the prioritization process, however, failure context may change the resulting severity code.

Consider a telecommunications scenario. An end-user calls to report: "no dial tone" at their home. The services desk responds: "is that on one phone or all phones." In that brief moment, severity is being assigned, does this person have the ability to make a telephone call, or not, if not, then severity is arbitrarily assigned to be higher. In addition, the method of troubleshooting the problem is determined because if it is only one phone without dial tone, the dial tone must be available at the building and thus, we may ignore all of the equipment and wire except for the wire and phones in the persons home.

Let's change the context of the telecommunications scenario from a home to a hospital. Three end-users call to report: "no dial tone" at a hospital. The service desk responds again: "is that one phone or all phones," meaning all phones in the immediate vicinity, not the entire hospital. The answer is "one phone." Lets say that on investigation, they all had the same problem - their cord was unplugged from the wall. Yet, the service desk overrides the severity code assigned to the problem or known error and set two of the troubles critical while allowing the third to set to the assigned, lesser severity. In addition, each had a different priority level, in part, driven by urgency. Why did this happen? They gave the highest priority and severity to a telephone in the cardiac care unit, because a button on the phone calls a crash cart. The second highest to a phone in maternity and third highest to a regular patient room. In reality, each case had the same technical severity, however they differed in the potential urgency. The example suggests that urgency, the time available before there is a risk to the business of saving lives, is highest in cardiac care. In ITIL theory, a single dead phone should result in a known problem with an assigned severity code and the prioritization should be a function of impact, technical severity and urgency. In practice, severity is a more "well-known" way to gain visibility and move up in the priority queue.

From a reporting standpoint and during service reviews, we believe it important to review incidents in terms of both their default and assigned severity, paying particular attention to incidents where the default is not equal to the assigned for a particular incident. If a review of the exceptions, i.e. default != assigned, shows a consistent pattern of change without reason, then the initial assignment may be incorrect. Reporting and review of the priority given to any particular incident is more difficult, however, because it is relative to the severity, impact, and urgency of all other incidents during a unit of time. Here, the question needs to be: was the priority given appropriate within the workload.

© Knowledge Transfer. All rights reserved.