• Skip to main content
  • Skip to primary sidebar

This view of service management...

On the origin and the descent of managing services. We put meat on the bones.

  • Kanban Software
  • Services
    • Kanban Software Solutions
    • Consulting & Coaching
    • Training and Seminars
  • Posts
  • Events
    • Events – Agenda View
    • Events – Calendar View
  • Publications
    • Our Publications
    • Notable Publications
    • Quotes
  • About us

What is meant by severity?

8 November 2012 by Robert Falkowitz 3 Comments

Standard Terminology
Most service management practitioners will agree that there is an advantage to using a shared and a standard terminology when speaking of how to manage services. To this end, the definitions provided by ITIL® are most often cited. Some terms, however, continue to be used in diverse ways, only adding to the confusion of those who attempt to follow industry standards. This might be due to multiple industry standards, to poetic license, to ignorance or, indeed, to laziness.

The Case of Severity
One such term is severity. Severity is normally used to describe an event or an incident.
However, some practitioners appear to use this term interchangeably with other attributes of events and incidents, such as impact or priority. I propose here a simple way of distinguishing severity from impact, one that is loosely derived from ITIL®.

Events or incidents may be viewed from two perspectives: how do they influence the customers of services and how do they influence the providers of services. We propose that the term impact should describe the influence of an event or incident on the customers, while the term severity should describe its influence on the service provider.

About Impact
Since an incident or event normally has a negative influence on service customers, impact is a measure of the loss of value to the customers. Services are intended to provide value to customers; incidents diminish that value. Impact tells us by how much. Ultimately, impact should be measurable in financial terms, but this is often difficult to do or impractical during the resolution of an incident or event. Therefore, it tends to be reduced to a rather arbitrary scale, such as high, middle or low. There are numerous indicators of the probable level of impact, including the number of users touched by the incident, the profiles of those users, the role that affected components play in the delivery of services and the value of those services.

Whatever means are used to measure the probable or actual impact of an incident or event, the resulting assessment should be recognizable and verifiable by the customers. There is an importance nuance here, however. Only the customer can really assess the actual impact of an incident. However, both the service provide and the customer may together assess the probable or potential impact of an incident. The service provider must make such assessments early in the management of events and incidents, even if the customer provides no input at all.

About Severity
Severity measures the effort and expense required by the service provider to manage and resolve an event or incident.  A number of examples illustrate this definition. A failed disk that may be replaced using a hot swap is an incident less severe than one requiring the shutdown and opening of a computer chassis. The failure of a device costing 100,000 to replace is more severe than the failure of a device costing 10,000. The incident whose resolution requires five technicians and ten hours of work is more severe than the incident requiring 1 technician and ten minutes.

As for impact, severity should ultimately be measurable in financial terms. Similarly, such measurements are much easier to make after the fact than during investigation and resolution. The major difference between impact and severity is that impact depends on how customers are using a service. The profiles of use are only indirectly influenced by the service provider. The same service provided to two different customers making different use of the service may end in radically different impacts in the case of failure. A lost email message intending to place an order to buy or sell stocks will have a very different impact than a lost email thanking a customer for years of loyal patronage.

In fact, severity is often due to a series of strategic and tactical choices made by the service provider. Severity is therefore directly influenced and under the control of that organization. If incidents are more severe because an organization has not enforced any standards for the models and configurations of its servers, then that severity is the direct result of a decision (or a decision not taken). A service provider may choose not to invest in the ongoing development and education of its technicians. In that case, it should not be surprised if the staff takes longer to diagnose and resolve incidents, thereby making them more severe than they might be otherwise.

Weakly Related
Even though impact and severity measure similar aspects of a single event or incident, there is no necessary relationship between the degree of impact and the degree of severity of a single incident. Simple to resolve incidents might cause great impacts, just as incidents of minor impact might be very difficult to resolve. Imagine, for example, the case of an Internet bank cut off from the Internet because someone unplugged a cable – huge impact, trivial resolution. It might happen that the severity of an incident is greater than it need be. This may be because the service provider has a fragile, complicated  and poorly understood infrastructure. In such cases, that incident is likely to have a greater impact than it need have, due to the length of time required to resolve it.

This latter example brings us to the use of the severity metric in managing IT. Severity measurements of events and incidents help to gauge, in common terms, the pain caused by the inadequacies of its resources and capabilities. Such pain points are obvious places for initiating improvements, especially if they represent quick wins. A Pareto analysis of the distribution of severity might be one factor in deciding how to prioritize all improvement initiatives. I emphasize one, because there should be some balance among operational, tactical and strategic improvements, whether there is pain or not.

In theory, severity could be a metric used for comparisons with industry benchmarks. In practice, it is extremely difficult to compare practices from one organization to another in a meaningful way. Any desire to benchmark severity ought to be handled with great prudence.

To close this discussion, it is important to mention that impact, and not severity, ought to be used to prioritize the handling of events and incidents. If a service provider puts the low severity incidents – meaning the ones that are easier to resolve – at the top of the queue, it is probably not well aligned with its customers’ priorities.

Concepts, not Terms
I do not expect universal adoption of this understanding of severity, given that other meanings are sometimes well entrenched in a company’s culture. The importance of the discussion, then, is not so much in the terms themselves as in the underlying concepts, each of which is distinct and is a useful metric for the management of services.

Summary
Article Name
What is meant by severity?
Description
Some practitioners appear to use the term severity interchangeably with other attributes of events and incidents, such as impact or priority. I propose here a simple way of distinguishing severity from impact, one that is loosely derived from ITIL®
Author
Robert S. Falkowitz
Publisher Name
Concentric Circle Consulting
Publisher Logo
Concentric Circle Consulting

Filed Under: Incident Management, Problem Management Tagged With: benchmark, impact, ITIL, ITSM, severity

Subscribe to our mailing list

Click here to be the first to learn of our events and publications
  • Email
  • Facebook
  • LinkedIn
  • Phone
  • Twitter
  • xing
  • YouTube

Reader Interactions

Comments

  1. MichaelMichael says

    20 November 2012 at 17:37

    Robert,
    it’s an interesting discussion, I just wonder if it might lead to more confusion? To me, severity is a measurement, not a separate concept. The usage would be “how severe is the impact of this incident?” High, medium, low? 1,2,3? Critical, major, minor?

    In other words, severity is used more in its sense as an adjective describing impact, rather than a noun, a concept in its own right.

    Michael

    Reply
  2. Robert FalkowitzRobert Falkowitz says

    20 November 2012 at 18:30

    Michael,
    Thanks for your feedback.
    This issue that I see is that ITIL defines severity in one way, whereas some people, including yourself, use it in other ways. Given the very fragmentary ITIL discussion and the varied usage, the confusion already exists. My contribution is an attempt to help people understand that a) there is a concept needing management, that I (and ITIL) call “severity”; and b) even if we choose to use words differently, at least we have a chance understand each other.

    Reply
  3. Matthias FleschützMatthias Fleschütz says

    27 February 2022 at 13:18

    Hi
    Great thinking and differentiation. Unfortunately to many mix this up and tools implement this contradictively.

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Kanban eLearning

Kanban training online

Recent Posts

  • Verbs, nouns and kanban board structure
  • The role of the problem manager
  • The Three Indicators

Tag Cloud

kanban board urgency kanban rigidity knowledge work automation Cost of Delay Incident Management adaptive case management knowledge management manifesto for software development tools statistical control chart service request leadership service manager change control problem manifesto incident lean ITSM lean management lead time value agile incident management tools risk cause flow efficiency process ITIL change management resource liquidity bias impact process definition flow waste value stream
  • Kanban Software
  • Services
  • Posts
  • Events
  • Publications
  • Subscribe
  • Rights & Duties
  • Personal Data

© 2014–2023 Concentric Circle Consulting · All Rights Reserved.
Concentric Circle Consulting Address
Log in

Manage Cookie Consent
We use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage vendors Read more about these purposes
View preferences
{title} {title} {title}