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


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: SedAveds
New Today: 22
New Yesterday: 37
Overall: 231707

People Online:
Visitors: 121
Members: 0
Total: 121



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

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.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Tracking "Problem" Cycle Times
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Tracking "Problem" Cycle Times

Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message

Joined: Aug 02, 2012
Posts: 12

PostPosted: Fri Mar 29, 2013 2:36 am    Post subject: Tracking "Problem" Cycle Times Reply with quote

Hey everyone....As we prepare to launch our revamped ITSM processes, we're debating whether we should track a couple metrics on the Problem Mgmt side. Both metrics provide some value, but we're wondering if it's enough value to make it worth formally tracking month to month. Do any of you guys track these (or somethnig similar)?

1) "Average time to become Known Error" - Do you guys track a metric that shows how quickly your problem records become Known errors? We're also already tracking the "% of Problems with Available workarounds", so my question is focused on the cycle time to which it may become a known error, and whether you track that.

2) "Average time to identify solution" - This would represent the time it took to identify the permanent fix (Not simply the workaround). We're already tracking "Average time to identify Root Cause" and "Average time to Resolve Problem". Just wondering if you guys dive into that cycle time even further & measure when the permanent solution is identified, to highlight the gap between when the solution was identified & when the solution was implemented.
**I know there's situations where you may choose not to implement the permanent solution based on time, cost, available workaround, likelihood, etc....but I'm looking at this question more along the lines of your "typical" (using loosely) problem that makes it through the full implementation process.**
Back to top
View user's profile
Senior Itiler

Joined: Mar 04, 2008
Posts: 1894
Location: Helensburgh

PostPosted: Fri Mar 29, 2013 3:23 am    Post subject: Reply with quote

Properly speaking

1) a problem does not become a known error; it acquires the status of known error and remains a problem.

2} there is no such thing as the typical problem. The only effect of measuring averages in problems is to tempt people (managers) to use the meaningless figures for their own ends.

Typically, but not always, a problem has a work-around from day one 9even if it is just to reboot or reload something), but as more is learned of its cause and context it sometimes gets an improved work-around. you could measure time to achieving different capability work-arounds, but what does it prove?
"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
Back to top
View user's profile Send e-mail

Joined: Aug 02, 2012
Posts: 12

PostPosted: Fri Mar 29, 2013 4:16 am    Post subject: Reply with quote

Diarmid.....C'mon man. I respect that you're a Senior ITILer, and as I can imagine, you're loaded with ITIL knowledge. However, if these forums are meant to help provide guidance to others, I'm hoping these threads don't become a nit-pick the specific verbiage being used. In your defense, I can see how question #1 can be taken in it's literal sense so let's reword it a bit.

1) I get that it doesn't "become" a known error, so lets consider it was something like "Average time a Problem acquiries the status of Known Error". The value I could potentially see here is you're measuring how quickly your Problems w/ workarounds are aded to your KEDB & thus readily available to your Tier-1 support or any other team. A workaround may be identified early in the process, but if the problem/workaround isn't communicated through the KEDB in a timely manner, there's the risk that new incidents (related to that problem) could come in and the workaround hasn't been communicated through the KEDB. I'm not sure why measuring that would be meaningless if one of the objectives of PM is to "Minimize the adverse impact of incidents". The use of a KEDB helps communicate workarounds to improve MTTR for incidents, so why wouldn't you want to measure how quickly a problem/workaround gets added to the KEDB to see if there's a CI opportunity there? I'm not saying you necessarilly have to measure it, I just want to know the argument against doing so.

2) Did you miss the quotation marks I used around Typical? I know there's no such thing as a "typical" problem, but was trying to have the reader consider a problem that makes it through the full cycle from identification to permanent solution. While I may agree that tracking "Average time to identify solution" may not provide much value, I couldn't disagree more with your thought that Averages in general on Problems are "meaningless", so you have to help me understand what you use as alternatives to help tell the PM story. Without averages to some extent, how do you know where gaps exist in the process?....How do you know whether teams struggle in the time it takes to find the root cause of Problems?....If Leadership asks the Problem Mgmt Process owner how quickly the department resolves Mission-critical Problems, how would you answer that without the use of averages? I think averages help tell part of the story (not the whole story) & identify areas where gaps exist in the process. Saying that averages in PM are meaningless seems a bit naive, though, so help me understand why Averages in general are "meaningless" & let me know what you'd use to help tell the story of Problem Management's effectiveness. Simply saying it's meaningless doesn't help me out, but maybe providing alternatives will help me understand where you're coming from.

Thanks for your input...much appreciated.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion All times are GMT + 10 Hours
Page 1 of 1

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

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.