Defining Metrics for Incident Management

I have written about how to define metrics and KPIs for IT service management processes before. In Defining Metrics for Change Management I discussed the importance of identifying stakeholders, and defining CSFs and then using these to help you think about what KPIs you should measure and report. In Defining Metrics for Problem Management I continued this theme, and showed how the KPIs that you find in best practice publications like ITIL may not be suitable for your needs.

In response to these earlier blogs, I received some requests for more blogs in the series, and in particular a request for guidance on metrics for incident management. So here are my thoughts on how you can define metrics for incident management…

The first question to ask is what is incident management for? What are you trying to achieve? This won’t be the same for everyone, but most organizations will want something like:

• We resolve incidents quickly, so they don’t have a significant impact on our customers
• We prioritize incidents appropriately, based on their impact and urgency
• We communicate well so that customers and users understand what is happening and when they can expect their incidents to be resolved
• Customers and users are satisfied with the way we handle their incidents
• We recognize repeating incidents and log problems to help reduce future business impact
• We make efficient use of our incident management resources

Ideally our KPIs should help us to understand whether we are achieving these goals, and should provide trends to help us focus on where we need to improve. So let’s think about what we could measure to help with these. Please remember that these are all just examples, based on how I think about incident management.

Some KPIs will be appropriate for one organization and completely inappropriate for another. For example some organizations measure the First Call Resolution (FCR) rate. This is a measure of what percentage of calls were resolved during the initial phone call with the service desk. For many organizations this is a great way of measuring that they resolved incidents quickly and made efficient use of resources, but if you are investing in self-service tools then you may find that FCR gets worse, even though the service is improving.

Here are some examples of KPIs that might help you to understand how well you are doing against the goals listed above. In each case I have indicated the metric, but not provided a target, as this will be completely dependent on your environment. You may need to collect data for a while before you can set targets for any of these metrics.

• We resolve incidents quickly, so they don’t have a significant impact on our customers.
  • Percentage of Priority 1 incidents resolved within SLA agreed target
  • Percentage of Priority 2 incidents resolved within SLA agreed target
  • Percentage of Priority 3 incidents resolved within SLA agreed target
• We prioritize incidents appropriately, based on their impact and urgency
  • Number of incidents where the priority was changed after logging
  • Number of customer complaints or escalations due to disagreement over incident priority
• We communicate well so that customers and users understand what is happening and when they can expect their incidents to be resolved.
  • Percentage of incidents where customer contacted the service desk to ask for an update
• Customers and users are satisfied with the way we handle their incidents.
  • Percentage of users giving a score of 4 or 5 on post-incident satisfaction survey
  • Increased satisfaction with incident management on annual customer satisfaction survey
• We recognize repeating incidents and log problems to help reduce future business impact.
  • Number of problems logged by the service desk
  • Number of problems identified by analysis of incident data
• We make efficient use of our incident management resources.
  • Percentage of incidents logged via self-service
  • Percentage of incidents solved by self-service
  • Average cost to resolve incident (by priority)

Remember these are all just examples. It really doesn’t take long to write down your own goals, and then to think about what you could measure to help you achieve them.

What are your current incident management KPIs based on? Do they help you understand how well you are doing for your customers, or are many of them just internally focussed? Why not sit down and review them and see if you can start measuring and reporting the things that really matter to you?

Learn about SysAid Incident Management
 

About Stuart Rance

Stuart is an ITSM and security consultant, working with clients all round the world. He is one of the authors of ITIL 4, as well as an author of ITIL Practitioner, ITIL Service Transition, and Resilia: Cyber Resilience Best Practice. He is also a trainer, teaching standard and custom courses in ITSM and information security management, and an examiner helping to create ITIL and other exams. Now that his children have all left home, he has plenty of time on his hands for contributing to our blog - lucky us!