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: SVancouve
New Today: 16
New Yesterday: 75
Overall: 142310

People Online:
Visitors: 68
Members: 2
Total: 70 .

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 - Root cause not found
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Root cause not found

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


Joined: Jul 22, 2010
Posts: 1

PostPosted: Thu Jul 22, 2010 10:20 pm    Post subject: Root cause not found Reply with quote

Dear,

What would you suggest when after investigation a problem you do not find the real root cause of it? what would be the next step to do?
thanks
Back to top
View user's profile
paulfixter
Itiler


Joined: Dec 22, 2008
Posts: 36
Location: Wakefield, West Yorkshire, UK

PostPosted: Fri Jul 23, 2010 5:56 pm    Post subject: Reply with quote

If you never find the root cause of the Problem then it can never become a Known Error.

You cannot close Problems, you can only close Known Errors.

So I guess if you do not find the root cause, it will remain open as a Problem.

I suppose you would have to determine was it worth opening as a Problem in the first place?
My rule of thumb for Problem creation is:
"a Problem is concerned with identifying the root cause, where the impact is significant".

I suppose that at the end of the day if you are satisfied that a workaround is in place even if you have not identified the root cause, you could concert to a Known Error and put the solution in you Known Error/Knowledge Database. It depends (copyright UKVIKING) what works for you.
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Fri Jul 23, 2010 7:25 pm    Post subject: Reply with quote

Known error is a red herring in this situation.

Paul is correct that what you do is to be determined by cost and risk. The more you know about the likelihood of incidents occurring from this problem and what the cost of those incidents is likely to be, the better able you are to proceed sensibly.

However, problem management is not focussed on finding the underlying cause, it is focussed on managing the problem out of existence. This is, of course, easier when you know the underlying cause.

If you cannot (or until) fix the underlying cause, you establish a workaround which (at significantly less cost than the implications of the problem) avoids or quickly resolves incidents arising.

If you cannot (or until) find a workaround, you establish damage limitation to reduce the impact of the incidents.

In the context of IT services, root cause is a limited concept that is overworked and often poorly understood. There are tiers of root causes all the way back to the origins of the universe.

If you have a potentially serous problem and you cannot find the "root cause", then you look for a higher "root cause". For example if a server keeps crashing and you eliminate software and OS as the cause, but cannot find a defective component, you consider replacing the server; or you prove it is something in the operating system but cannot find what, then you re-install the operating system or move your apps to a "better" operating system.

You go as high as you need while staying within the boundary of cost compared to benefit.

An untraceable underlying problem in third party application software, can be ultimately resolved by going to a new product from a rival company, but that is an enormously costly and risky exercise and you would live with quite some pain rather than do that.
_________________
"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
PM36
Newbie
Newbie


Joined: Sep 29, 2008
Posts: 2

PostPosted: Tue Jul 27, 2010 11:37 pm    Post subject: Reply with quote

I have reasonable success with this in our implementation of problem mgmt.

Our process dictates that we only close out a problem investigation when the issue has gone or is not recurring. I am guessing that this is what you are talking about.

When closing these investigations were no rootcause has been found but there has been no subsequent occurrences we use a success code rating for the problem.
On closure of all our problems the Problem Management function is responsible for assigning success codes.
We use 1 of 3 categories with quite simple definitiions, see below
Unsuccessful No Rootcause or Workaround or Fix.
Successful with problems Fix with No Rootcause and or Workaround.
Successful Rootcause + Fix and or Workaround.

This is all done within our Problem mgmt module of our service mgmt tool which allows for easy reporting.

The key here is reviewing the groups of "Unsuccessful" investigations at a later stage. We do this twice yearly. We splice and dice by Service, Infrastructure Components, Tecnologies and Teams looking for trends and follwoing up with the relevant stakeholders. Typically we ask what is it about the Service, Infrastructure Components, Tecnologies or Teams that inhibits effective rootcause analysis and look to remediate based on the dicussions.

Hope this helps.
[/b]
Back to top
View user's profile
noneforit
Newbie
Newbie


Joined: Jul 30, 2010
Posts: 18

PostPosted: Fri Jul 30, 2010 9:19 pm    Post subject: Reply with quote

Personally, I think that leaving a Problem Ticket open if you cannot find the root cause is not a good idea for several reasons:


1. Eventually the problem will become obscelete due to hardware/software/system replacement or upgrade
2. There is no benefit of keeping a problem ticket open if the root cause simply cannot be found.......surely it is just going to skew the call stats?
3. Sometimes for reasons outside of the problem managers control, a decision is taken not to put anymore resource into finding the root cause, either due to Point 1 above or financial reasons etc.


I do agree that you cannot convert the Problem to a KE as the root cause cannot be established but I just dont see the benefit of leaving it open if you (or someone else) has decided that the root cause cannot be found or nothing else will be done to investigate further

Even if you cannot find the root cause, you can still investigate a viable workaround to 'patch' the issue or at least mitigate the impact of the problem

ITIL is a framework, adopt it to suit the needs of your business
Back to top
View user's profile
Timo
Senior Itiler


Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Sat Jul 31, 2010 12:48 am    Post subject: Reply with quote

in my mind if the problem is still there the record should stay open, if only for the matching purpose.
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Sat Jul 31, 2010 7:10 pm    Post subject: Reply with quote

There is a substantial discussion on this question at Linkedin in the ITSM (ITIL) Professionals group. One of my contributions was:

" Reasons to stop working on a problem:

1 - the investigation will cost more than the problem will.

2 - the resolution will cost more than the problem will.

3 - there is no resolution (i.e. the "problem" is an inherent feature of something fundamental to the organization. In practice this is often a special case of the second reason, but where it is not then it is a built-in cost rather than a problem - and therefore could be closed).

4 - no cause can be determined (this is very likely to be a special case of the first reason).

5 - the environment in which it occurred no longer exists (this is a special case of both the first and second reasons - or it is a de facto resolution whichever you prefer).

It goes without saying that these need to be recorded in an auditable and verifiable manner.

Since circumstances can change, the first four are not unchallengeable reasons to close the problem (although the third might be in the stricter definition) in the sense of dropping all commitment to its resolution. In each case there could be specified a time and/or circumstance for re-visiting the problem. This review could follow a protocol for eventually closing problems. As an example of what to think about in such a protocol: when considering the length of time since the last incident emanating from the problem, there is a difference between the type of incident that, on its own, is of trivial cost, and that which would be of great cost."

And I should add that such decisions are business decisions. In other words these reasons should be an argued case referred to the appropriate level of management affected by the problem.
_________________
"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
Timo
Senior Itiler


Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Wed Aug 04, 2010 1:48 am    Post subject: Reply with quote

Ouch... lots of text, Diarmid. I should probably clarify... the problem should remain searchable even if the decision has been made to stop working on it. Could require some special status set for it, but still... if the potential for seeing such problem remains, the problem record should remain accessible.
Back to top
View user's profile
noneforit
Newbie
Newbie


Joined: Jul 30, 2010
Posts: 18

PostPosted: Wed Aug 04, 2010 5:13 pm    Post subject: Reply with quote

I agree with Timo, the problem still needs to be capable of being found by means of a search even if a decision has been made to stop working on it.

If your call logging system has a good built in search that allows free text etc then closing the Problem would be ok as it could be found later on.

If your call logging system has a bad built in search then it may be better to keep the problem open and assign a special flag to it...such as 'Unresolved' etc etc
Back to top
View user's profile
paulfixter
Itiler


Joined: Dec 22, 2008
Posts: 36
Location: Wakefield, West Yorkshire, UK

PostPosted: Wed Aug 04, 2010 5:25 pm    Post subject: Reply with quote

Don't forget you cannot close a Problem.
It must be converted to a Known Error first.

Just a small point I know, but people at work often say they will close a Problem and I say they will have difficulty. A bit pedantic I know! Very Happy
Back to top
View user's profile
noneforit
Newbie
Newbie


Joined: Jul 30, 2010
Posts: 18

PostPosted: Wed Aug 04, 2010 5:41 pm    Post subject: Reply with quote

paulfixter wrote:
Don't forget you cannot close a Problem.
It must be converted to a Known Error first.


You can close a problem if you so wish
It gets converted toa KE when the root cause is known and a workaround and/or permanent fix is in place.

What if you never find the root cause, do you just have an outstanding problem ticket?

Say you have an Problem ticket for a file server......the server gets replaced before you can find the root cause of the issue......it wont become a KE but whats the point of keeping the Problem ticket open?

ITIL is not a set of rules that every IT company 'MUST' follow, its a set of guidelines that can be adopted to suit your business

If you want to close a problem, then close a problem Smile
Back to top
View user's profile
paulfixter
Itiler


Joined: Dec 22, 2008
Posts: 36
Location: Wakefield, West Yorkshire, UK

PostPosted: Wed Aug 04, 2010 5:47 pm    Post subject: Reply with quote

Fair point. Perhaps this is a limitation of our system. It does not let us close a Problem (it is greyed out).
The system stipulates that we can only close a Known Error.

However, you are right in saying that ITIL is a framework. I am still personally uncomfortable with closing a Problem, however this thread has made for an interesting debate and I will probably be making some changes to our Problem Management Policy as a result to account for the different scenarios that can occur.

All the best
Paul
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Fri Aug 06, 2010 12:39 am    Post subject: Reply with quote

paulfixter wrote:
The system stipulates that we can only close a Known Error.


Sack your system. You could say it was being pedantic, but I think it is just plain wrong. Except, of course, for organizations that want to control problems in exactly that way.

As far as I'm concerned you can manage problems by having "known error" as a status for the problem, although it would make more sense to call it "error known". After all, it's still a problem until the resolution is in place.

The three advantages of knowing the underlying cause are that:

1. You can probably describe the symptoms accurately and therefore ascribe new incidents correctly to this problem

2. You can design a workaround with considerable confidence in its relevance

3. You can precisely determine the requirement of the resolution.
_________________
"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
DanA
Itiler


Joined: Feb 12, 2007
Posts: 27
Location: Minneapolis, MN, USA

PostPosted: Sat Jan 29, 2011 7:38 am    Post subject: Reply with quote

In these cases, we do close problems as undetermined. But we also ask for the senior leader of the owning group to approve the closure. Then we report on the "undetermined" problems and make them accountable for what they are approving. That way, we hopefully limit the laziness factor.
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.