Cutting Some Fat: A More Agile Incident Management Process

Making your incident management process more agile means stripping out every step that has no customer value or adds nothing to their experience. Doing so means you must critically analyze your current processes and evaluate every step. You do this by asking yourself and your incident management team if the steps do or do not add value for the customer. All in all, pretty simple and straightforward.

However, answering this question requires first knowing what your customer wants—an obvious place to start. Ultimately, though, your customers likely just want a quick, easy solution that meets their needs, whatever their needs are. Thus, every step in your incident management process must contribute to how quickly an incident is claimed, processed and moved through completion, or you must offer your customer a better solution.

Any steps along the way that do not contribute to your goal of serving your customer, you must try to remove. Honestly, this is a process that compares nicely to what you might find in Lean management where you eliminate all waste from all you do for the benefit of the organization and its peoples. Lean is different in that your goal is to make each process most efficient, while agile is about bringing as much value as possible to the customer and their experience.

Here’s a regular incident management process that you’re likely familiar with:

Let’s map the process: 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 the incident can be processed. If the answer is yes, it is moved forward; 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. At this point, the incident is closed and the customer is informed. No further action is required. All-in-all, this process is pretty straightforward from a traditional sense, but it can be made even easier.

Instead of the service desk managing the process through closure, why not end it where it actually ends. For example, traditionally, the service desk is tasked with closing each incident even if the solution to the incident has been solved or discovered by another department. Using this example, a back-office specialist solves the incident, describes what’s been done, but members of the service desk must translate this technical information from the back office (or other department as appropriate) into something understandable that can be conveyed to the use before the incident is closed and the user informed.

Now for the cutting of the fat. What if we remove the final portion of this process to where the process actually ends? Thus, cutting back on the duplicate work of the service desk employee and placing this responsibility in the hands of the person or department that actually wraps up the incident? Doing so would reduce redundancies and might eliminate any potential “lost in translation” that can occur from one department to another as seen in the childhood game of telephone.

Moving the “closure” process to the back office specialist (using our example above) where the incident was first solved (or wherever the incident was initially solved) eliminates a great deal of redundancy and frees up the service desk team for other more pressing needs.

This might be difficult for some service desk teams, but it’s a concept that’s easy to grasp. Ultimately, it’s more efficient if the back office can describe, transcribe and close their own incidents as opposed to having the service desk figure out what to write to the customer based on the outcomes of another department.

Plus, the incident requires less forwarding, making for a shorter duration of the issue, and a happier user whose incident has been addressed in the quickest manner possible.