5xWhy – effective method for root cause determining

5xWhy is a key problem solving part. Thanks to it, we are able to define the real root cause, not the symptom. It’s important because for the symptom the containment actions are defined in the step D3 in the 8D report.

How then to carry out such an analysis?

Step zero is to correctly fulfill Ishikawa diagram. If we already know whether we are dealing with an incorrectly performed control, lack of its implementation or poorly defined process parameters, we go to the 5xWhy method

5xWhy – structure

5xWhy

Fig. 1. An example of the 5xWhy Method structure

The structure of the method itself is very simple, as it consists in asking questions five times that will most likely allow to get to the root cause.

In theory it seems easy, but in practice not necessarily anymore, because we can fall into several traps that will significantly make it difficult to continue:

5xWhy vs. 5 guilty

When conducting any meetings in a team, we must be aware of the importance of the relationships within it. I have had the opportunity to observe many times (even as a client’s representative) when during the meeting, the conversation moved from the “content” level to the “emotional” level. It’s a definition during which the meeting participants do not focus on the physical solution of the problem, but on reminding who didn’t do what and what it led to.

Teamwork, not a “one man hero”

Group work is very important during 5xWhy defining. Only the effect of synergy and modifying the ideas presented by other participants gives a better view of the problem, during which we can look at the operational activities carried out in our own area from a different perspective. One person cannot get it.

Quality of the team – who should solve the problem?

Continuing the topic of teamwork, it should be remembered that, unlike defining Ishikawa (which can also be attended by people from outside the production area), 5xWhy requires a person who knows the production process and technical issues. This knowledge most often appears from Why number 3, where the most common transition from general formulation to the technical area.

Additionally, the team should include everyone who has the problem, not just the person reporting it. Most often it is a quality person who reports customer complaints or internal problems. Then this person is obliged to organizes the team.

Objectivity, or “it did not happen with us”

Maintaining objectivity and going beyond the comfort zone is a very good feature of the participant taking part. It allows us to look at our process critically, without delegating responsibility to other departments. I had the opportunity to find out about it myself when I blamed the sub-component for the bent metal bracket. As it turned out later, such a problem could occur during incorrect bracket handling by the operator. Of course, it was not his fault, because such opportunities were provided by the designed production process.

5xWhy – example

Below is an example of the 5xWhy method that will help You understand the exact mechanisms between each question.

Problem: Unable to mount the instrument cover to the dashboard

Why (1):

Because the dashboard cover does not have the correct dimensions (it is too short).

Why (2) is too short ?:

Because the component cooling parameters were changed during the injection process.

Why (3) the component cooling parameters have been changed?

Because the parameters of the production process have not been password protected.

Why (4) parameters were not password protected?

Because after tests for the production of another product in the pre-launch phase, the process engineer forgot to activate the password for current production.

Why (5) Why did the process engineer forget to activate the password?

Because the production software does not force such an action when changing parameters from the test cycle to the production cycle.

In the above case, we can see that the action that can be introduced is the software modification. It should be done in such a way, that when switching between test and production parameters, they are immediately unavailable for modification by production workers.

Another action that can be implemented in a systemic way in this case is the modification of the check list for production tests performing by adding the following questions:

– Have the parameters changed from test to process parameters after the tests finishing?

– Has a process engineer activated password for process parameters?

You can download an automatic, editable Excel form for free on the Free Quality Tools

Document name: 5Why – Excel form

Dariusz Kowalczyk

Download for FREE our E-BOOKS

X