"Can a failure mode and cause of failure be interchanged in FMEA?"
I belong to several groups on the Linked In web site and find many of the group discussions to be both interesting and informative. A member of the American Society for Quality (ASQ) group recently posted the following:
The Failure Mode would be “Porosity – Excessive." One of the Effects could be “Joint fails strength test” (or something like that). A Potential Cause could be excessive voltage.
You could also have the Failure Mode as “Excessive voltage” with one of the Effects being “Excessive porosity”. Now your Potential Causes would deal with the reasons there is excessive voltage present. Can the Mode of failure and Cause of failure be interchanged? If so then it gives a different perspective in making an FMEA.
His post generated several responses from other group members, and some of those responses were either incorrect or very confused. Examples:
- They can definitely be interchanged. However the order of steps in the process would define if the interchangeability applies or not; I believe visibility of the process is necessary to put everything in context.
- I have always looked at the effect in terms of what would happen if the failure occurred. For example, the failure mode could be that the brakes in a car failed to engage because the brake line system leaked. One of the effects of that is a car crash. If you do not focus upon the effect of the failure or defect, you will not get an appropriate/relevant RPN, due to the fact that you cannot effectively rate the severity of the failure.
- In causal analysis "cause" and "effect" labels change as you build the case. Porosity being the effect of the amount of voltage turns into the cause of mechanical failure. So don't sweat about picking one label.
“They can definitely be interchanged?”...” Don’t sweat about picking one label?” Comments like these on the ASQ group site sometimes drive me crazy. If one is combining failure modes, effects, and causes, it can only lead to confusion, wasted time and improper analysis. Finally, a comment was posted that got to the meat of the matter:
If you have the same phrase repeating in different columns within the same FMEA level, then your thoughts are "bouncing around" and the team needs to clarify its FMEA scope!
I followed that post by writing, “I agree with the previous post. It all has to begin with a clear definition of scope. For example, in Design FMEA, is your scope at a system level, sub-system, assembly, sub-assembly, part or component? The cause of failure at one level will be the failure mode at the next lower level; and the effect of failure at one level will be the failure mode at the next higher level. If you don't agree on your scope at the outset and stick to it, a lot of wasted time and confusion will result.”
If FMEA project teams clearly define and agree on the scope of their analysis prior to getting into the details, they will know if they start to get off track. The most common warning signal occurs early in the analysis when the team is listing failure modes. How many times have you heard the question, “Is that a failure mode or a cause?”
As soon as you hear that question, back off and re-visit your scope. Nine times out of ten you’ll find that the team has narrowed its scope to a part or component level from the previously-agreed-upon assembly or systems level. Or, in Process FMEA, they moved to a particular step in the process instead of the original scope of a stage of the process or the overall process.
To return to the original question, failure modes and causes of failure should never be “interchanged.” Doing so will lead the team to non-productive, time-wasting tangents and delays in the project. Teams will avoid the tangents and delays if they clearly define their scope at the outset of the current round of FMEA – and stick to it!
© 2016 James F. Leonard. All rights reserved.