Data analysis is one of the best ways to validate a y=f(x) assumption, but teams who are familiar with processes can often arrive at some basic relationships through a process known as the 5 Whys. This is a brainstorming tool that asks increasingly granular why questions about a problem or process, seeking to understand the root cause or actual problem. The 5 Whys can be used to define a problem or to begin seeking causes.
For example, consider the hamburger example above. Teams addressing a problem of customer satisfaction might begin doing so because feedback forms have shown a lower-than-normal satisfaction with food quality over the past week.
The team first asks: Why are customers dissatisfied with the food?
Looking at feedback tied to orders, the team notes that the customers who are rating the food poorly are mostly customers who ordered hamburgers of some type. The answer to the first question is that the customers are dissatisfied with the food because they are dissatisfied with the hamburgers.
Why are customers dissatisfied with hamburgers?
The team looks at written feedback on forms or speaks with customers directly and discovers that many customers feel that their hamburgers were undercooked. The new answer is that customers are dissatisfied with hamburgers because the meat is undercooked.
Why is the meat undercooked?
An investigation into the kitchen reveals that the grill is not properly calibrated and is providing inconsistent results. At this point, you have the y=f(x) relationship, but the team could keep asking questions.
Why is the grill not properly calibrated?
Further investigation shows that the morning shift, responsible for calibrating the grill, has a new grill cook. During training, education on performing this function was omitted. The grill is not properly calibrated because the employee responsible was not properly trained. Now the team has a specific cause and a solution: train the grill cook.
In a Six Sigma environment, the team might move on with one more question: Why was the grill cook not properly trained? This might lead to the development of a consistent training policy so the problem doesn’t occur the next time a new grill cook is hired.
In the hamburger example, it only took four why questions to get to the root of the problem, and a fifth question started pointing to controls or long-term solutions. It isn’t always this easy; the tool is called the 5 Whys because it often leads to answers within five questions. However, teams could ask a dozen questions if they begin at a very high level and work down through a complex process.
When to Use 5 Whys?
One benefit of 5 Whys is that it only costs your team a small amount of time to use—a team familiar with a process can conduct a complete 5 Whys session in less than an hour if a moderator keeps things on task. Because of its simplicity, the 5 Whys tool can be used for almost any problem. Use it to address a problem team members bring up, to address a problem a supervisor noticed, or to address the vague feeling that there is a problem when no one has been able to define what is actually wrong. At the very least, a 5 Whys session facilitates communication and thought.
In a Six Sigma project environment, 5 Whys is usually deployed when processes involve human interactions or people-powered inputs, though it can be an effective start to brainstorming on any process.
How to Conduct 5 Whys Session?
Since a 5 Whys session is usually based on input from subject-matter-experts, gather people who are close to the process. On a white board or web conference screen, display a basic problem statement as you understand it. This problem statement is not going to be detailed like the statements we’ll discuss in the next session—a 5 Whys session is often one of the tools you use to get to that detailed statement.
Examples of statements you might see in a 5 Whys station include:
- Customers are not happy with the selection of produce
- Customers are receiving orders late
- The printing process is resulting in too many defects
- Lead times on the bottling process are excessive
- Employees are not happy with vacation schedules
These are all fairly general statements that simply say something about defects or dissatisfaction. Begin by asking the highest-level “Why?” question possible about the statement. “Why are employees not happy with vacation schedules?” Write this question down.
The team works together to provide a high level answer to the question. Employees are not happy with vacation schedules because it’s rare to get the exact time off requested. Write the answer down under the question, then create the highest-level “Why?” question you can about the new answer.
“Why are employees not getting their first choice time off for vacation?” Perhaps the answer is that supervisors take so long to approve vacation requests that other employees have also asked off for the same time, so it’s hard for supervisors to accommodate everyone.
The next question is “Why are supervisors taking too long to approve requests?” The answer might be that the time-off system is too cumbersome, so supervisors put off approvals until they have a lot of time to manage them.
“Why do supervisors see the system as cumbersome?” Because there are wait times when moving from screen to screen and each approval requires a vast number of clicks and entries.
Now, the team has a root cause: the system itself is inefficient, which leads to problems down the line. If the team can correct the programming issues and encourage supervisors to approve vacation requests faster, employee morale can be improved.