Incident management

What is incident management?

The service desk team typically provides the first line of response for incidents since they provide a single point of contact for customer communications with IT. According to ITIL, the aim of incident management is to restore any disruption or failure of service to normal operations as quickly as possible. This includes monitoring for any condition that has the potential to result in a reduced quality of service. How an IT team responds to incidents is one of the top priorities for many IT organizations. ITIL provides best practice guidance for defining a proactive approach to incident management.

The service desk team typically provides first line of support (level 1) when responding to an incident. Activities performed by the service desk team include the following:

• Record the incident - date & time, description, name of person reporting it and unique identification number
• Incident identification, classification and prioritization
• Initial diagnosis
• Communication with the customers and service owner throughout the life of the incident
• Escalation to level 2 support (as needed)
• Resolution and verification
• Incident closure
• Participate in a Post Incident Review (PIR) for all major incidents.

Since the goal of incident management is to restore a service as quickly as possible, the service desk is not expected to perform root cause analysis to identify why an incident occurred. Root cause analysis is the focus of a problem investigation, and is covered in Problem management. However, it's important that the service desk team capture all relevant information while working on the issue, because this may be important when responding to future incidents.

Incident management process

It's important that the service desk team use all available resources to effectively respond to an incident. This includes following a predefined process to streamline the response and reduce the risk of prolonged service outages. The following process represents an example incident response based on ITIL recommendations. It provides a streamlined starting point that you can use for adapting existing ITIL processes or defining new ones.

Variations in this process may depend on your IT organizations' process and work instructions. Common incident response process considerations include:

• What Service Level Agreements (SLAs) are required that define incident priorities, escalation paths, and resolution time frames?
• What incident procedures are needed to provide standardized responses to ensure incidents are resolved efficiently?
• What types of incident categorizations are required for better data gathering and problem management?
• What is needed for incident statuses, categories, and priorities to properly classify, track and report on incidents?
• What is the process and procedure for major incident response?
• What are the proper incident management role responsibilities and assignments needed to ensure an effective process?

Setup for incident management in JIRA Service Desk

Configure the workflow and fields with the Incident Management workflow add-on

We built the following workflow add-on based on the ITIL framework for incident management: https://marketplace.atlassian.com/plugins/com.atlassian.servicedesk.incident/server/overview. 

You can use this workflow as a basis that you can then build out your own change management process on.

To use the workflow from the Marketplace:

1. Log in as a user that has the JIRA administrator global permission, and follow the instructions listed here to import a workflow.
2. To have the fields created by the workflow import displayed on your incidents, activate the screen by following the instructions here: https://confluence.atlassian.com/adminjiracloud/defining-a-screen-776636475.html#Definingascreen-Activatingascreen.  

What does the workflow look like?

When you import it, the workflow will create a few screens and custom fields as shown below:

 Incident management fields

We recommend the use of the following fields to support your incident management process:

• Description: Use this field to capture the symptoms and the basic information about the incident. 
• Status: Indicates the current state of the incident. 
• Pending Reason: Specifies the reason for why incidents are moved into pending and what the incident is pending on. 
  • Example values: Waiting on vendor, More info required, Awaiting approval, Pending on change request, Pending on problem investigation. 
• Priority: This is determined by the urgency and impact of the incident. Your team can define the value matching according to your own processes. 
  • Example values: Critical, High, Medium, Low
• Urgency: A measure how quickly a resolution of the Incident is required
  • Example values: Critical, High, Medium, Low
• Impact: A measure of the extent of the Incident and of the potential damage caused by the Incident before it can be resolved.

  • Example values: Extensive / Widespread, Significant / Large, Moderate / Limited, Minor / Localized

• Operational categorization: Classifies an incident for the purpose of assignment and reporting from the operational perspective. 
  •  Example values: Configuration > Printer
• Product categorization: Classifies an incident for the purpose of assignment and reporting from the product perspective. 
  •  Example: Hardware > Printer
• Source: Indicates where the incident comes. 
  • Example values: Phone, Email, Monitoring event 
• Component: Indicates the service impacted by Incident
• Resolution: Classifies the resolution of the incident.