By on January 11, 2018

In my previous blog posts, you can read all about the essence of agile service management. Let’s now look specifically at the most important process of a supporting department. How do you make your incident management process more agile?

Remove all steps with no customer value

Are you thinking of making your incident process more agile? Your first step is to take a critical look at the current process and evaluate each step by thinking: does this step add value for the customer?

To answer this question, you first need to know what your customer wants. Your customer probably wants a quick and good solution. Every step in your incident management process needs to contribute to how quickly an incident is processed. Or to offering your customer a better solution. Is there a step that doesn’t contribute to your goal? See if you can remove it.

You can compare it to the lean approach. Here, you eliminate everything wasteful from your process. The difference is, with lean your goal is to make the process more efficient, and with agile you want to add as much value as possible for the customer.

Follow these best practices to make the most of ITIL incident management

A traditional incident management process

Let’s have a look at a regular incident management process. You’ll know this diagram, or a version of it:

A customer logs an incident. A service desk employee adds information such as classification and scheduling to this incident. Then, he or she checks to see if he or she can process the incident. If the answer is yes, he or she processes it. If the answer is no, the incident is forwarded to a specialist. The specialist makes the same assessment. When the incident is solved, it is returned to the service desk. There, the incident is closed and the customer is informed.

Looks quite straightforward, right? Well, it can be even easier.

Why does your service desk need to process every incident?

In many organizations the service desk closes each incident, even if the back office solved the problem. The back-office specialist describes what he’s done, the service desk translates his technical story to something understandable, closes the incident and informs the customer. Why? Because people assume that technical specialists aren’t strong communicators and they can’t describe their solution in a customer-friendly way.

This bothers me. If a technical person can’t describe his solution, how does the service desk know what he did? A service desk employee needs to go through all the information to piece together an understandable explanation. A waste of time, in my opinion.

Why shouldn’t the back office be able to write understandable solutions for their customers? I understand that it might be difficult for some, but it’s easy to learn. Have a training session and coach each other. It’s a lot more efficient if the back office can describe and close their own incidents, as opposed to having the service desk figure out what to write to the customer. Plus, the incident needs less forwarding, which makes for a shorter duration.

Swarming is a collaboration-based approach to solving incidents

Does your service desk really need to fill out all fields?

For each incoming incident, you need to fill out a lot of data. But is this really necessary? You only need to know a few things to process an incident. The caller, the question and a deadline for the incident. The rest of the data is only used for reports.

Go through all filled-out data with the service desk and management to determine if you really need it for reports:

Are there reports for this data?

I’ve visited dozens of organizations where the service desk filled out all kinds of fields, but they never end up in a report. How does this happen? During the implementation, some people might have thought: ‘Let’s fill out these fields, then we can report on them later’. However, the reports were never made.

What happens with the reports?

Imagine that there are reports on all the data you filled out, and that these reports are read. Then the question arises: do we actually do something with this data? Does management make improvements based on these reports? Do these improvements help contribute to your overall goal: find a suitable solution for your customer as fast as possible? If so, are these improvements important enough to fill out all this data for each incident?

Don’t get me wrong. I’m not saying reports are useless. On the contrary, reports can give valuable information about your service management process. But you need to stay critical. Is some data not relevant? Don’t fill out the fields, or have them filled automatically. This saves the service desk a lot of registration time.

Can I make my incident management process even more agile?

There are of course more ways to make the process more agile. Do you know how? Or are you experimenting with your own service department? Let me know in the comments. I am curious to hear your ideas.

And check out our e-book on Agile Service Management.