Determining Root Causes – 5Ys

The five why method is a proven and popular tool for finding the root cause of a problem but, it takes time to develop this skill. Beginners often ask and answer a series of unproductive “why” questions. This leads to a false or weak root cause. Structured problem solving methods like five why can lead to powerful remedies to problems in the workplace. Teams though, must first learn how to use this the five why method.

They say a bad workman blames his tools. In the same vain, a tool will only ever be as good as the person using it. Without having developed a mastery over the tools used in effective problem-solving, teams produce inferior solutions to nagging problems, problem solving becomes a compliance burden rather than a value adding essential business function.

Finding the Root Cause of a Problem

A Google search for “five why” presents us with a myriad of examples of five why analysis. Almost every example shows teams racing from a symptom to a root cause. In these examples, authors seldom explain how to ask effective “why” questions.

Five Why Mastery

How can teams master the five whys? How can teams identify actionable root causes and effective corrective actions? In this post, We will share simple techniques that help you find productive root causes so you can solve your biggest problems, quickly and effectively.

The fundamentals

The five why method – like many of the best tools – is easy to learn, but only after it is truly Mastered and correctly applied.

It seems simple: answer the “whys” and away we go. Beginners, though, often come to a quick dead end. Somewhere in their quest for root cause, they answer one of the “whys” like this:

  • Why? “Human error…”
  • Why? “We’ve always done it that way…”
  • Why? “Because the customer wanted…”
  • Why? “It takes too much time…”

Subsequent “why” questions take the team even further away from an actionable root cause.

Often the 5 whys also almost prompt the user to believe that once they’ve got close to or hit 5, the job is done.

It is also incorrectly assumed, that the 5whys are to be carried out as a single activity against the problem identified, with the whys not drilling deeper, but re-establishing previously raised areas of concern:

  • Whats the problem? “We did something wrong…”
  • Why? “We didn’t notice it…”
  • Why? “We should have…”

How To Complete The 5 Whys

Approach from different angles with a team

Yes, it is this easy once you are familiar with the technique :

Before you start, every problem always has two elements to it, and both should be considered independently as two 5why activities

  • The problem itself,
  • The fact the problem escaped

HOW TO DO IT:

  1. Write down the specific problem. What happened e.g. Parts have damaged thread. Writing the issue helps you formalise the problem and describe it completely and clearly. It also helps a team focus on the same problem.
  2. Ask why the problem happened and write the answer down below the problem.
  3. If the answer you just provided doesn’t identify the root cause of the problem that you wrote down in step 1, ask why again and write that answer down.
  4. Loop back to step 3 until the team agrees that the problem’s root cause is identified. Again, this may take fewer or more times than five whys.
  5. Do the same but now change the problem statement, to be the area or way in which the problem escaped. e.g. Parts received at customer with damaged thread.

For many who persevere, it takes two dozen or so five why root cause analyses, to “get it”. Although the question “why?” seems straightforward, the question itself must be poised and aimed at the right issue or problem.

Often this is where issues arise. The 5why works, when it is asked in the right way aimed at the correct target/subject or problem

Best Practices

Best Practice

These few tricks can help your team become more proficient at five why root cause analysis.

  1. Focus on the real problem
  2. Focus on actionable answers.
  3. Select answers that are in the team’s control.
  4. Take small steps.
  5. When in doubt, go and see.

Focus on the real problem

As we mentioned previously, each 5why activity you carry out must be focussed on two aspects. The problem itself (whats wrong), and the Escape (Where the wrong was identified).

There is a tendancy to confuse the two, or often overlap during the 5why investigation process.

Take for example a customer complaint that is raised, where a part has been received with no thread.

There are two issues that need to be resolved.

A) How was a part manufactured with no thread? (Problem)

B) How was a part with no thread allowed to work its way to the customer? (Escape)

Focus on the real issue for

PROBLEM: The incorrect condition of the service/product that results in it being considered non-conforming/incorrect

ESCAPE: The failure that occurred at the last point in the process that should have identified the incorrect condition before use.

Remember: Problems rarely occur as a result of a single root cause. Multiple issues are generally at play. Considering the Whys to both the problem and escape, will ensure not only that the specific incorrect condition will not occur again, but that mechanisms will be put in place to identify the same results or incorrect condition that may appear as a result of other root causes not currently understood.

Actionable Answers

Develop a habit of asking questions that lead to actionable answers. Instead of focusing on the problem we are having and the influences outside of our control, identify areas where your team can exercise control. Think of it like this: you can’t change the weather, but you can buy a raincoat. The opposite of an actionable answer would be a deflection to something outside of our control. Here is an example of an actionable “why” from an Epec problem-solving team.

PROBLEM: UPS no longer compatible with current label printers.

WHY 1? Equipment was not upgraded to match UPS 2015 program release.

Had the team answered the why by blaming UPS or the printer manufacturer, the team might have become frustrated and disbanded or they could have settled on an ineffective problem. Instead the determined that we needed a better service contract, so we do not repeat this problem.

Under The Team’s Control

People tend to externalise problems. With little evidence an untrained team is quick to exclaim “It’s the supplier’s fault!”, “It’s the customer’s fault”, “It’s the other department” and similar variations. Always take a serious look at problems under your control. When you find problems under your control, you can often solve them quickly. In addition, when you are quick to investigate and solve your own problems, this builds credibility outside of your team.

For example, when a problem is actionable, and it is equally likely to be your fault, as it is your supplier’s fault, first ask “why” about the part of the process under your control like in this example:

PROBLEM: Supplier shipped parts to us via Local Courier, causing late product delivery.

WHY 1? Miscommunication. = OK

Why 2 (A)? They did not read our email. = Bad

Why 2 (B)? We sent a long email with several important action items. This urgent request for next day air shipment was buried toward the end of the correspondence. = Good

When we see Five Why answers like 2 – Why? (A) above, we are suspicious for several reasons:

  1. Most likely this is an inference and not based on evidence.
  2. If the answer to the “why” is blame oriented, it is not actionable.
  3. It’ll take a while to validate any type of problem at a supplier facility.

However, if the problem-solving team discovers evidence that supports 2 – Why? (B), they can continue to evaluate their own communication practices.

Take Small Steps

Often the five why analysis goes wrong when the team takes a giant step with weak cause and effect relationship. This often occurs when team are sure of themselves and are eager to take action. Small incremental “why” responses help guide the team toward a strong root cause. Here is a real life example of a giant step setting the team off in the wrong direction:

PROBLEM: Production is using work instructions that are out of date.

1 – WHY? Operators do not have the ability to view online documents.

In this case, the team who made this five why had their mind made up early on. They really wanted to get the production computers onto the company network, so production operators could view their work instructions online. In their five why, the team skipped over explaining why management allows operators to use out of date work instructions. Many readers already recognize that the problem statement indicates an out of control condition where production builds with obsolete documents. This is not a document automation problem. This is a process control issue. The team did not question why obsolete documents were in use.

The team got their network drops, to address the “root cause” but it took several more years to get the process in control and have production operators regularly follow their work instructions.

Go And See

When using the five why approach, it is tempting to answer a “why” question with a belief, not a fact and to focus on people and not process. Working this way might seem satisfying because you can go through the whys quickly. The problem then becomes that your results are suspect. e.g.

PROBLEM: Production is using work instructions that are out of date.

1 – WHY? Operators aren’t looking at latest versions on server

The issue is focussed on people and not the process and this 5 why is not rooted in fact. Subsequently, his root cause is not actionable.

Because they’re lazy.”

Successful five why practitioners go to the place where thing happen. Their terminology for this is Gemba walk. When in doubt, go and see. Observe, ask questions, and gain insight. Focus on the process, not on people. Ask questions of the process to understand what really happens and what does not

A better way:

PROBLEM: Production is using work instructions that are out of date.

1 – WHY? Access on the shop floor to work instructions are limited

2 – WHY? Computers on shop floor are not connected to main server.

This enables real actions to be created and implemented to solve issues.

Are We Done Yet?

So how do we know when we have identified to the root cause? You will have reached the root cause when asking “why” produces no more useful responses. Let us illustrate with an example where by the 5th why, the team discovers that the design engineers cannot collaborate effectively:

This is a real-life example:

PROBLEM: Engineers cannot efficiently collaborate on SolidWorks design.

1 – WHY? No one has access to entire library of CAD designs or visibility of what others are working on.

2 – WHY? Engineers store CAD locally on their own computers, share via email.

3 – WHY? No shared CAD database that allows for collaboration and file management.

4 – WHY? Current engineering workgroup tools are not optimized for version control and document management.

5 – WHY? Our engineering workflow was not designed for multiple engineers to work from the same files.

6 – WHY? System previously only required one design engineer, who also happened to work on-site with production.

Notice that the 6th why describes what may be another problem in another part of the process but following this line of inquiry will not fix the problem described in the problem statement. The team went on to provide countermeasures for the root cause identified in the 5th why.

Root causes are underlying, are reasonably identifiable, can be controlled by management, and allow for generation of recommendations. Are you at the end? “If the most recent response were corrected, is it likely the problem would recur?” If the answer is yes, it is likely this is a contributing factor, not a root cause.

Knowing when to stop asking why mostly depends on three questions:

  1. How relevant are the questions and answers to the original problem you are investigating?
  2. Did you find a root cause that helps you control or avoid the problem?
  3. Are the questions and answers useful?

Parting Thoughts

The “five” in the Five Why Method is just a “rule of thumb.” In some instances, you may need to go on and ask “why?” a few more times before you get to the root of the problem. At other times, you may identify the root cause before you ask your fifth “why?”

Some teams – especially in manufacturing – do not bother to focus on finding the reason why the problem occurred, they search for the root cause of why the problem was not detected after it occurred. While this is often a valid part of a comprehensive improvement program, it’s not sufficient enough to merely improve detection methods. It is usually far more productive to focus on eliminating the cause of a problem, rather than focus on containment.

When you try to determine root cause through the five why method, remember to use these five rules:

  1. Focus on the real problem
  2. Focus on actionable answers.
  3. Select answers that are in the team’s control.
  4. Take small steps.
  5. When in doubt, go and see.

When you think that you found the root cause of your problem, ask these three questions:

  1. How relevant are the questions and answers to the original problem you are investigating?
  2. Did you find a root cause that helps you control or avoid the problem?
  3. Are the questions and answers useful?

Happy problem solving!!

What is the real cost of Quality?

Think about all the time you spend Managing your Compliance and Quality Requirements? From planning and conducting internal audits, to managing internal and external non-conformances,

Read More »