KPI confusion

[nzmoko]

Any insights welcome,

I have seen all sorts of KPI's for Problem Management and to be quite honest, it's confusing to me.

Example:

# of incidents
reduction in the # of incidents

Which one is a KPI? Some say both whilst others say reduction... Some even say the reduction is a metric. Ugh!

Thanks in advance

[Bluesman]

Look at it this way:

The PM process needs tools (KPI:s) to evaluate itself, other processes (IM, CM, etc) and to be evaluated by other processes (or management).

Your KPI:s should therefore (IMHO) be sorted into 3 groups, mainly:

1) KPIs for evaluating other processes
2) KPIs for internal evaluation
3) KPIs for external evaluation

Some examples (out of our shop and off the top of my head):
1)
# incidents/MI that were submitted from IM to PM with FULL and adequate documentation
# incidents correctly matched against the KEDB

Add a few more, to evaluate the communication and routines between IM and PM as well as the IM process output in general

Do the same with CM, SLM et al. One or two well chosen KPIs will point to weaknesses!

2) Here you can use the majority of the "standard" PM KPIs, but try to concentrate on measuring effectiveness (length of problem queue, time needed to resolve problem, number of submitted Known Errors to the KEDB and on and on. Many of these can be used by others to scrutinize the PM process, see 3)

3) Use KPIs wisely here. Be prepared to be watched by others, and offer a short monthly report to mgmt and the surrounding processes - to begin with.


All in all - not all KPIs make sense in all workplaces. Stay sane, don´t overdo it. Keep the helicopter view, don´t become too granular. You will eventually find the (few) crucial ones that really MEAN something and they will help you improve things.

Hope you get the idea. Lots more to read in the excellent book "Metrics for IT Service Management" by ITSMF.
Regards /Richard
_________________
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr

[Diarmid]

I'm not convinced that Problem Management can be meaningfully subjected to KPIs in the sense of statistics except about money.

The number of problems in the queue depends on the number of problems that surface (that might be usable as a measure of the quality of other processes from which these problems emerge, but not of Problem Management).

Problems are largely dissimilar to each other. The time it takes to determine the underlying cause (some call this root cause) is dependent on the complexity of the system and the quality of the symptoms as data. The time taken to fully resolve a problem is dependent on the complexity, cost and scale of the solution, and can also be affected by priorities for resources over fairly long periods.

There are two areas that can be addressed:

1. Costs - you want to establish that the cost of Problem Management is covered by the projected savings from incidents not occurring as a consequence.

2. Efficiency and effectiveness - in Problem Management a lot of this is down to judgement about about process and practices and more subject to logical analysis than statistical. Audit will play a part, but the main thrust must be improvement initiatives. The best confirmation of improvement will be an increase in projected benefit over cost. Projected benefit is itself part judgement since the actual cost of incidents can only be determined by observing them and that is what Problem Management is trying to prevent.

If you train your technical analysts they should arrive at causes and solutions quicker, but it is not easy to prove since each problem is different.

If you improve the flow of information and co-operation to and from other sections then your solutions should be arrived at quicker and they may be better solutions. Again, each problem is different...

All the above is less true in very large and/or complex systems if these experience a lot of problems, but many IT services will not have much useful statistical data about Problem Management.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[Marcel]

[iradek]

Hello Mate..

I would suggest few things on KPI monthly . You can compare with previous months or years

Total Volume of the tickets
Total Closed tickets
Mean to restore ( To check how far we are doing the best )
how many tickets occurred by a change ( problem due to change

you can split the tickets on
3rd Party
Application
Capacity
Database
Hardware
Network
Planning
Process
Security
Software
Testing

Once you have this data for couple of months , You can start working on the proactive problem mgt ...


i hope this helps you...

[Marcel]

[Bluesman]

iradek..you are missing the target mostly, those are mostly IM. And you forget "User" in your category list..

Problem management needs metrics on input and output, as well as internal. KPIs are those metrics that help you judge the effectiveness and health/maturity of the process. Not all metrics do that. KPI= KEY performance indicator..

Example:
# of known errors (and solutions) posted by PM in KEDB
will show how helpful the PM process is towards IM - but it needs combining with other KPIs in order to show the whole picture. (After a while, most errors ARE known, hence a reduction in the flow.)

You may want to read up on this, I believe. See the book tip above.
_________________
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr