Posted: Fri Mar 29, 2013 2:36 am Post subject: Tracking "Problem" Cycle Times
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.**
Joined: Mar 04, 2008 Posts: 1884 Location: Newcastle-under-Lyme
Posted: Fri Mar 29, 2013 3:23 am Post subject:
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
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.
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