<<< Back to Index
This Month's Article >>>

FMEA Corner 
This Month's Theme is Using FMEA quality objectives to audit FMEAs
Next month's theme will be parameter diagrams

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.

 

 

 
qual·i·ty [kwol-i-tee, noun]
The Oxford English Dictionary defines "quality" as "the standard of something as measured against other things of a similar kind; the degree of excellence of something."

 
ob·ject·tive [uh b-jek-tiv, adjective]
The Oxford English Dictionary defines "objective" as "a thing aimed at or sought; a goal."


 

What are FMEA quality objectives?

Building from the above definitions, FMEA quality objectives are specific goals or aims that measure the degree of excellence of an FMEA.

How to audit FMEAs using FMEA quality objectives

In last month’s FMEA Corner, ten common FMEA mistakes were identified, along with the associated quality objectives. In this article, suggestions for how to audit each of the quality objectives are included, as well as application tips.

Mistake No. 1: Design/Process Improvements

A review of FMEA applications across industries shows that some FMEAs drive ineffective actions or no action at all. Some design FMEAs drive mostly testing, while some process FMEAs drive mostly controls. FMEA’s failure to drive product or process improvements is mistake No. 1.

FMEA quality objective No. 1: The FMEA drives design improvements (design FMEA) or manufacturing or assembly process improvements (process FMEA) as the primary objective.

FMEA application comment: The quality and reliability fields have many tools to choose from in driving design or process improvements. The key is using the recommended actions worksheet column of the FMEA to identify and execute tools that can optimize designs and processes. This is one of the reasons quality or reliability engineers should participate in FMEAs.

How to audit: Review the FMEA recommended actions and observe whether most of them drive design improvements (for a system or design FMEA) or process improvements (for a process FMEA). Talk with team members to ensure their focus was on improving the design or process.

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 FMEA to address all high-risk failure modes is mistake No. 2.

FMEA quality objective No. 2: The FMEA addresses all high-risk failure modes, with effective and executable action plans.

FMEA application comment: The team first addresses all high-severity issues, regardless of risk priority number (RPN). After high-severity issues are addressed, the team can prioritize and address high-RPN issues (or high severity x occurrence if severity and occurrence are used rather than RPN). The key is effective actions that reduce or eliminate risk. Most high-risk problems require multiple corrective actions.

How to audit: Review high-severity and high-RPN issues to determine whether the corresponding recommended actions are adequate to reduce risk to an acceptable level. Talk with the team members to ensure they are satisfied that all high risks were addressed and no important concerns were left unaddressed.

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.

FMEA quality objective No. 3: The DVP considers the failure modes from the design FMEA. The PCP considers the failure modes from the process FMEA.

FMEA application comment: The FMEA team will often discover failure modes/causes not adequately addressed in current test plans/procedures or not included in the PCPs. The key is to ensure the DVP or the PCP is impacted by the results of the FMEA. This is best accomplished by including test/control membership on the FMEA team and through well-written actions.

How to audit: Review the recommended actions to determine whether there are improvements to the DVPs, PCPs or corresponding procedures based on risk associated with current design or process controls. Talk with the team members to determine whether they had adequate representation from test or controls groups, benefited from their input, and whether test and control procedures were improved.

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.

FMEA quality objective No. 4: The scope of the design FMEA includes interface failure modes in both FMEA block diagram and analysis. The scope of the process FMEA includes inter-operation failure modes, such as transfer devices, incoming parts and shipping, in both process flow diagram and analysis.

FMEA application comment: Product design interfaces can include physical connections, material exchanges, energy transfers or data exchanges. The FMEA block diagram should clearly show the interfaces that are part of the design FMEA scope. Similarly, the process flow diagram should show inter-operation connections and exchanges, such as with materials transport, receipt of incoming parts and shipping.

How to audit: Review items, functions, failure modes and other portions of the FMEA to ensure interface issues were addressed within the design FMEA scope. Ensure connections and exchanges between operations were addressed within the process FMEA scope. Review the FMEA block diagram and process flow diagram to verify. Ask the team how it determined that no interface issues were missed.

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.

FMEA quality objective No. 5: The FMEA considers all major lessons learned (from in-service warranties, customer service databases, recall campaigns, prior manufacturing or assembly problems, etc.) as inputs to failure mode identification.

FMEA application comment: Field and manufacturing failure databases often have noise. Effort is needed to filter the correct input information to FMEAs. New FMEAs should be seeded with potential field and manufacturing problems, and should show how the problems will be avoided in the new or modified design or process. Hold FMEA teams accountable to ensure known problems are not repeated.

How to audit: Review failure modes and causes to ensure they contain supplemental field failure data (for system and design FMEAs) and manufacturing failure data (for process FMEAs). Talk with the FMEA team to ensure the FMEA benefited from lessons learned and that high-risk issues will not recur.

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.

FMEA quality objective No. 6: The FMEA provides the correct level of detail to get to root causes and effective actions.

FMEA application comment: Good FMEA facilitation keeps a team focused on areas of risk that lead to root causes and effective corrective actions. FMEA discussions should be focused around areas of concern noted by at least one member of a properly constituted FMEA team. Avoid lengthy discussions about low-risk issues. The higher the risk, the more in-depth the discussion should be. Low-risk issues should receive less, but appropriate, discussion.

How to audit: Verify that the level of detail on high-risk issues is adequate to fully understand root causes and develop effective corrective actions. Review the different worksheet columns of the FMEA to ensure the overall level of detail is proper and adequate. Too much detail may appear in the form of endless pages of FMEAs covering issues no one on the team is concerned about. Too little detail shows up as under-defined functions, failure modes, effects, causes or controls, or as areas of unaddressed concern from one or more FMEA team members. Talk with the FMEA team members to determine how they addressed the level of detail and ensured all concerns were included in the scope of the FMEA project.

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.

FMEA quality objective No. 7: The FMEA is completed during the window of opportunity from where it can most effectively affect the product design or manufacturing process.

FMEA application comment: The key to completing FMEAs on time is to start the FMEAs on time. Design or process FMEAs should begin soon after the design or process concept is determined and be completed before design or process freeze dates. Starting and completing FMEAs on schedule requires proactive management support throughout the FMEA process.

How to audit: Review the timing of the FMEA against the product development process timeline. Verify the FMEA was started and completed in the proper timeframe to maximize the value of the FMEA results.

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.

FMEA quality objective No. 8: The right people, adequately trained in the procedure, participate on the FMEA team throughout the analysis.

FMEA application comment: People have blind spots. A well-defined, cross-functional team minimizes errors due to blind spots. FMEA analysis requires SMEs from a variety of disciplines to ensure all necessary inputs are incorporated into the exercise. The cross-talk and synergy among SMEs that occurs during FMEA meetings is essential, because well-defined groups can discover what individuals miss. Attendance is influenced by management support.

How to audit: Review the FMEA team member roster to ensure there was adequate representation from the various disciplines based on the type of FMEA and the project scope. Check FMEA team meeting records to ensure attendance was adequate at each meeting. Talk with individual team members to learn whether their input was elicited in decisions.

Mistake No. 9: Documentation

There are hundreds of ways to do FMEAs wrong. Some organizations do not encourage or control proper FMEA methods. In other cases, 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.

FMEA quality objective No. 9: The FMEA document is completely filled out by the book, including action taken and final risk assessment.

FMEA application comment: The FMEA team must have a solid understanding of FMEA fundamentals, definitions and concepts. There is no substitute for properly applying FMEA fundamentals. This is a broad quality objective to ensure the FMEA worksheet is filled out completely and properly.

How to audit: Verify that the FMEA worksheet columns were correctly filled out and that the FMEA procedure was properly followed. Talk with the FMEA team members to ensure they rigorously followed FMEA guidelines and practices.

Mistake No. 10: Time Use

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.

FMEA quality objective No. 10: Time spent by members of the FMEA team is an effective and efficient use of time with a value-added result.

FMEA application comment: If this quality objective is met, future FMEA meetings will be well attended and supported by SMEs and management. Conversely, if subject matter expert time is wasted, it will be difficult to generate attendance at future meetings.

How to audit: Talk with the FMEA team to learn whether each member believes his or her time was well spent and whether a value-added result was achieved. If not, find out why.

How are FMEA quality audits conducted?

The following is excerpted from the book, Effective FMEAs.

In a nutshell, an FMEA subject matter expert or management person reviews the FMEA results with the FMEA team against each of the FMEA Quality Objectives, one by one, using the "How to audit" recommendation. Each quality objective is evaluated for how well it is achieved. This evaluation can be done on a yes/no basis or a variable evaluation, such as high, medium or low. The estimated time is one hour for this audit, about 5 minutes per FMEA Quality Objective. The results of the audit provide valuable feedback to improve future FMEAs. The focus is on improving the FMEA process, not on the person or team doing the FMEA. The auditor is looking for specific process-related issues that underlie deficiencies in achieving the quality objectives, such as lack of training, procedure, facilitation skills, standards, resources, support, etc. Action items from the FMEA quality audit should be documented and pursued to improve the overall FMEA process. Do not expect to achieve all ten FMEA quality objectives instantly. Rather, work to maintain steady improvement.

Summarizing FMEA quality audits in Xfmea

Xfmea has a tab in the Analysis Plan to record the results of an FMEA quality audit or team assessment.

In the Xfmea system hierarchy, select the item that is being evaluated and choose Analyses > Planning > Add Analysis Plan.

In the Analysis Plan window, click the Quality Survey tab. You can then use one of the surveys in the library or create your own survey and save it in the library, as in the following example. The form can be used to document the results of an FMEA quality audit or a self-assessment of the FMEA quality objectives by the FMEA team.

Analysis Plan

!FMEA Tip of the Month

The best use of FMEA quality audits is to improve the FMEA process, not to correct the FMEA team.

?Something I’ve always wanted to know about FMEAs
The important thing is not to stop questioning. - Albert Einstein

A HotWire 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.

I have a question about best practice for traceability of a Design FMEA to Design Requirements. For complex products with many design requirements at multiple system levels, is it preferred to list all requirements in the DFMEA(s) with failure modes corresponding to not meeting each requirement, or to perform "functional" DFMEA from block diagrams for subsystems, modules, etc. and then trace the functional failure modes back to the design requirements?

With the former approach, there are very large number of rows to individually evaluate for risk; with the latter approach, there will often be sets of unitary requirements that trace to one "functional" failure mode from the block diagram. It can be tedious going back and forth between a requirements database and the DFMEA to ensure that all essential requirements are associated with a given failure mode while not including requirements haphazardly that aren’t pertinent. If the risk level is high for a particular failure mode, then all the requirements traced to it become "essential" according to our procedures and require special rigor in verification/validation.

So, is there a "preferred" process most often followed for this in high-tech industries with complex designs?

Carl: Thanks for getting in touch with me on this important question.

In order to reply to this question, I'll discuss my preferred method. Since your example talks about a complex product, I'll assume we are talking about a System FMEA. I prefer to begin a System FMEA with an FMEA block diagram that identifies and visually represents the exact scope of the System FMEA, including all interfaces and integration areas. The FMEA is then populated with the primary functions of the system, as well as the interfaces brought into the analysis as interface functions. By definition, each function should include the "standard of performance," which can be highlighted by corresponding requirements. Some companies include a "Requirements" field that is associated with the corresponding function. Each function has associated failure modes, and the FMEA is continued in this manner. This way you can trace each failure mode to corresponding functions and requirements.

You are correct that it is important to trace the requirements from the source of requirements to the associated function (and requirements) in the System FMEA, while excluding from the FMEA the requirements that are not pertinent to the analysis.


About the Author

Carl S. CarlsonCarl 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.

Effective FMEAsMaterial 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.

 
ReliaSoft