What are the right metrics to track progress in Problem Mgmt

[BigM]

I am working on implementing some metrics for our newly implemented problem management process and wanted to know if there was one or two metrics that best track progress for PM.

Thanks....

[Diarmid]

Hi,

a good start would be to read through the thread "Problem fix timescales".

I'm not sure how you can have implemented the process without it having already identified the metrics since the identification, gathering and meaning of metrics should be integral.

I think it is very difficult to measure the effectiveness of problem management because the pro-active role avoids problems before they reach a state where you can measure what they would have cost.

Reduced numbers of incidents can also be misleading because each level of improvement allows people to use services more aggressively and stumble across new problems. Of course black marks if incidents occur caused by problems that were thought to be resolved.

Numbers of problems resolved and numbers of problems outstanding tell you something, but that gets complex when you consider whether thet are waiting for external input, future event, availability of resources or are just stuck because nobody can fathom out what the cause is.

In many organizations the technical resources are the same ones that do development and/or support roles and their availability has to be prioritized; you have to be able to measure just what resource is available.

You can measure the stages - evaluation, root cause analysis, design of resolution, development, implementation - in terms of staff time, elapsed time, cost (against benefit).
_________________
"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

[BigM]

Thanks for the post....very enlightening.

If we were to look at the Root Cause Analysis for example, would a metric such as avg. # of day's to cause be a good measure or is that too simple?

[Diarmid]

Hi,

[BigYounks]

Not sure I would use time as a metric for RCA. Problem Mgt shouldn't have any type of OLA or SLA associated with it. The goal is to fix the problem and fix it right the first time...not the fastest. Leave that to Incident. Some of the metrics we're using for Problem Mgt are Problems that have generated Changes (or a potential for an official RFC), those that have spawned a project (which could potentially create an RFC) and the number of known errors discovered, recorded and communicated to the Service Desk.

Dave Younker
Problem Manager, Maritz Inc.

[asrilrm]

Hi BigM,

I'm not sure if I can understand you right.
But I never heard metrics used as progress tracking.
Metrics are usually used as a basis to measure the effectiveness of a process

I'm a Change Manager. To help me track progress, I divide the activities in CM Process in stages and controlled as milestones, such as:
- Registered
- Analyzed
- Approved
- Developed
- Tested
- etc
There I can track in what stage a RFC is on.
I hope this can make an analogy to Problem Management

Cheers,
Asril

[asrilrm]

Hi again,

I guess I misunderstood your question.
If you are referring to the time to resolve a problem, then I suggest you find at the ITIL Open Guide.

cheers,
Asril

[Diarmid]

Hi,

[troy23]

Its a tough one, I am struggling with the same thing.

Reduction in incident volumes for the config items is one way.
As mentioned, throughput of problem records is another but that is more of a way for continuous improvement of the process. E.g. try to remove waste or rework.

The measurement to workaround solution would be a good one as at least that returns service, the permanent fix is the one that can take considerable time to achieve.

[Brian1]

Big M, your question is kinda vague because you did not tell us what the metrics will be used for and who your audience is. One metric you can use is a "pipeline" report. Using phases or stages to show progress through your process you can graphically report how many problems you are workign on and how many are at each stage. If this is a monthly report you can show the changes (plus or minus) from the previous month to demonstrate progress. Linking time to this you can report on the average number of minutes/hours/days that a problem is taking at each stage.

A more time consuming report to compile is a "Call Reduction Report". Basically for each problem you work on, you generate an incident report to build histroical data. Once you have implemented a solution you continue to track incident volume for up to a year. This way you can show on a monthly or annual basis how many calls you saved the Service Desk and through some financial calculations report to senior management the number of hours of productivity you put back into the organization. If you can link this into your organzation to show each business unit what you have saved them. This is information your CIO craves but doesn't know it yet.

[Doober]

As Brian1 already pointed out, it all depends who's asking the question, and also what they're asking.

IS PROBLEM MNGMENT PROCESS BEING ADOPTED?
- Show # of Problem records over time.
- Show Problem records non-conforming to proces (leave you to determine how that could be measured)

IS PROBLEM MNGMENT PROVIDING VALUE?
- Show # of KEDB articles used by service (provided you captures service on both Problem and Service Request/Incident. Also requires a means of determining if KEDB article was used)

There's a report you can build for every question out there... the key is: "What are the questions"?