While sitting on a bus on the way to work, I saw a billboard that said something to the effect of, “We DO Sales.” I always love when people say that they ‘do’ something.
A few months back I was discussing IT Service Management with a colleague who is currently at another company. She mentioned some improvement initiatives they were working on and said, “… and well, you know, we already do Incident.” There it was!
She mentioned that there were some challenges with Incident, but it wasn’t on the radar for review or improvement since their leadership didn’t see many issues or concerns with it (of course not—after all, they were ‘doing’ incident already). While the incident process was pretty smooth, there was always room for improvement from her perspective. She also pointed out that the company had grown substantially recently and that the perception of the service provided may not have been what it once was.
I bumped into her again this past week, and she said that they were going to take a closer look at incident as part of the ITSM process review and improvement initiative they had underway. It turned out that when she went to the leadership group with her analysis of the current state of incident, they were surprised. The perception from the top brass was that service was always quick and receptive, but this could be because it is mentally ingrained for people to go the distance for the company VIPs. She said there were many areas that did not “make sense” anymore from an organizational standpoint, and that to improve the other processes, they were going to rework Incident Management on some levels as well.
This can be an uphill climb; while you might think that there are only a few tweaks, remember this process is the most recognizable to your customer base. Any changes might be like re-launching this process to your business or customers, so it should be tackled in such a manner.
Whether it is a modified process or brand new one, here are just a few of the challenges I have come across:
Buy in and commitment
You need to have a solid plan before you communicate on what you are doing. You need a method to track the incidents, as well as a clear understanding of the incident process. Distinguishing which incidents are critical and which are not is critical. “How do you know which incidents are critical?” you might ask yourself. This is where there needs to be an agreement on which services are considered critical to your business and which of those supersede the others (priority matrix). This will help you to determine the priority of issues you deal with. Depending on what tool or process maturity you have, you may be able to automate this in some capacity rather than the service desk going from the gut upon creation.
The ability to detect incidents as early as possible
There are a few ways we can work to improve this situation. From a process perspective, we need to take a look at the Event and Problem management processes if they exist. Is there something here that we are able to leverage? Does the operations team monitor any environments and are there ways we can reduce double work to improve service? Getting these activities lined up can reduce the outage time and in many cases reduce the actual impact to our business.
Convincing all staff to log Incidents
This is where we need to improve our relationships with our business. From their perspective they just want something sorted out. They don’t want (and frankly don’t need) to jump through hoops to get things working again. There are two components for this.
Visibility: If the experience with the service desk is such that the business doesn’t escalate the issues thinking we already know, we may not truly identify the scope of the issue and prioritize it correctly.
Contact: Take a long look at the way that the business can communicate with IT currently. Ask the business if this is effective and if there are other ways the business wants to communicate with us.
We also need to make sure that our customers know that we are there to deliver an excellent experience, and to do that we have a process (or processes) in place. This level of communication can be handled by something as simple as a one-on-one personal connection through to roadshows, surveys, discussions, and social media.
Availability of information about Problems or known errors
There are many escalations each day that are known issues. If you are at a point where you are able to have a public repository of known issues where users can check before they escalate, this will reduce calls into the service desk. In some cases the tool that generates the Incident will also have a place to view these documents. Put that to work for you, but ensure that you can track the usage on these knowledge tidbits.
The old saying goes you can only manage what you can measure.
There is no need to overcomplicate this. Determine what’s important to business and line up your critical success factors to match up. At the end of the day you are looking to identify how well (or not) you are delivering services. In the beginning, define or redefine your top goals and align your metrics to report on them. As you get more mature in the process you will be able to enhance your KPIs to make further improvements.
These are just a few of the common roadblocks that I have run into while working in Incident Management, and there are plenty of others. Feel free to let me know in which areas you have seen some issues.
For more brilliant insights, check out Ryan’s blog: Service Management Journey