“Good judgment comes from experience and experience comes from poor judgment.” Will Rogers
Much is learned by observing the mistakes companies have made in doing FMEAs. Based on the experience of over 2,000 FMEAs and working with many companies in a wide variety of applications, certain common mistakes show up repeatedly. In this article, I’ll share ten common FMEA mistakes and how to convert them into quality objectives.
mistake
The Oxford English dictionary defines “mistake” as “an action or an opinion that is not correct, or that produces a result that you did not want.”
What are FMEA quality objectives?
Each of the common FMEA mistakes can be converted into corresponding quality objectives. For example, the first mistake is “failure to drive product or process improvements.” Rewording this mistake as a quality objective, it becomes “The FMEA drives design improvements (design FMEA) or manufacturing or assembly process improvements (process FMEA) as the primary objective.”
Mistake No. 1: design/process improvements
A review of FMEA applications across industries shows some FMEAs drive ineffective actions or no action at all. Some design FMEAs drive mostly testing, while some process FMEAs drive mostly controls. Failure of the FMEA to drive product or process improvements is mistake No. 1.
Quality Objective # 1
The FMEA drives product design or process improvements as the primary objective
Mistake No. 2: high-risk failure modes
Although organizations define risk using different criteria, failure to address all high-risk failure modes can result in potentially catastrophic problems or lower customer satisfaction. Failure of the FMEA to address all high-risk failure modes is mistake No. 2.
Quality Objective # 2
The FMEA addresses all high-risk failure modes with effective and executable action plans.
Mistake No. 3: design verification or process control plans
Some organizations miss the opportunity to improve their design verification plan (DVP) or process control plan (PCP) based on the failure modes or causes from the FMEA. The result is inadequate product testing or PCPs. Failure of the FMEA to improve test and control plans is mistake No. 3.
Quality Objective # 3
The Design Verification Plan (DVP) or the Process Control Plan (PCP) considers the failure modes from the FMEA.
Mistake No. 4: interfaces
Empirical data show at least 50% of field problems can occur at interfaces between parts and subsystems or between the system and environment. Similarly, many manufacturing or assembly problems occur at the interface between operations or beyond operations, such as while transporting materials, receiving incoming parts or shipping. Some practitioners miss these interfaces. Not including interfaces in design or process FMEAs is mistake No. 4.
Quality Objective # 4
The FMEA scope includes integration and interface failure modes in both block diagram and analysis.
Mistake No. 5: lessons learned
Some organizations do not provide links between FMEAs and field data (in design FMEAs) or manufacturing data (in process FMEAs). It takes concerted effort to integrate problem resolution databases with the FMEA. A lack of integration can cause serious problems to be repeated. Disconnect between the FMEA and information from the field or plant is mistake No. 5.
Quality Objective # 5
The FMEA considers all major “lessons learned” (such as high warranty, campaigns, etc.) as input to Failure Mode identification.
Mistake No. 6: level of detail
Some FMEAs are too detailed in their analysis, which makes it difficult to focus on areas of higher risk. Some FMEAs aren’t detailed enough, which makes it difficult to determine the root cause and effective corrective actions. Having the wrong level of detail in the analysis is mistake No. 6.
Quality Objective # 6
The FMEA provides the correct level of detail in order to get to root causes and effective actions.
Mistake No. 7: timing
Many organizations conduct FMEAs late, and this reduces their effectiveness. FMEAs should be completed according to design or process freeze dates in line with the product development process. Performing FMEAs late is mistake No. 7.
Quality Objective # 7
The FMEA is completed during the “window of opportunity” whence it can most effectively influence the product or process design.
Mistake No. 8: team
Some FMEA teams do not have the right experts on their core teams. Some FMEA team members just sit in their chairs if they show up at all and don’t contribute to team synergy. FMEAs having inadequate team composition and participation is mistake No. 8.
Quality Objective # 8
The right people, adequately trained in the procedure, participate on the FMEA team throughout the analysis.
Mistake No. 9: documentation
There are hundreds of ways to do FMEAs wrong. Some organizations do not encourage or control proper FMEA methods. Or they copy old FMEAs and don’t adequately address changes, such as new technology or new applications. Training, coaching and reviews are necessary for success. Use of improper FMEA procedures is mistake No. 9.
Quality Objective # 9
The FMEA document is completed “by the book,” including “Action Taken” and final risk assessment.
Mistake No. 10: value of time spent
Some organizations mandate FMEAs, but that doesn’t ensure the time spent on them is productive. Pre-work must be completed, meetings must be productive and high-risk issues must be resolved. Ask the FMEA team whether their time was well spent, and take action to address shortcomings. Inefficient use of time is mistake No. 10.
Quality Objective # 10
Time spent by the FMEA team is an effective and efficient use of time with a value added result.
FMEA Tip
FMEA Quality Objectives should be integrated into FMEA team training and reviewed at each stage of FMEA project completion. It is suggested that FMEAs not be considered complete until the quality objectives have been met.
Summary
We can learn from common mistakes and avoid them in future FMEAs. By converting the most common mistakes into quality objectives, FMEAs can help achieve safe and highly reliable products and processes.
Reader Question
“The important thing is not to stop questioning.” – Albert Einstein
A question about occurrence and detection: How are they linked, or not linked? To detect a cause or failure mode a test was performed with a high quality on detection. From the test results, the engineers claim that the occurrence must be much lower than initially ranked. However, there were no proper prevention measures taken. I allowed it because there was evidence that the occurrence must be low.
I am faced with this a couple of times when ranking occurrence. The low occurrence ranking is based on a preventive measure taken, along with test evidence that the occurrence must be low. Of course the test quality (I see this as the detection ranking) must be good enough, let say 3 or less. What are your thoughts?
My Reply
Regarding linkage of occurrence and detection, I’ll begin with excerpts from SAE J1739 2009.
“The occurrence ranking number has a relative meaning rather than an absolute value and is determined without regard to severity or detection.”
“Detection is a relative ranking, within the scope of the FMEA, and is determined without regard to severity or occurrence.”
The essence of my answer to your question about occurrence-detection linkage has to do with the timing of FMEAs, and the process of updating an FMEA. Ideally, Design FMEAs are completed before testing begins. The reason for this has to do with the primary objective of the FMEA, which is to improve the product design. Another objective of a Design FMEA is to identify test deficiencies and recommend modifications to the tests before testing commences. The earlier the design is modified the lower the cost and timing impact of product development. And, of course, test improvements should be made before testing begins.
Having said that, FMEAs are often updated with subsequent test and field data. In the case of test or field information that indicates a different value for the occurrence ranking, the occurrence value can be updated. The same is true for detection risk. Modified tests can provide an update to the detection-type controls and a corresponding update to the detection ranking. However, before updating, I would suggest making a record of the original FMEA to document the due care in product development.
Next Article
The theme of the next article is “Using FMEA quality objectives to audit FMEAs.” In this article we’ll show how to record and evaluate the progress in meeting the quality objectives in your FMEA.
Thanks Fred.
As always, concise and helpful.
Mark