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: RDaley
New Today: 40
New Yesterday: 87
Overall: 139940

People Online:
Visitors: 58
Members: 0
Total: 58

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 - 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
DustinW07
Newbie
Newbie


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
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

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
DustinW07
Newbie
Newbie


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 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.