Getting to Root Cause with “Five Whys”
There is no more important task in an FMEA than correctly identifying the “Cause.” Finding the root cause is the heart and soul of FMEA procedure. When you have the right cause, it opens the door to solutions. When you have the wrong cause, nothing gets accomplished.
By continuing to ask “why,” the team will be able to discover the progression of cause-and-effect relationships behind a problem and the root cause that is below the surface.
Wisdom begins in wonder – Socrates
why
The Oxford English dictionary defines “why” as “a reason or explanation.” Origin: Old English “by what cause.”
Recall the definition of “Cause” in FMEA
If you haven’t read the “Inside FMEA” article on Understanding FMEA Causes, this would be a good time to read the article.
A “cause” is the specific reason for the failure, preferably found by asking “why” until the root cause is determined. For Design FMEAs, the cause is the potential design deficiency that results in the failure mode. For Process FMEAs, the cause is the manufacturing or assembly deficiency (or source of variation) that results in the failure mode.
What are “five whys” and how are they used?
Many practitioners use repeated questioning of the FMEA team to ensure that the basic “why” is determined as the cause of a failure mode. This technique, called the Five Whys, can be very helpful, especially when the root cause is not forthcoming. The Five Whys is a technique developed by Taiichi Ohno, originator of the Toyota Production System. It means that by asking “why” five times, the team will be able to discover the progression of cause-and-effect relationships behind a problem and the root cause that is below the surface.
Rationale for “five whys”
Identifying the right “cause” in an FMEA is one of the most important concepts in effective FMEAs. It is impossible to over-stress the importance of fully analyzing and understanding the cause. A half-analyzed cause has little value, as the cause is the heart and soul of the FMEA. Take the example of a projector lamp shattering. If the FMEA team simply describes the cause as “over pressure” and does not ask why the over pressure, the root cause of “wrong gas” is not established. The team will end up trying to solve “over pressure,” and may miss recommending the correct gas specification. The problem will not be solved.
For high-risk issues, it is essential that root cause be identified. “Five whys” is a useful technique to help ensure the FMEA team achieves root cause.
FMEA Tip
Tip: When the FMEA team first identifies the cause of a failure mode (call it Cause A), it is useful to ask why the cause occurred. If there is a meaningful answer, then Cause A is not the root cause, and the team should continue asking “why” until root cause is determined.
Progression of failure mode and cause from system to subsystem to component
Appropriate failure mode and cause descriptions depend on the type of FMEA being performed: in some cases, the cause in a System FMEA will be the failure mode in the Subsystem or Component FMEA. The following excerpts from of a bicycle system FMEA, a hand brake subsystem FMEA and a brake cable FMEA will illustrate this concept. This excerpt is from chapter 3 of Effective FMEAs.
Failure Mode and Cause progression
The FMEA team needs to be aware at what level of the system hierarchy (system, subsystem, and component) the FMEA is being done. Remember, it is always necessary to get to root cause (and associated failure mechanism) for higher-risk failure modes. In this example, the FMEA team can use the Recommended Actions column of the hand brake subsystem FMEA to require a design FMEA on the brake cable, in order to get to root cause.
Excerpt from bicycle hand brake Design FMEA
In the Hand Brake Subsystem DFMEA, “cable breaks” is not a root cause. The FMEA team recommends “Require cable DFMEA and PFMEA from cable supplier . . .” in order to get to root cause.
“Corrosion of cable wiring due to wrong material selected” and “Fatigue cracks in cable wiring due to inadequate cable thickness” are root causes. The FMEA team can use techniques such as “five whys” to help ensure root cause is obtained.
Problem
An FMEA team is performing a Design FMEA on a projector lamp. They identify “lamp shatters” as one of the failure modes, and “pressure too high” as one of the causes. Is “pressure too high” a root cause? If not, how can the team use “five whys” to ensure root cause is obtained?
Solution
In this example, since the team can ask, “Why is the pressure too high” (and get a meaningful answer), they have not yet achieved root cause. By continuing to ask “why”, the team can follow the answers to discover the root cause: “over pressure in lamp due to wrong gas.”
FMEA Question
The important thing is not to stop questioning. – Albert Einstein
Reader:
With regard to System FMEAs, I would expect these to be done early in a project, and at a high level in the system’s hierarchy, meaning that the design elements being analyzed are going to be the main sub-systems and assemblies that will make up the product. Scoring the Severity seems straight forward, but scoring the Occurrence and the Detection seems a bit more problematic at the System FMEA level because one may not have any useful information about those metrics.
Do you find that you can apply the usual scoring scales for O and D at the system level, or do you handle these metrics in some other way for the System FMEA?
Carl:
It is often challenging to assess occurrence and detection for system FMEAs, as they occur early in the product development process, and objective data may or may not yet be available. There are ways to help with this assessment. First is good preparation, which includes having objective field-failure data on similar systems. It’s not perfect, as system configurations change, but it is helpful input to the discussion. Second is having the right team of subject matter experts in the room. They can be asked subjectively for their input to the likelihood of occurrence of the failure mode / cause. Third is having representation from the testing department on the team. This helps with the detection assessment, as to how well the currently planned testing or analysis methods can detect the failure mode / cause.
Next Article
FMEAs take time and cost money. They should be done when a certain level of risk can be effectively addressed by the FMEA procedure. The next article presents a tool called “Preliminary Risk Assessment,” which can be used to prioritize potential FMEA projects.
Ask a question about FMEA
In the words of Albert Einstein, “The important thing is never to stop questioning.” I invite you to ask anything at all about the broad subject of FMEAs. You may be curious about an application issue, or want another view on a challenge you are experiencing. Questions and answers are the lifeblood of learning, and we’re are all learning. I will answer all questions to the best of my ability, and promise to keep personal information confidential.
Leave a Reply