I'm asked to write today for a customer who is taking their first steps with Problem Management - in particular, I'm asked to write about practical strategies for Problem resolution. We have other Problem Management resources, such as a white paper and blog posts here, here and here.

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.

Emailer Steve responds to this Problem Management white paper and poses this question: what can you do if no Problems are actually raised by the Incident resolution teams? Steve specifically mentions a period of over 4 months with no Problems at all being raised. Steve’s teams are handling 2500 or so Incidents per week, has 30 or so staff on the Service Desk and a further 70 working in specialist teams like I’ve referred to in this post on escalation.

Ever wished you could highlight High Priority Incidents red? Or Hardware faults blue? Here's how you do it.

1. Go to your list of Incidents, Problems or Changes.

If the last few posts have convinced you to give Problem Management a try – I’m glad. If not, I reserve my right to nag in future posts.

So how do you get started with your own Problem Management function, and what do you need?

Aside from a basic process, ideally you will have a CMDB (Configuration Management Data Base). I’ve posted about the CMDB here and here. I say ideally, because you can still derive benefits from Problem Management even if you don’t have one yet.

Here’s how you can get started: