Problem Management KPI Suggestions

This is a follow up to my last post on the subject of KPIs in Problem Management – read that previous post for background. In what I write I’m assuming that the KPIs are going to be used in a report whose audience will be the Problem Management team (therefore, quite detailed).

I’ve concluded that we are looking for signs that the Problem Management process is working. Here are some suggestions for you to try.

1. Number of Problems raised.

This is a tricky one – I’d never show this figure without comment. A figure which is low may indicate a situation where Problems are not being adequately identified, as I’ve discussed in this post. You can compare this to the number of Incidents raised over the period, to see if the rising/falling trends are the same.

2. Number of Problems Resolved.

There are a few ways I’d present this. I’d show the number of Problem satisfactorily resolved, and the total number of Incidents linked to these Problems. This is useful because it tells us how many Incidents we’ve finally got to the root cause of.

Then I’d produce a summary listing, so that the detail can be seen. I’d show the Problem Reference number, Priority, a one-line description, and the number of linked Incidents. Doing this allows readers to see how the ‘overall’ figure breaks down.

3. Days open for unresolved Problems.

One of the things that you wish to see in your Problem Management process is that tickets that are logged do (eventually) move to resolution, and so you want to see how long Problems have been on file for. An easy way to express this graphically is to have a ‘days open’ figure along the vertical axis, and then to list each open Problem along the horizontal axis, with its reference number, showing how long it has been open.

I have met customers who have used Service Level Agreements on Problem Management. Generally I don’t approve, partly because SLAs should be for things that a customer sees (like an Incident), but mostly because I don’t think it improves efficiency or promotes best practice. Sometimes Problems can (by their unexplained nature) can take a long time to come to a satisfactory resolution, and the outcome we want is a quality (complete, accurate) resolution. What is important though is that your own procedure make sure that Problems don’t just stall, but continue to be moved forward.

4. Activity since last reporting period, per Problem

I’ve written above how we need to make sure that Problems are being looked at, priorities, managed and assessed by the team – rather than simply gathering dust in your service management tool.

Whilst more of a status report, list each Problem and give a brief (no more than one or two line) summary of what you’ve done since the last reporting period.

So for instance, if you are reporting every fortnight you might say ‘Identified application X as possible cause, currently discussing with vendor support’ for a given Problem ticket. Serio uses would simply create an Action called ‘Progress update’ for this purpose, to be completed by those assigned Problems within the service management teams.

Needless to say, you are looking for signs of life across all or most of your Problem records because without that we won’t move to resolution.

[Edit: I issued an amendment (actually, a little more detail) to this post. Click here to see the post]

[Edit by Blog admin: See also the related Incident Management KPI post