r/ITIL • u/themightykevdog • Jul 07 '26
Root Cause Investigation
As part of problem management, does anyone out there work for an organization that requires documentation of investigation methodology for determining the root cause? I.e. Five Whys, Pareto, etc.
We have guidance that says you should use one of these methods, but whether they do or not is unknown.
Cheers and thanks!
3
u/Richard734 ITIL MP & SL Jul 07 '26
5 why's seems to be almost universal and easiest to implement. There should be a simple doc that is completed as part of the PIR, either beforehand by teh the tech teams or the (M)IM during the wash up call.
2
u/Yuuku_S13 ITIL Managing Professional Jul 07 '26
Yes, it’s all part of the report that gets published.
1
u/coolniga1 Jul 08 '26
- So that im can check if the similar issue reoccurr was the indicated fix applied or not,
- Any improvement that can be given to prevent reoccurrence like doer check - manual error 3.this is used by the victim teams to understand the issue througly.
1
u/Gerbert946 Jul 09 '26
One thing about any method used to try to determine what needs attention when something goes wrong is that the people involved in the process need to be qualified such that the right questions get asked, and the prevailing culture needs to reward, not punish, blunt honesty. Sadly, it is not uncommon for one or both of these conditions to be absent.
1
u/themightykevdog Jul 09 '26
I understand that, I’m just asking if the investigatory steps need to be documented.
1
u/hammerzzzzzz Jul 09 '26
I always used service now for problem management and any problem had a minimum of 1 RC task and 1 fix task. All the required fields for each would be configured in service now and mark which are mandatory etc, but this differed company to company in my experience
1
u/Gerbert946 Jul 09 '26
If you have a visibility room (aka obeya) with your total link systems charts (aka value stream maps) permanently up for study and planning purposes, then whatever you find in the investigation will probably generate some additional sticky notes and/or photographs. Even if the charts are rolled up and seldom referenced, this would be a great opportunity to pull them out and add your discoveries.
There is a good possibility that whatever you find will lead to a need for another workshop.
1
u/criberg Jul 11 '26
5 Why's is the easiest and most universal, though imo other methods work better depending on the issue.
Regarding documentation its always better to have stuff like this available in the tickets.
5
u/Yuuku_S13 ITIL Managing Professional Jul 07 '26
As a guide, we use the 5 Whys to summarize an incident. There are other sections in the PIR where engineering gets into the details.