ITSM dashboard for small teams: what to measure

IT service management is often presented as something for large organisations, with an ITIL programme run by a project team and an implementation partner. A smaller organisation also needs outages fixed quickly and changes made in a controlled way, and it has commitments to keep too. It does not have the budget or the headcount to set up a programme for it.

You do not need that programme to get things under control. What you do need is a handful of metrics that you look at regularly and act on.

Start with the question

Most dashboards that end up unused were built around what could be displayed, without asking what people needed to know. You get a screen full of gauges that nobody looks at, because no decision depends on any of them.

A metric is useful when someone owns it, there is a target or an expectation, and someone acts when it goes off track. If one of those is missing, the metric is merely nice to know.

Seven metrics that tell you something

1. New incidents per period

The number of new incidents per week or month, with the trend alongside. It is your base volume. If it rises steadily, that is either a capacity issue or a sign of an underlying problem.

2. Open incidents, and how old they are

Besides how many are open, look at how long the oldest has been open. A single incident that has been open for 298 days tells you more about your process than an overall average does.

3. SLA compliance per priority

Look at each priority separately rather than at one overall percentage. An overall score of 80% says little if you cannot see which priority falls short.

4. Resolution time, and where it goes

The total time from creation to closure is the starting point. You learn more from how that time splits into waiting on the caller, waiting on another operator group and actual work.

5. Number of handovers per incident

Count how often an incident moves from one operator group to another. Every handover costs time, and some context gets lost along the way. If incidents in one category are routinely forwarded three times, fix the routing, because adding people will not help.

6. First-line resolution

The share of incidents resolved without escalation responds fastest to better knowledge items and better intake, which makes it a good way to see whether an improvement is working.

7. Distribution across operators

Use the distribution to spot imbalance, and do not rank people on it. If one person consistently carries twice the load, that is a continuity risk.

Three metrics that tend to add mostly noise

• Average resolution time across all incidents. Incidents vary too much. Put a password reset and a network outage into one average and you get a number that tells you nothing.
• Incidents resolved per operator, as a performance measure. When operators are judged on this, incidents get split up. From then on, you are mostly measuring how people log their work.
• Customer satisfaction with a 4% response rate. A score of 8.7 out of 10, based on seventeen responses out of four hundred incidents, mostly tells you who took the time to reply.

Starting small

You can build this up step by step, in the order below.

1. Log everything consistently. As long as half the work comes in through a conversation in the corridor or a chat message, you are only measuring part of what happens. Of the four steps, this one matters most, even though the work is dull.
2. Set up categories you will want to filter on later. Eight usable categories that everyone fills in properly work better than forty that are half used.
3. Automate the repetitive work. Think of password resets, standard requests and recurring incidents. Doing so often saves time before long and makes your numbers cleaner.
4. Look at the same metrics every month. One look at a number tells you where you stand on that day. If you look at it every month, after a year you can see the trend.

What a dashboard adds to this

With a dashboard you can check metrics like these in passing, without putting them together every month. The difference seems small, but it leaves more time in the conversation for deciding what to adjust.

Make sure you can drill down into the numbers. When someone in a meeting asks “So which incidents are those?”, you should be able to show them in that same meeting, or the discussion gets stuck on whether the number is right at all.