ITMPI FLAT 005
Main Menu
Home / IT Governance / Incident Management / To Improve Metrics, Look in Reverse

To Improve Metrics, Look in Reverse

BloggingAllianceButton

A colleague of mine was saying that, in a recent leadership meeting, her team came to the conclusion that they needed to improve service delivery, and to do this they may need to implement or rework a particular process. Their homework assignment for the next meeting was to outline what they thought was a good way to not only ensure that they were implementing something that would add value from a process perspective, but would be easily sustainable in the long term.

For me, no matter what the improvement initiative looks like, it will always have a component of metrics to support what and how I will attack said improvement. After all, you will need to be able to measure what you are implementing, and if you want to continue to be able to improve you need to show what a baseline for ‘today’ looks like.

One of the first steps I mentioned to my colleague to look at was ensuring that the improvement initiatives have all the makings of SMART goals. They should be specific, measurable, achievable, realistic, and time-based. Now that you have the framework, you can get to the root of what you are looking to accomplish for improving service delivery.

From a roadmap perspective, think about what your end state should look like and then start to work “backwards.” I asked my colleague what the largest pain point was currently for her team. She said it was the rate at which service requests were being handled. On average they were able to resolve requests within 43 business hours. The expectation was that these would be resolved within 24 business hours.

Knowing where you want to be, you can help filter out what metrics really matter as they pertain to the challenges you face. To start with she looked at “average duration of incident by priority,” which seems like a fairly obvious place to start.

Without looking through a sea of metrics she was able to spend more time focusing on what was going on from a resolution perspective. When she looked at the resolution rates based by priority, something obvious jumped out right away. She was able to see that the teams were handling the top-priority requests really quickly. This was the first win. While not all requests were being handled within expected limits, she was able to identify that top-priority tickets were being completed in great time. Don’t forget to ensure that teams know what they are doing right—celebrate this success!

Now that she knew what her team was doing well, she could clearly see where the longer duration issues existed. With this data exposed she would be able to dial into this with more scrutiny. Remember though, I said that we were looking at this in reverse so don’t focus solely on the outcome.

Look to identify what is causing constraints on achieving the outcome itself. It could be the number of escalations of requests, or that there is a lack of specialized resources. Whatever the slowdown might be, there is a root cause to consider in your investigation, as this is where the improvement is likely going to be implemented.

While you might not get to the goal right away, communicating with your stakeholders on the progress will allow you to share in the team’s success in not only improving the service delivery, but likely in streamlining the way you are providing service.

 

For more brilliant insights, check out Ryan’s blog: Service Management Journey

About Ryan Ogilvie

Profile photo of Ryan Ogilvie
Ryan Ogilvie is a Service Management consultant in Calgary, Alberta with Blackfriar Consulting inc. While working with stakeholders to achieve their business outcomes is his main focus you can also catch his commentary on his blog – Service Management Journey. You can connect with him via the various links below.

Check Also

5 Tips for Getting Started with ITIL

It would probably require a magic lamp and maybe a monkey’s paw in order to …

Leave a Reply

Your email address will not be published. Required fields are marked *