KPI for Open Tasks??

[burgboy73]

I'm trying to figure out what the standard benchmark KPI for the number of days a Task should remain open (Defining the Root Cause and Work Around). I am in the process of reporting our Problem Management performance to our executives and I need to establish what the "standard" KPI is for Open Tasks. We have been using 7 days, but I'm not sure if that is accurate or not.

thanks!

Brian
Limited Brands Technology Services
Columbus, Ohio.

[eisbergsk]

I would be interested in a standard, too. I've tried to get our managers to care that having an Problem in 'investigating' status (that's what I use to indicate that an actionable root cause has not been found) for more than 1 month is 'not good'. They've asked me to provide industry benchmarks. *sigh*
/Sharon

[jpgilles]

Hi,

I am not sure having standards is accurate. The "urgency" to solve a problem is very much dependant on several factors (business impact and frequency of incidents, for example) not talking about complexity: if the problem is related with architecture, I am not sure you can simply determine what needs to be changed in just 2 days or , in some cases, even one month, whereas with other type of problems 7 days might too long...

I would rather try to determine criteria to define target delays. You can then use the ratio of problems solved with delays to build your KPI.

my 2 cents contibution, if it can help

rgds
_________________
JP Gilles

[eisbergsk]

You make a good point, JP. The only difficuty I can think of is getting enough data to detemine the criteria (our volume is not high enough).
Brian, I think you might be lucky that your executives care about that KPI. I track information like crazy and have presented it every month with dance numbers and special effects and what did I get? "cut it down to 3". *sigh*
fyi, I picked
1. CSF "Improve Service Quality", KPI "% reduction in the Known Incidents & Problems encountered"
2. CSF "Minimize Problem Impact", KPI "% reduction in the average number of undiagnosed Problems", &
3. CSF "Minimize Problem Impact", KPI "% reduction in the average backlog of 'open' Problems & errors"
Best of luck
/Sharon

[Globis]

burgboy73 said:

[eisbergsk]

[Guerino1]

[UKVIKING]

I dont think there can be KPIs against Problem Management finding the root cause

Inside try this

Have a review when the investigation hits >>>> many hours and have the review board decide whether to spend more time or less time
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[eisbergsk]

Just to stay on topic, I'll say that I think John may be on to something...
Off-topic I'll say,"why, thank you Frank! That's very sweet. I hope to be able to keep my hand in"
/Sharon
_________________
In theory, there is no difference between theory and practice.
In practice, there is!

[ranjithraghunathan]

As much as it is important to find a permanent fix for an incident, it is important to temporarily resolve the issue with a workaround that enables continuation of service as you may know. I think I agree that we cannot have a strict KPI for Problem Resolution, however KPIs can largely be associated with providing a workaround with possible known resolutions listed down (needing further analysis to conclude), if possible to minute details and treat the Problem Request separately on a larger perspective to dig deeper into the Root Cause.

A similar situation was experienced in my workplace where we could not drill down the issue resolution with respect to running reports on an application and thereby a temporary resolution to cut down on the criteria for running reports was a positive fix for the time being and the problem request continued till a permanent solution was obtained.

The KPIs thus should be linked to the speed at which a permanent or temporary fix is provided to enable continuity of service.

P.S - I am a beginner, but suggestions to this comment may help me in getting better understanding of the ITIL concept


Ranjith Raghunathan
ITIL Foundation Certified

[eisbergsk]

Hi Ranjith - I'm wondering if you are mixing Incident resolutions and Incident KPIs, with Problem resolutions and Problem KPIs. Separate. Not the same. different perspectives. different objectives....
Ditto Knowledge Base and Known Error Data Base. Separate. Not the same. different perspectives. different objectives....
I've been caught on this myself, so if could you clarify your point it might help me or someone else respond....
*Faint, but hopeful*
/Sharon
_________________
In theory, there is no difference between theory and practice.
In practice, there is!

[ranjithraghunathan]

Sharon -

I think I see the distinction now. I indeed did get it mixed up.
Thanks for those comments and I agree with you.

But then willing to wait to see if anyone can push in their suggestions about the KPI for the Problem Requests.

[Bondy]

Hi...........

I understand where Ranjith is coming from here with his workarounds .

In many respects your Seniors will not worry too much about how long a Problem Record is open for as long as the Service Protection Wrap\workaround for the Problem is robust and protects service 100%

It would be very difficult to generate KPI's around this .
Indeed it can be very difficult to create KPI's and CSF's in general as there is only so much control that many Problem Managers have over the Problem Management processes , as many of the Problem Managers are dependant on the resolution areas \ 3rd party suppliers creating the fix pack for the Known Error , in some organisation this can take forever.

There is much debate over Problem Management and many people have different ideas and ideals, i.e is it good to have lots of Problem Records ( you have found all the issues ) or good to have few Problem Records ( only good if you can prove the infrastructure\applications are 100% perfect , not going to happen ).

My area has worked on a KPI dashboard that shows how each step of the PM process is managed and we set ourselves targets to reduce.
So we look at ' Time to progress to Known Error', ' Time taken to get a fix\patch or whatever', ' Time taken to progress fix through testing', ' Time taken to progress fix into Live environment' etc etc .

Hope this helps, I could go on for hours !!!!

Nick

[ranjithraghunathan]

Having read the comments so far, and my thoughts evolving through the journey from top to bottom, I think we could have KPIs defined when a Problem Management Tool is used.
I would refer to ITSP Remedy that I know of, and getting back to the initial "Problem Statement" from Brian the KPIs should be linked to tasks within Problem Management.

In ITSP Remedy Problem Records have tasks created that are assigned to different team members that assist the Problem Management team. These tasks are very specific and could be to get specific answers from the assigned team. Measuring responses from each team will help us in defining KPIs and thereby having an overall KPI for a Problem Record.

When there are say, 5 tasks that need task resolution before the Problem record could be taken further towards the final resolution etc....we could have different status assigned to the Problem records and this will enable in creating KPIs for the Problem Records.

Maybe someone could elaborate if they have anything implemented similar to this. This is just a thought.
_________________
Ranjith Raghunathan
ITIL Foundation Certified

P.S - Most of my posts are to understand the ITIL fundamentals clearly. So please excuse if not genuine answers to questions.

[Bondy]

Hi Ranjith,

Another worthwhile area of Problem Management KPI's\CSF's is in the area of PM proactivity .
You should be creating Problem Records that are driving down the total number of incidents from your estate.

This you should be doing via incident trending and closure analysis in conjunction with your Incident Service Desk.

You can then equate how many incidents your remove from the estate to an approximate cost saving, money saving will always impress the bosses and is another way of showing the 'worth' of your Problem Management function.

Protecting Service, removing costs , u cant go wrong

Nick