Root cause analysis is a technique performed to identify the underlying reasons why a particular problem is occurring. At Epec, we do a lot of problem solving. As manufacturers, we strive to discover better, more efficient ways to delight our customers. Whether we are working on an 8D CAPA or running an A3 Project, we are often working to determine the foundational cause of issues as the means to solving the problem.
5 Why Analysis
The 5 why technique has become our go-to method for determining root cause analysis. It is simple, and with practice, it quickly gets you to the source of the problem. To some, the 5 Why is intimidating.
Working in the prolific problem-solving environment that is Epec production provides many opportunities to see why newcomers struggle with this method of structured problem solving. For one, there is little practical advice on how to ask a good “why?”, nor is there much advice on how to answer the “why?” in a productive manner. But with practice, maybe several dozen attempts, some folks begin to master the 5 why.
Using 5 Whys helps discover the root cause of a problem
Recently I have discovered some powerful advice about root cause analysis: start with a good problem statement. With a good problem statement, we focus our team with the issue that needs attention.
The Problem Statement
A problem is merely the difference between the way things are and the way things need to be. The difficulty in writing a good problem statement often stems from knowing too much. When we know too much about the problem, this hampers our ability to write a clear and concise problem statement.
Often, by the time we write the problem statement, we know a lot about the cause of the problem. We also know consequences of the problem, the customer/coworkers reaction to the problem, the need to resolve it promptly. We have probably also given thought as to a few viable solutions to the problem. When these thoughts about how the problem occurred or how we can solve the problem seep in to the problem statement, it skews our description of the problem. When one writes skewed or cloudy problem statements, the reader struggles to understand the problem. When the reader struggles to understand the problem, it is difficult to convince them to take appropriate action.
Consider these two problem statements below. There are real reports of problems that need attention. Neither example, however, states the problem directly. Both examples beg the question and infer a solution. This approach handicaps our problem-solving efforts.
“Workers are making mistakes because there is no work instruction.”
“We need to perform 5S at the production work cells.”
Let's take the first example above. Let us assume that the problem statement author observed a product yield problem at final test. Also evident was that assemblers were not using work instructions. The problem solving team goes out to gemba walk to research the problem. With a little digging, they find that indeed there is a work instruction. However, no one uses it. The team reports back, “There is no problem, we found a work instruction, and told everyone to use it.”
Not so fast. In this example, the better problem statement would be “Excessive fallout at final test causes excess rework and late shipments”. This is a better problem statement. But it requires focus on the problem itself, a gemba walk, and communication with the team to understand the problem. No matter what potential remedies the team discovers as they dig for root cause, this problem statement remains objective and unchanged.
A good problem statement has these features:
- It describes the difference between the actual conditions and the desired conditions.
- It does not offer commentary on a proposed solution.
- It does not attempt to diagnose the problem, nor assign blame.
- It is objective and factual.
A great problem statement goes even further:
- It ties to company goals.
- It is measureable, not qualitative.
Summary
When starting your A3, CAPA, or 8D, spend your time constructing a good, clear problem statement. Focus your problem statement on the actual problem: be objective and factual. Withhold whatever else you believe to know about the problem source. Do not use the problem statement to propose a solution.
These additions to the problem statement only serve to distract from the problem. Write a clear, concise problem statement and you will reward yourself with a problem-solving team that speeds to a great solution.
