Is the 5 Why analysis a better better approach to find root cause of a problem?

Question

Is the 5 Why analysis a better better approach to find root cause of a problem?

while doing it,will it become like blaming game?

Answer 1

5 whys is a good general approach to try and find root causes of problems, however its main problem is that it doesn't provide any guidelines for what questions to ask and when to stop. So if you try doing it with a group that is prone to blaming each other it can very quickly devolve into a blame game.

Answer 2

"5 why" is not always better approach to find the root cause of the problem. Some problems are too complex and connected with many other factors. Let's take case of life-cycle planning, you'll find many problems which are not solved from 5 why approach. Why ? There is no guideline on how we should approach with "5 why".

Answer 3

A place I've worked for uses it and their products are very successful. If you depersonalize problems and focus on fixing the issues rather than who did the issues, you can move further.

Answer 4

It's a good way to reflect and drill down a problem area and make sure that you're not fixing symptoms.

Every meeting or group discussion needs a facilitator, who ensures that the group doesn't derail and drive the train into the sea. Its the job of the facilitator to step in when subjective opinions are being voiced... you need to be objective in this case.

Answer 5

If you really want to get in the blame game, try the "5 Whos" technique!

Seriously... I have found this to be effective in "root cause analysis sessions". But the 5 Whys is not so much a recipe as a concept: It's a good idea to stop and reflect on why things go wrong, not from a surface level of who did it, but what about the development system allowed the problems to sneak through.

Actually, every time I have done this it has gone very well. We go through each of our resolved bugs and try to suggest a "root cause". I try to set the right tone early on, recognizing that I was a bit hasty trying to complete a task, or something like that. The team responds, "Why were you so hasty?", etc.

After we talk about each bug, we try to recognize common threads and reasonable fixes. Again, not a recipe, but part of a process. I try to limit the outcome of these meetings to a single, actionable item.