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.

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

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.

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

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

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.

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

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.

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

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.