Branimir Valentic I remember a situation when most of the users were quite satisfied with the functionality of a service, but when things got tough – completely different situation. There were a lot of complaints about the speed and performance of the support team. That was a mirror image of what an IT organization should be – a lot of mess causing people to be inefficient and lose a lot of time and energy.
So, it’s logical that something must be done, but how to begin? If you are keeping your eyes on the organization, its processes and performance – it’s easy. But, if you don’t…
Motivational factor
First of all – why would you be interested in measuring how efficient your process is? Before I answer, let me ask you a counter question – do you know how your customer perceives the value your service creates? There are three parameters:
- Preferences – what the customer expected to get
- Business outcome – what the customer received, i.e., what he can do with the service
- Perception – that’s the feeling your customer has regarding your services (and, consequently – you). And, that’s the hardest parameter to control.
Preferences are the subject of good preparation. Business outcome is based on the functionality your service provides. Actually, perception is a factor that is highly influenced by the people you have and how productive and efficient they are.
Let’s assume the service is delivering the agreed functionality. So, you can’t influence (at least, not significantly) preferences and business outcome. The only parameter you can influence is perception in order to increase the customer’s satisfaction. To do that, you need to know where you are, i.e., how efficient you are and what points you need to address.
There is one thing you must take into consideration when talking about the efficiency of Incident Management – who is doing the appraisal. Namely, users are interested in having their service function all the time, while IT internally is talking about KPIs (Key Performance Indicators), CSFs (Critical Success Factors), measurement, metrics applied… etc.
Users are focused on the functionality they are paying for, but “behind the curtain” there is a whole organization needed to maintain the provided (or, better to say, required) quality level. Take, as an example, a mobile network – you, as the user, just want to make calls or surf the Internet. But you don’t know (and shouldn’t care) about the effort required to keep the network available 24×7.
Figure: Different points of view
External view
Let’s see the world from the users’ eyes. What do they want? To use the service they are paying for. If something happens (i.e., an incident occurs) – they still want to use that service (remember, they are paying for it). And, there you have the measure – the service is working or not. If the service is available most of the time and incidents don’t occur too often – your users will (most probably) understand that errors or unavailability take place from time to time. But, don’t underestimate that. They know when they requested your help (in ITIL we would say – when the incident was opened) and when you replied, i.e., when you resolved the situation, whether it was with the expected quality… etc.
So, here are a few metrics that your users employ to create their perception about the service, i.e., your performance:
- Response time – although, with the usage of IT Service Management tools, this parameter is measured in seconds or minutes, your users like that human touch and the feeling that “there is someone behind the e-mail address or web portal.”
- Speed of resolution – simply, how long it takes from opening an incident until they get the message – “Your incident No. XXX has been resolved.”
- Quality of resolution – whether the provided resolution is really what they expected.
Internal view
This is more complex. Being responsible for a service puts many obligations on the IT Service Management organization. In order to keep control of the organizations’ (that could be, e.g., the IT department or some more specialized group like an ERP support team) performance and activities, as well as service performance and quality, you need to set metrics that will give you a clear picture of the situation. That means that you, as the responsible person (e.g., Incident Manager), would like to know how good, or bad, your team is. To do that, you set a bunch of parameters that you will watch. And, yes, the metrics that your customer uses – still apply. Here are a few examples of the metrics used internally by IT Service Management, i.e., Incident Management:
- Number of resolved and unresolved incidents
- Number of reopened incidents
- Number of incidents escalated to next support level
- Number of incidents incorrectly categorized
- Number of incidents incorrectly assigned
Lessons learned
Once you have your measurements, you have a solid foundation to create appropriate action. That means that you are now aware of the good points, but also where your weak points are. Additionally, you can use an extended incident lifecycle as explained in the article Availability Management – calculating for improvement.
You know your tasks, you are aware of your performance (i.e., how you do), and you know what you have to do (what you need to improve). Such a clear picture sounds great. But, be aware that you are dealing with incidents (i.e., life is full of surprises) and there is always a customer in the background. And they see everything – how good or how bad you are. So, nobody is perfect and neither are you. But, once you learn your lessons (i.e., monitor, measure, and improve your efficiency), try not to repeat in-efficiency.
Use this free ITIL Gap Analysis Tool to see how well your Incident Management process complies with ITIL recommendations.
