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.
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.
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