<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=42246&amp;fmt=gif">
ITIL incident management best practices

ITSM Processes

5 ITIL incident management best practices

By Stephen Mann on March, 12 2020

Stay up to date

Stephen Mann

Principal and Content Director at ITSM.tools

In his previous blog, industry expert Stephen Mann shared ten practical problem management tips. Today, he’s going to talk about ITIL incident management: an important foundation of any IT organization. In this blog, Stephen shares five ITIL incident management best practices that’ll help you improve your IT service desk.


With all of the ITSM blogs on hot topics such as Artificial Intelligence, digital transformation, and Enterprise Service Management, it can be easy to overlook the importance of ITSM staples such as ITIL incident management. But you shouldn’t let incident management fall between the cracks – especially since employee experience very much depends on the quality of your IT service desk and their ability to quickly get employees productive again.

So, how could your IT organization improve its ITIL incident management capabilities? In this blog, I’m going to share five ITIL incident management best practices to help you improve your IT service desk.

Just getting started with incident management? Get these fundamentals right first >>

1. Understand how your IT service desk creates business value

If the answer to the question “How does your IT service desk help the organization?” is “They fix IT issues”, you still have a lot of work to do in this department. It has been a long time since the IT service desk was merely “IT support”: they’re actually “people support”, as they help both your customers and your employees do what they need to do.

Nowadays, the focus of business stakeholders lies more and more on the value that your IT organization creates, and not simply on its costs. Your IT service desk is no exception here. So, how does your IT service desk create value – or prevent value leakage – for your organization?

Sadly, there’s no one-size-fits-all answer here. Instead, the value of your IT service desk is something that you need to discover by having proactive discussions with your key business stakeholders. In manufacturing, your IT service desk might add value by fixing IT issues that help minimize production line losses, or by performing preventative maintenance.

It’s also likely that different stakeholders will have different views on how your IT service desk creates value for their operations, teams, and customers. Some business stakeholders, such as a sales vice-president, might value minimal employee productivity losses above all else. In this case, quickly resolving IT issues that cause lost sales is critical.

You can only determine the various definitions of value by having quality conversations with your stakeholders about where your IT service desk helps, where it causes pain, and what you can improve. It’s important to appreciate that this needs to be multidimensional – you should recognize the overall impact of your IT organization, and that your stakeholders’ perceptions of value will likely change over time.

Once you’ve established the value of your IT service desk, it should flow through to your IT service desk strategies, objectives, policies, processes, service levels and metrics or KPIs.

2. Reassess your IT service desk’s service level targets

I’m not necessarily talking about metrics, but rather about some of the key service level targets your IT service desk is currently working towards.

Think about the following questions:

  • When did you set the targets? (Perhaps it was when the IT service desk was first set up, way back when?)
  • Did your key stakeholders agree on and influence the targets?
  • When did you last refresh the targets in light of changes in business demands, technology, and employee expectations?

You need to understand how well your targets are meeting the needs of your business. For example, how does dealing with incidents communicated via email within 24 hours help the business? And, thinking about this through a value lens: does the delay in resolving an issue cost your organization more than if additional IT resources had been used to ensure a quicker resolution?

The only way to tell is to ask the people you’re delivering your services to: your employees and potentially your external customers as well. Of course, any changes in your targets can only be delivered within the constraints of your IT service desk’s available resources.

3. Reconsider your current ITIL incident management metrics in the context of value

Logically speaking, this should have come before the second best practice. But if you want to align your IT performance with business expectations, it’s easier to start the required conversations with stakeholders with more of a “How are we doing?” lead-in. Whereas “This is what we measure; what do you think?” or “What should we be measuring to ensure that we meet your needs?” both seem a bit inappropriate as conversation starters.

So, what could be wrong with your current basket of ITIL incident management metrics and KPIs? IT service desks make many common metrics mistakes, including:

  • using too many metrics;
  • misunderstanding the relationships between metrics;
  • ignoring the behavioral aspects of metrics, and
  • seeing metrics as merely targets to be aimed for, not as a springboard for improvement.

Plus, there’s often a focus on what IT support does, rather than on what IT support achieves through what they do. It’s often very much about operations, and not about outcomes. And while the speed, numbers, and costs of operations are important, can you be 100% sure that your IT service desk is optimized from a business value perspective? Yet again, you need to talk to your key stakeholders about what really matters to your organization, and how successful your IT service desk is in meeting their expectations.

Learn how to improve your incident management KPIs in this guide >>

4. Don’t assume that a positive-looking change is automatically a good thing

This is a variant of one of the mistakes I talked about in the third best practice – that the relationship between metrics isn’t always understood. Take the number of incidents for instance. Of course, no one wants to have incidents, but they will inevitably happen. And when the number of incidents increases or decreases, it’s important to understand what such a change means.

Take for instance an IT service desk that wears the high number of incidents it handles each month as a badge of honor. Having a high number of incidents is not necessarily a good sign (or something to shout about) from an overall IT organization perspective.

And how about when the number of incidents drops over time? This isn’t necessarily a good thing for an IT service desk either. Especially if it’s a sign of the IT service desk’s worsening reputation: there might actually be more IT issues, but fewer incidents are coming in at the service desk. On the other hand, an increase in incidents can also be a sign of an IT service desk that’s performing well, so employees are more likely to contact IT with their issues.

So, when you look at changes in the number of incidents, you also have to understand what else has changed. Has customer satisfaction dropped? Or has the number of “simple” or low-priority incidents dropped?

Similarly, you need to understand changes in metrics such as costs per ticket or average handling times better before shouting about them. Your IT service desk may just be dealing with simpler incidents, such as password resets. And the average handling time when you don’t include simpler incidents such as password resets might have actually increased. Also ask yourself why your organization seems to need more password resets - and why isn’t this automated already?

Ultimately, your IT service desk needs to keep this in mind: don’t automatically assume that what looks like a positive change is actually a good thing. Always look at the relationship between different metrics and what that means in your organization.

5. Use problem management to reduce your number of incidents

This ITIL incident management best practice is going to be a short one. I already wrote a blog about why ITIL problem management adoption levels are so low – and another one with ten practical ITIL problem management tips.

Obviously, IT service desks need to understand the difference between incidents and problems. But your IT support also needs to make a proactive effort to use problem management tools and techniques to remove any time-consuming, effort-wasting reccurring issues for once and for all. This allows your IT service desk analysts to focus on the IT issues that really need their attention.

That’s it for now - five ITIL incident management best practices that’ll help you take your incident management process to the next level. Of course, I could have included other things - for instance related to people or the use of automation. But what best practice do you think I should definitely add to my list? Please let me know in the comments.


In Stephen’s next blog, he’ll talk about the ITIL Service Lifecycle and what happened to this essential part of ITIL v3 in ITIL 4. Subscribe to our blog to be sure you don’t miss it.

 

Illustration by Danique den Hartog.

Submit a Comment