An Overview of the Incident Management Practice in ITIL 4

Incident Management, overseen by those working on a Service Desk, is the practice that allows us to quickly respond to and get our customers “up and running” again when things fail. Because it’s a practice that is highly visible to our customers, it’s important that we get it right. This article will cover the Incident Management practice guide, highlighting key concepts to ensure this practice is performed successfully, as well as some of the key differences in the practice between ITIL v3 and ITIL 4.

The Purpose of the Incident Management Practice in ITIL 4

Let’s talk about what Incident Management is and what it includes:

The Incident Management practice is about making sure that when things fail, we have a solid way of getting our customers back to “normal” quickly. It’s worth noting here that “normal” does not mean diagnosing and implementing the final, permanent solution, but rather getting our customers to a state where they can continue their work. Incident Management is about managing and treating symptoms, not necessarily understanding root cause. More on Problem Management and the differences between how we manage incidents and problems here. When it comes to managing incidents, we should work to respond to and resolve them in agreement with what our SLAs say (more on that in our article, “An Overview of the Service Level Management Practice in ITIL 4”) and ensure our customers can carry on with their work. How we manage incidents plays a large part in the overall customer or user experience and, when done well, can increase our credibility and perception to those we serve.

Definitions in the Incident Management Practice in ITIL 4

This brings us to the definition of what an incident is:

Unlike a change, where an interruption is planned and scheduled, incidents take us by surprise. Incidents, however, may or may not be noticeable by a customer; and if we can resolve them without our customers even knowing an incident has happened – even better. I’ll give you a quick example on the importance of communicating incidents, regardless of whether customers see them or not. One of the technicians at a customer site was walking by a server closet in the hospital. He heard a loud beeping sound and went to investigate. It turned out that a battery back-up unit (UPS) on a server was giving an alert that it was going to fail (unfortunately, it was not being managed by an event monitoring tool). The tech had every intention of calling the network team to report the alert and get it fixed. At the same time, his girlfriend called, they got into an argument, he got distracted, forgot to call the network team, and the UPS went down. Luckily, the server didn’t go down as it was supporting a live patient system. The networking team didn’t have a spare UPS in stock; and the vendor said it would take a couple of weeks to get a new one even with a rush order. They ended up borrowing a UPS unit from a less important system to support the patient system until a new unit could be put in place. Fortunately, everything ended well in this story. The point here is that “life happens,” and it’s key to communicate failures (even if it’s just a backup as it could be supporting something critical), and incidents should be sent to the Service Desk as our single point of contact – if for no other reason than to ensure that somebody is paying attention to them – and to avoid last-minute crises.

Also, the earlier that we can detect and resolve incidents, the better. Having good practices around Monitoring and Event Management (to raise alarms as soon as something fails rather than waiting until a technician walks by a server closet or a customer calls the Service Desk, implementing self-healing systems, etc.) and using automation in how we handle incidents (with automatic categorization, routing, resolution, customer notifications, machine learning solutions, etc.) can help. Having a solid knowledge-base can also help teams resolve incidents quickly (more on knowledge sharing and Knowledge-Centered Service or KCS here).

The Use of Incident Models in ITIL 4

Having pre-defined ways of handling common types of incidents – or what’s called an “incident model” – can also help:

By creating incident models, we don’t waste precious time “reinventing the wheel” with common incidents we’ve seen before and can thereby speed up how we handle them.

Major Incidents in ITIL 4

In catastrophic situations (fires, floods, tornados, and, unfortunately, we can add pandemics to this list) or, alternatively, in situations where there’s a lot of complexity and it’s not immediately clear what has failed, it’s helpful to have separate procedures. These situations, depending on their nature, may cause us to invoke our continuity or disaster recovery procedures; and those teams or individuals that are handling these types of incidents would often categorize them as “major incidents”, as defined here:

Major incidents need to be resolved quickly as they can have far-reaching, negative consequences on our customers and the overall organization. The Incident Management practice guide has some helpful details that should be discussed and defined within an organization when it comes to “major incidents”, namely, that our models for handling major incidents should include:

• Clear criteria to distinguish major incidents from disasters and other incidents
• A special, accountable coordinator, sometimes referred to as the major incident manager (MIM)
• A dedicated, temporary team created to investigate and resolve a major incident
• Other dedicated resources (including budget); for example, for urgent consultations with third-party experts or procurement of components
• Special methods of investigation (for example, swarming – defined below)
• An agreed-upon model of communications with users, customers, regulators, media, etc.
• An agreed-upon procedure for review and follow-up activities

Handling Security-Related Incidents

There are other special types of incidents that need to be defined and managed within this practice, namely, that of security-related incidents. The Service Desk needs to be aware of when to identify and how to handle these types of incidents as they will require separate procedures and are managed by the security team or other relevant groups to ensure they are addressed quickly and effectively. InfoSec is such an integral part of everything an organization does, and it’s a substantial piece of Incident Management as well.

Intelligent Swarming

Swarming is a term that is new to Incident Management (introduced as part of the ITIL 4 framework), though Agile teams have been doing this for some time. It can be defined as:

Just as a swarm of bees or ants would quickly gather together, and in concert, to contribute to the larger group so that the entire hive/colony succeeds, analysts would gather to provide their collective expertise to an incident. This approach can be especially helpful when dealing with complex incidents or those where a particular group is having a hard time resolving it – and this can include how we handle major incidents. The Consortium for Service Innovation™ has a term called Intelligent Swarming℠ that’s pretty interesting. The diagram below shows the difference between more traditional ways of escalating incidents – also called “streaming” and that of swarming.

Workarounds for Incidents in ITIL 4

In some cases, we may not be able to identify or implement the final solution, and that’s where workarounds can help. They are defined as follows:

One thing to keep in mind when applying workarounds is that they can increase technical debt (see the definition below) within an organization and, where possible, the cause of the incident should be identified and resolved.

How Incident Management in ITIL 4 Differs from ITIL v3

The purpose and definitions in the ITIL 4 Incident Management practice are pretty much the same as they were in ITIL v3. The main difference is that the practice guide expands on existing concepts in the following areas:

• Major incidents
• Workarounds and understanding how they can add to our “technical debt”
• How Incident Management and other ITIL practices interfaces with each other, such as: Monitoring and Event Management, Problem Management, Service Desk, Service Request Management, Change Enablement, Service Continuity Management, Deployment Management, Infrastructure and Platform Management, Project Management, Release Management, and Software Development and Management, as well as Continual Improvement.
• Information on getting good data from customers. The practice guide discusses the “3 Cs” when it comes to collecting data, making sure that it’s: Concurrent (understanding what happened when and getting a solid timeline of events), Complete (going beyond simple statements to uncover useful, additional detail), and Comprehensive (understanding not only the “what”, but the “why” as well to ensure understanding). Having good data can also help teams perform better Problem Management activities if needed. There are also several pages in the practice guide that detail the types of information to be collected (see Section 5 on Information and Technology).

The Incident Management workflow that was included as part of ITIL v3 has been replaced by two sample workflows for: 1) handling incidents (detection, registration, classification, diagnosis, resolution, and closure), which can be done manually or automatically, and 2) periodic review of incidents. The practice has also been simplified to include the bare necessities when it comes to managing incidents. For example, all incidents should be:

• Registered or logged, so that you have a record and can easily track incidents.
• Classified (which contributes to incident priority) or categorized (which provides context and responsibility for resolution) in some fashion to help with reporting, linking to other objects like assets, and/or routing to the correct team as needed.
• Prioritized (based on impact, urgency, time constraints, etc.), so your team understands what to work on first. Further, incidents should be managed as part of a single backlog along with other work that needs to get done (requests, other projects, enhancements, etc.).

The Incident Management practice guide mentions SLAs and how we should work to resolve incidents in alignment with what we’ve committed to with our customers.

Agile, Lean, and Team Dynamics Covered in ITIL 4’s Incident Management Practice

Agile and Lean Concepts

Agile and Lean-related tools and techniques can also be helpful to teams that are managing incidents, for example, with: 1) the use of Kanban boards to make overall work and prioritization visible, and 2) limiting the amount of Work in Progress (WIP) to ensure we’re not trying to tackle too many things at once, which can decrease our overall flow and the speed at which we can get things done. Last, we should continually look for ways to get better at managing incidents – whether that be after handling “major incidents”, as new types of incidents arise, or at times when we don’t meet our SLAs.

Team Dynamics

The Incident Management practice guide also talks a bit about team dynamics to support overall success of the practice. This includes creating an environment where our teams exhibit:

• Collective responsibility – It’s not a single person’s job to make sure incidents are resolved efficiently and effectively. We’re all in this together, and we succeed or fail together as a team.
• No-blame culture – When things go wrong and, say, for example, we miss an SLA, blaming an individual or team doesn’t solve anything. The better approach is to attack the issue at hand and figure out how to get better the next time.
• Continual learning – Part of getting better as a team and organization is sharing information and collaborating with one another, experimenting with new ways of working, and failing (and, most importantly, learning) quickly.

Practice Success Factors for the ITIL 4 Incident Management Practice

All of the ITIL practices now include Practice Success Factor or PSFs (which were referred to as Critical Success Factors or CSFs in ITIL v3). The PSFs for Incident Management include:

• Detecting incidents early
• Resolving incidents quickly and efficiently
• Continually improving incident management approaches

The practice guide also provides several specific metrics we can use to make sure we’re meeting our PSFs. These PSFs are, essentially, the three most important questions to ask yourself and your teams when looking at the overall practice: 1) Do we detect incidents early on and have good tools to help us with that? 2) Do we do a good job of resolving incidents quickly, and are our customers satisfied with our quality of work? and, 3) Are we looking for ways to improve and are we getting better over time? If you’re doing these three things, you’re on the right path when it comes to Incident Management.

Where to learn more about Incident Management

The Consortium for Service Innovation has some great resources on Intelligent Swarming. AXELOS’s Incident Management practice guide has additional details and is available for free as part of a MyITIL subscription for those that have taken and passed a 2-day ITIL 4 Foundation course and exam. You can also find practice guides for the Service Desk, Service Request Management, Problem Management, and Event Management as part of MyITIL too. If you don’t currently hold the ITIL 4 Foundation certificate, a 1-year subscription to MyITIL costs $50.

If you hold the ITIL 4 Foundation credential, you have the necessary pre-requisites to take any of the advanced ITIL 4 courses that discuss concepts from this article, namely:

• 3-day ITIL 4 Create Deliver and Support (CDS) course, which include details on Incident Management, Monitoring and Event Management, Problem Management, and the Service desk. This is a great course for anyone involved in Incident Management-related activities.
• 3-day ITIL 4 Drive Stakeholder Value (DSV) course, which includes details on the Service Desk and Service Request Management.
• 3-day ITIL 4 High Velocity IT (HVIT) course, which includes details on the Service Desk and Problem Management.

*Note: You must have completed a 2-day ITIL 4 Foundation course and exam as a pre-requisite to be able to attend one of these advanced ITIL 4 courses.

Intelligent Swarming℠ is a service mark of the Consortium for Service Innovation™.