3.10 What Metrics Will Be Used?

Above all else, remember why we produce management reports and identify key performance metrics.

“To enable stakeholders involved in IT service management to make informed, rational decisions about the IT services and support offered to customers”.

Starting from this premise, some of this data is going to be more important to us than the rest. We will refer to the data which is important to us as Key Performance Data.

Your own choice of what is Key Performance Data should be influenced by:

  • The challenges you face in delivering IT services to customers

  • The demands made of the IT Service Management function by stakeholders

  • The intended use of the reports

  • Audience of the reports

For instance, you may provide an E-mail system and your organization requires the SLA to be met 90% of the time. In this case, it would make sense to include SLA target achievement data as part of the Key Performance Data.

At first glance, it might seem that identifying your Key Performance Data is a very difficult task, particularly as there will be a lot data to use in reports. To help, we are going to classify performance data into the requests types that we have used previously, those of Service Request, Incident and Change. In each case, you need to have a clear idea of what the data might tell you about the services you are providing to customers.

Service Request:

  • The total number of service requests (for trend analysis)

  • The breakdown of service requests at each stage (e.g. logged, work in progress, closed, etc.)

  • The size of the current backlog of outstanding service requests

  • The mean elapsed time for handling each type of service request

  • The number and percentage of service requests completed within agreed target times

Incident:

  • In addition to recording the number of incidents logged each week, compare the numbers to incidents logged prior to implementing incident management

  • Show the average length of time taken to resolve incidents before and after implementing incident management

  • Where possible, show the types of incident reported

  • Show the percentage of incidents handled within the agreed response time

  • Show the percentage of incidents closed by the service desk without the need for contacting technical support

  • Show the number and percentage of incidents resolved remotely, without the need for a visit

Change:

  • The number of changes implemented to services which met the customer’s agreed requirements, e.g. quality/ cost/time (expressed as a percentage of all changes)

  • Reduction in the number of disruptions to services, defects and rework caused by inaccurate specification, poor or incomplete impact assessment of changes Reduction in the number of unauthorised changes

  • Reduction in the number and percentage of unplanned changes and emergency fixes

  • Change success rate (percentage of changes deemed successful at review/number of RFCs approved)

  • Reduction in the number of changes where remediation is invoked

  • Reduction in the number of failed changes

  • Average time to implement based on urgency/priority/change type

  • Incidents attributable to changes

  • Percentage accuracy in change estimate

Along with metrics for each of these areas, you should also consider measuring the satisfaction of your customers that interact with the service desk. This is an area this is frequently overlooked but carries substantial value.

A good approach to measure customer satisfaction is case-by-case surveying. Each time a case is closed, which means the request has been resolved and the resolution has already been communicated to the applicant, a short survey on the case is sent to the customer.

With the following example survey you might want to add options such as very satisfied, somewhat satisfied, somewhat dissatisfied and very dissatisfied. Do not use “NA” or “neutral”.

  • Speed of response

  • Was your question answered in full?

  • Knowledge of staff

  • Ability for help desk to diagnose the problem quickly

  • Helpfulness of staff

  • Professionalism of staff

  • Ability to get through to a staff member promptly

  • Time to solve problem

  • Kept informed of the progress of your ticket

  • Ease of opening your help desk ticket

You then might want an open ended question about how your customer sees how you could improve your overall service or anything else they may want to add.

Service Desk Proposal

Now it's time to bring together what the business has asked for, what I.T is capable of delivering, any gaps that exist and metrics to demonstrate delivery. This will then be discussed with the key stakeholders that you have been meeting with to obtain alignment. Adjustments may need to be made to the proposal before alignment will be obtained. It is vital than any adjustment and the reason for it is recorded. More than one meeting may be necessary.

The proposal should cover:

  • Who will be supported within the business: Departmental level, don't go down the level of individuals

  • What will be supported: Categories and types of item e.g Laptops, Desktops, MS Office etc. Break out by department if needed

  • What requests will be covered: Service Requests, Incidents , Changes Illustrate with examples for each type of request

  • What response will be given: Baseline is SLA by categories and types Exceptions for certain departments and individuals

  • What metrics will be used: The list of metrics that will indicate success

Depending on your organisation, the proposal can be a slide presentation or a more formal document. For either case make sure that you make it readable for the intended audience.

Service Desk Charter

Now that the proposal has been accepted you should create a Service Desk Charter. We would suggest that you obtain signatures from senior IT and business management to help give it authority within your organization and also make it visible to the greater organization e.g publish on your internal website.

It servers two main purposes:

  • It lets your customers know what to expect

  • It lets you know what your goals are

This should not been seen as a something that is fixed in stone. You will need to revisit on a regular basis with your organization to make sure that these are what they require. Here's an example:

  • To enable incidents and requests to be dealt with quickly and effectively.

  • To ensure that an incident only requires reporting once.

  • To ensure that those providing technical support understand the details to enable them to resolve incidents as quickly as possible.

  • To provide a system that is up and running, even if only a temporary repair, but to ensure it is fixed completely within a specified time.

  • To get best value for money from those providing technical support by providing good quality information about incidents and requests.

  • To report on trends, common incidents and their resolution to business area leaders