Every month in FMEA Corner, join Carl Carlson, a noted expert in the field of FMEAs and facilitation, as he addresses a different FMEA theme (based on his book Effective FMEAs) and also answers your questions.
Questions and answers are a great way to learn about FMEAs, for both experienced and less experienced FMEA practitioners. Please feel free to ask any question about any aspect of FMEAs. Send your questions to Carl.Carlson@EffectiveFMEAs.com, and your contact information will be kept anonymous. All questions will be answered, even if they are not featured in the FMEA Corner.
why [hwai, adverb]
The Oxford English Dictionary defines "why" as " a reason or explanation." Origin: Old English "by what cause."
What is Five Whys and how is it used?
Wisdom begins in wonder - Socrates
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 overstress 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 occurs, 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 of the Month
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 FMEA and a brake cable component FMEA will illustrate this concept.
The FMEA team needs to be aware of 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 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.
This progression is further illustrated in Xfmea:
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.
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? [Show/Hide Answer]
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."
Answer: Paste answer here.
I’ve always wanted to know about FMEAs
The important thing is not to stop questioning. - Albert Einstein
A reader submitted the following question to Carl Carlson. To submit your own question about any aspect of FMEA theory or application, e-mail Carl at Carl.Carlson@EffectiveFMEAs.com.
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 regarding 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.
I do use the scales for O and D on system FMEAs.
I hope that those tips are helpful.
About the Author
Carl S. Carlson is a consultant and instructor in the areas of FMEA, reliability program planning and other reliability engineering disciplines. He has 30 years of experience in reliability testing, engineering and management positions, and is currently supporting clients of ReliaSoft Corporation with reliability and FMEA training and consulting. Previous to ReliaSoft, he worked at General Motors, most recently senior manager for the Advanced Reliability Group. His responsibilities included FMEAs for North American operations, developing and implementing advanced reliability methods and managing teams of reliability engineers. Previous to General Motors, he worked as a Research and Development Engineer for Litton Systems, Inertial Navigation Division. Mr. Carlson co-chaired the cross-industry team that developed the commercial FMEA standard (SAE J1739, 2002 version), participated in the development of SAE JA 1000/1 Reliability Program Standard Implementation Guide, served for five years as Vice Chair for the SAE's G-11 Reliability Division and was a four-year member of the Reliability and Maintainability Symposium (RAMS) Advisory Board. He holds a B.S. in Mechanical Engineering from the University of Michigan and completed the 2-course Reliability Engineering sequence from the University of Maryland's Masters in Reliability Engineering program. He is a Senior Member of ASQ and a Certified Reliability Engineer.
Material for the FMEA tips, problems and solutions is excerpted from the book Effective FMEAs, published by John Wiley & Sons, ©2012. Information about the book Effective FMEAs, along with useful FMEA aids, links and checklists can be found on www.effectivefmeas.com.