Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: VRounseve
New Today: 4
New Yesterday: 43
Overall: 146513

People Online:
Visitors: 41
Members: 0
Total: 41

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - KPI for Open Tasks??
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

KPI for Open Tasks??
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
burgboy73
Newbie
Newbie


Joined: Feb 01, 2007
Posts: 1

PostPosted: Fri Feb 02, 2007 2:19 am    Post subject: KPI for Open Tasks?? Reply with quote

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.
Back to top
View user's profile
eisbergsk
Senior Itiler


Joined: Nov 01, 2004
Posts: 81
Location: Sask, Canada

PostPosted: Wed Apr 04, 2007 3:06 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
jpgilles
Senior Itiler


Joined: Mar 29, 2007
Posts: 123
Location: FRance

PostPosted: Thu Apr 05, 2007 1:00 am    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
eisbergsk
Senior Itiler


Joined: Nov 01, 2004
Posts: 81
Location: Sask, Canada

PostPosted: Thu Apr 05, 2007 9:00 am    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
Globis
Itiler


Joined: Apr 17, 2007
Posts: 36
Location: Cape Town

PostPosted: Thu May 03, 2007 8:16 am    Post subject: Reply with quote

burgboy73 said:
Quote:
I'm trying to figure out what the standard benchmark KPI for the number of days a Task should remain open ..... We have been using 7 days, but I'm not sure if that is accurate or not

I'm not sure you can set a KPI for that aspect of problem solving, after all some problems are easy and are solved immediately, some you may never solve, e.g. a bug in an application you purchase. Some you might need to collect data for a month to be able to solve.

In other words it's like saying how long is a piece of string?

Moreover, if you have a problem that has minimal business impact and remains open for six months, is it something to worry about? Not really.

I think Sharon's suggestion is excellent, i.e. instead of trying to measure how long it takes to solve problems, measure what the effect of solving problems is. In other words look for KPIs that show the usefulness of problem management.

Perhaps you could look at a KPI that relates the time taken to solve a problem to the severity of the problem, i.e. the business impact. Or perhaps the time taken to solve problems related to the affected service - i.e. this might give you an indication in the areas in which you lack knowledge.

Sharon said:
Quote:
..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*..


Sharon, been there, had the same depressing reaction but you've got to see it from their side: they don't understand what you do (except in the broadest terms), they've got customers screaming at them, political infighting, golf at 3pm, divorce at 5pm, 10 people fighting for their job and the attention span of an amoeba (and possibly the same intelligence). If it's not 'Green is good, red is bad' you're going to struggle. The higher it goes the simpler it gets, but alway always always have the detail handy - occasionally you get one that listens;-)

Dave
Back to top
View user's profile
eisbergsk
Senior Itiler


Joined: Nov 01, 2004
Posts: 81
Location: Sask, Canada

PostPosted: Fri May 04, 2007 4:02 am    Post subject: Reply with quote

Globis wrote:

Sharon, been there, had the same depressing reaction but you've got to see it from their side: they don't understand what you do (except in the broadest terms), they've got customers screaming at them, political infighting, golf at 3pm, divorce at 5pm, 10 people fighting for their job and the attention span of an amoeba (and possibly the same intelligence). If it's not 'Green is good, red is bad' you're going to struggle. The higher it goes the simpler it gets, but alway always always have the detail handy - occasionally you get one that listens;-)
Dave


Hi Dave! First, let me say how much I've enjoyed reading your posts. welcome to the forum!
Thanks for the reminder on retaining perspective. After 31 years in this company I hope I've managed to develop a thorough understanding of bureaucracy, but some days are harder than others Wink (Love the 'attention span of an amoeba' concept!) Luckily, I get to 'retire' in about a month and will try to get work as a Problem Mgmt consultant. fun!
/Sharon
_________________
In theory, there is no difference between theory and practice.
In practice, there is!
Back to top
View user's profile Send e-mail
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sun May 06, 2007 2:45 am    Post subject: Reply with quote

eisbergsk wrote:
After 31 years in this company I hope I've managed to develop a thorough understanding of bureaucracy, but some days are harder than others Wink (Love the 'attention span of an amoeba' concept!) Luckily, I get to 'retire' in about a month and will try to get work as a Problem Mgmt consultant.


Hello Sharon,

I wanted to congratulate you on your upcoming retirement. I certainly hope it doesn't mean that we're losing the pleasure and value of your contributions in the community.

My Very Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL
Back to top
View user's profile Send e-mail Visit poster's website
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3316
Location: London, UK

PostPosted: Sun May 06, 2007 3:09 am    Post subject: Reply with quote

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
Back to top
View user's profile
eisbergsk
Senior Itiler


Joined: Nov 01, 2004
Posts: 81
Location: Sask, Canada

PostPosted: Sun May 06, 2007 6:35 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send e-mail
ranjithraghunathan
Itiler


Joined: May 09, 2007
Posts: 22
Location: Bangalore

PostPosted: Wed May 09, 2007 8:14 pm    Post subject: Reply with quote

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
Back to top
View user's profile MSN Messenger
eisbergsk
Senior Itiler


Joined: Nov 01, 2004
Posts: 81
Location: Sask, Canada

PostPosted: Thu May 10, 2007 5:34 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send e-mail
ranjithraghunathan
Itiler


Joined: May 09, 2007
Posts: 22
Location: Bangalore

PostPosted: Thu May 10, 2007 6:09 pm    Post subject: Reply with quote

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.
Back to top
View user's profile MSN Messenger
Bondy
Newbie
Newbie


Joined: May 14, 2007
Posts: 2
Location: Chesterfield, England

PostPosted: Mon May 14, 2007 11:01 pm    Post subject: Problem Management KPI's Reply with quote

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
Back to top
View user's profile
ranjithraghunathan
Itiler


Joined: May 09, 2007
Posts: 22
Location: Bangalore

PostPosted: Mon May 14, 2007 11:26 pm    Post subject: Reply with quote

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.
Back to top
View user's profile MSN Messenger
Bondy
Newbie
Newbie


Joined: May 14, 2007
Posts: 2
Location: Chesterfield, England

PostPosted: Mon May 14, 2007 11:49 pm    Post subject: Reply with quote

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 Very Happy
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.