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
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.
Posted: Thu Nov 06, 2008 5:31 am Post subject: Major Problem Review
We are currently mapping our PM process. Looking at the V3 Service Operations publication (page 60), I see that the MPR should be conducted after the closure of the Major Problem.
In our PM tool, we would typically close a Problem when we find Root Cause and open a KE.
There seems to be a gap in the ITIL process as I don't see any review happening when the KE is closed...
What I would like to do is cover the complete life-cycle and perform the MPR just before the KE is closed - this way, we will cover off what was done well and not done well from Problem creation to KE closure.
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Thu Nov 06, 2008 7:12 pm Post subject:
nzmoko,
I don't understand why you would not keep the problem open until you have implemented the resolution.
Raising a Known Error record (with or without an effective workaround) is not part of problem resolution; it is an expedient while you tackle the root cause and solution. The problem is still there. _________________ "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
I don't understand why you would not keep the problem open until you have implemented the resolution.
Raising a Known Error record (with or without an effective workaround) is not part of problem resolution; it is an expedient while you tackle the root cause and solution. The problem is still there.
I hear you... here is an example. We have RC for a problem (say, power related issue). Customer doesn't want to fix it because of cost and are happy to live with it. We don't want to keep the problem open because it counts against us in terms of performance (metrics/reporting). So, we close the problem and track it as a KE (because, that's what it is).
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Mon Nov 17, 2008 7:18 pm Post subject:
nzmoko,
There are two very different approaches to this case, and I favour each of them in the right circumstances.
But first, and absolutely vital, the costs and risks of allowing it to continue are identified and compared to the costs and risks of fixing it. Since, at this stage, there are no technical imponderables, the decision (not to fix) is a financial one, to be made by the appropriate arm of management.
Solution 1. Okay it is not a problem; it is a constraint (or feature, if you are a vendor ) of the service. Whenever its symptoms surface as an impact on service that needs fixed, a service request is raised rather than an incident report.
Solution 2. It is a problem; it leads to incidents. A known error and workaround and avoidance actions are all documented and applied. Meanwhile the problem record is set to awaiting resolution of costs for solution and all the costs are documented and tracked. This is reviewed periodically to be sure that it still costs more to fix than to leave.
Finally, for the second approach, you have to make your performance measurement for Problem Management just a little more sophisticated. This is better service than hiding the issue from scrutiny.
It would be a good idea to do this review in the first solution as well, but you have to find where to manage the review because you have removed the issue from problem management.
If i can just make the points that a) when you stop calling things what they are, you are heading for trouble; and b) when you compromise a system for the sake of statistics, you are quite likely using the wrong statistics. _________________ "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
I don't feel there's a great deal to discuss here. Do you want to have a post-problem review? If so, add one in for your major problems. ITIL is descriptive, not prescriptive, i.e. do as much or as little as you feel necessary for your organisation.
UJ _________________ Did I just say that out loud?
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Mon Nov 17, 2008 7:57 pm Post subject:
NZmoko,
I have a serious question ?
Are you not mixing your Incident management process (ITIL) with you Problem Management (ITiL) process
using your example, this is an incident NOT a problem.
A power related issue (RCA) would have been found during the incident life cycle - ie troubleshooting. This would not have required that a PROBLEM record be raised and then the UNDERLYING ROOT CAUSE be found.
Finding out that an event is the result of a power issue should be discovered by the Incident team during the troubleshooting for the incident. _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
A power related issue (RCA) would have been found during the incident life cycle - ie troubleshooting. This would not have required that a PROBLEM record be raised and then the UNDERLYING ROOT CAUSE be found.
Finding out that an event is the result of a power issue should be discovered by the Incident team during the troubleshooting for the incident.
I think this conclusion can not be drawn based on the vague information in the example that was given. In our large environment we do have some "power related issues" that require root cause analysis. For example, we have incidents with facilities where the UPS and generator do not provide power as designed when utility power is lost. Given the cost of these outages, we want to perform RCA and to find out why the emergency power infrastructure failed (even though the incident is often quickly resolved). A problem record is the vehicle to drive and track the investigation, which may result in one or more known errors.
Back to the original question. We do keep our problem records open until the associated known errors have been resolved and it has been confirmed that the problem no longer occurs (this confirmation can be a challenge in some cases). At that point you may find out that you did not address all root causes of the problem and you will need to continue the investigation.
There can be valid reasons to not resolve a known error or to even stop the investigation of a problem, for example if the resolution would be too costly compared to the 'damage' of the problem. In those cases we close the problem and/or known error with a specific status indicator. That way it is always clearly documented. _________________ Manager of Problem Management
Fortune 100 Company
ITIL Certified
Posted: Mon Dec 15, 2008 6:00 am Post subject: Got there in the end...
Quote:
A power related issue (RCA) would have been found during the incident life cycle - ie troubleshooting. This would not have required that a PROBLEM record be raised and then the UNDERLYING ROOT CAUSE be found.
Finding out that an event is the result of a power issue should be discovered by the Incident team during the troubleshooting for the incident.
I am dealing mostly with Telco problems where power related issues make up a large percentage of our incidents. RC is not always so cut and dry so sometimes PM are engaged to identify RC.
Thanks for your answer Marcel - it makes sense now. We got there in the end...
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
) of the service. Whenever its symptoms surface as an impact on service that needs fixed, a service request is raised rather than an incident report.
