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: FYFE
New Today: 51
New Yesterday: 73
Overall: 143543

People Online:
Visitors: 49
Members: 1
Total: 50 .

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 - Major Problem Review
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Major Problem Review

 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
nzmoko
Newbie
Newbie


Joined: Aug 29, 2008
Posts: 17

PostPosted: Thu Nov 06, 2008 5:31 am    Post subject: Major Problem Review Reply with quote

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.

Appreciate any feedback on this.
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Thu Nov 06, 2008 7:12 pm    Post subject: Reply with quote

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


Joined: Aug 29, 2008
Posts: 17

PostPosted: Mon Nov 17, 2008 8:19 am    Post subject: Reply with quote

Diarmid wrote:
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.


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


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

PostPosted: Mon Nov 17, 2008 7:18 pm    Post subject: Reply with quote

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


Joined: Feb 23, 2005
Posts: 458
Location: London

PostPosted: Mon Nov 17, 2008 7:37 pm    Post subject: Reply with quote

nzmoko,

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?

(Beige badge)
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Mon Nov 17, 2008 7:57 pm    Post subject: Reply with quote

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


Joined: Sep 21, 2006
Posts: 63
Location: USA

PostPosted: Tue Nov 25, 2008 8:05 am    Post subject: Reply with quote

UKVIKING wrote:
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
Back to top
View user's profile
nzmoko
Newbie
Newbie


Joined: Aug 29, 2008
Posts: 17

PostPosted: Mon Dec 15, 2008 6:00 am    Post subject: Got there in the end... Reply with quote

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