Failure mode and effects analysis, or FMEA, is a tool for the identification and prioritization of possible ways a product or process can fail. The intent is to use that information to make improvements to the product or process.
I think of FMEA (and related processes like FMECA, dFMEA, etc.) as structured brainstorms that provide a means to focus on what’s important.
The basic structure and process for the conduct of an FMEA are best (and very concisely) described in The Basics of FMEA by McDermott, et. al. They cover the preliminary work to prepare for the study and the mechanics of conducting a study. Brainstorm failure modes and causes, list effects of those failure modes, and list means in place to detect the presence of the causes (or elements that lead to the cause). Assign scores for the severity of the effect, occurrence (probability) of the cause and effectiveness of the detection mechanism and calculate the risk priority number, RPN. The highest RPN is the most likely most severe consequence and least detectable, thus important to design out of the product or process.
Some teams use the rule that any item with a severity of 9 or 10 (if it occurs the effect would cause harm to people or cause significant damage to assets) has to be resolved.
Some use scoring on an 1 to 5 or 1 to 10 scale, some use fixed scoring scales, other don’t. Some detail every part of the bill of materials and every attachment or joint, sone focus on the high priority or highest overall risk areas. Nearly all struggle to get value from the exercise.
That is about the time to study the new book by Carl Carlson, Effective FMEA, for the why and how to be much more successful with your next FMEA study. Carl explores principles to guide the team as they conduct an effective FMEA (i.e. one that has value).
According to Effective FMEAs the guiding principles are:
Having the Right Objectives
- Focus on Problem Prevention
- Focus on Design and Process Improvements
- Leverage FMEAs to Improve Test Plans and Process Controls
- Select FMEA Projects Based on Preliminary Risk Assessment
- Keep it Simple
Having the Right Resources
- FMEA is a Team-Based Activity
- Fully Understand the Basics of FMEAs
- Provide Skilled FMEA Facilitation and Unleash FMEA Team Creativity
- Benefit from Real-World Lessons Learned
- Management Plays a Key Role in Establishing and supporting an Effective FMEA Process
- Support the Natural Passion and Energy of Employees to Achieve Trouble-Free Products
- Utilize the Wealth of Knowledge in the Fields of Quality and Reliability
Having the Right Procedures
- Make it Visible
- Ensure FMEAs are Requirements Driven and Data Driven
- Ensure FMEAs Always get to Root Cause and Actual Failure Mechanisms
- Keep the Focus on Areas of Concern and Risk
- Perform FMEAs within the Right Time Frame
- Fully Execute all Actions to Ensure Risk Reduction to an Acceptable Level
According to The Basics of FMEA, there are ten steps
- Review the process
- Brainstorm potential failure modes
- List potential effects of each failure mode
- Assign a severity rating for each effect
- Assign an occurrence rating for each failure mode
- Assign a detection rating for each failure mode and/or effect
- Calculate the risk priority number for each effect
- Prioritize the failure modes for action
- Take action to eliminate or reduce the high-risk failure modes
- Calculate the resulting RPN as the failure modes are reduced or eliminated
Those are the basics, combined with the principles above (fully explained in Carl’s book, Effective FMEA), you too can use FMEA to reduce failures.
Ten steps of FMEA (article)
Benefits of Fault Tree Analysis (article)
Reliability Role and Safety and Liability (article)
Greg McLean says
Great topic! I’m sure the book covers it but I’d like to add two points …
1) Get the right people in the room but make sure the number is manageable and effective
And I’m not sure I have that order correct. The dFMEA/dFMECA has to be the most dreaded task in the design process. I’m hoping the book has some insight on how to make it palatable to all participants.
Carl Carlson says
You are absolutely right, Greg. One of the keys to effective FMEAs is engaging the right team of experts!
Some companies try to perform FMEAs with only one or two people. This is not a good idea, in my opinion.
There are three primary reasons for the necessity to have the correct team when doing an FMEA.
1. People have “blind spots.” A well-defined cross-functional team minimizes the errors inherent with “blind spots.”
2. The FMEA analysis requires subject-matter experts from a variety of disciplines to ensure incorporation of all necessary inputs into the exercise, and that the proper expertise is applied to the design or process being analyzed.
3.One of the indispensable values of an FMEA is the cross talk and synergy between subject-matter experts that occurs during the meetings. Well-defined groups can discover things that individuals often miss.
In my experience, a typical core team for a System or Design FMEA might include representatives from system engineering, design engineering, manufacturing engineering, test engineering, field service, and quality or reliability. Large systems or subsystems may require more than one design representative. Supplier partners may be included for critical parts on a need to know basis. A typical core team for a Process FMEA might include representatives from manufacturing engineering, plant assembly, product engineering, supplier quality, end-of-line test, maintenance, and quality or reliability.
I’m a strong advocate for a team-based approach to FMEA, as the right expert team can identify and resolve issues far better than individuals.
Alfred Stevens says
What Fred describes seems to be more accurately described by the Hazard Analysis process rather than the FMEA process; as least as defined by NASA on the Space Shuttle Program in NSTS 22254 and NSTS 22206. FMEA is most definitely not a brain storming process; it is a detailed engineering review of the schematics of system under review and how it can fail and how those failures can propagate through the system. It is a bottom up approach from the components of the system to the outputs of the system. It is exhaustive, labor intensive, and expensive. The failure modes of the various electrical/mechanical components of the system are well known and defined, it is not a matter of brainstorming but rather the physical characteristics of the components. Filters fail in two ways, they clog or they pass contaminants. Relays can fail to operate when required or operate when they are not required (fail open, fail closed) and so on.
Hazard Analysis, on the other is a top down approach looking at adverse outcomes and then thinking (brainstorming if you will although I dislike the term) about the various hazards that could cause those outcomes. In the Shuttle program we used fault trees to drill down from the adverse outcomes to the causes.
The two analyses were performed by two different engineers and then combined into a single analysis known as the Systems Assurance Analysis.
FMEA is an extraordinarily powerful tool but only if applied properly and not confused with hazard analysis.
Carl Carlson says
You make some very good points, Alfred. As you point out Hazard Analysis has an important role in a reliability program, and is a top-down analysis. In most (not all) companies, System FMEA is also a top-down analysis with a scope somewhat greater than Hazard Analysis. Hazard Analysis focuses on system-safety hazards, while System FMEA focuses on *all* system-related deficiencies, including system safety, system integration, interfaces or interactions between subsystems or with other systems, interactions with the surrounding environment, human interaction, service, and other issues that could cause the overall system not to work as intended. I use both Hazard Analysis and System FMEA when addressing complex systems, as they both have their role.
And you are also right that NASA standards, as well as Mil Standards, look at FMEA as a bottom-up analysis. In my experience, it is appropriate to include both the top-down analyses, in the form of Hazard Analysis and/or System FMEA, as well as selected Design FMEAs on critical subsystems and components (bottom-up).
I also agree that FMEA is not primarily a brainstorming activity, although brainstorming can have a limited role, if properly done. Brainstorming is a technique for getting a flow of ideas on the table before making decisions. This technique is most useful when a decision or solution is not easily forthcoming. I’ve seen some amazingly creative solutions to hitherto intractable problems, with the proper use of brainstorming by an FMEA team. However, the FMEA facilitator must be well trained, and needs to know when to use the technique and when to cease using it. An FMEA team that uses brainstorming when it should not be used will flounder and go off track.
Your point about use of Fault Tree Analysis to supplement FMEA is important. Many FMEA teams try to use the FMEA procedure to address situations that are better modeled with FTA. There are times when it is essential to avoid an undesirable event or other high-risk situation that has numerous and complex potential contributors, and FTA is the proper tool.
Carl Carlson says
Thanks, Fred, for referencing my new book, Effective FMEAs. It has been a two year effort and the culmination of 30 years of experience in the field of reliability engineering and management, involving hundreds of companies and thousands of FMEAs. Frankly, it has been a true labor of love, as FMEA is a subject about which I am deeply passionate.
The book is written for both beginners and experienced practitioners, for use in industry and academia. It includes dozens of case studies from a variety of industries, and shows not just the procedure of FMEAs, but how to achieve uniformly high quality FMEAs that improve product designs and manufacturing processes. All types of FMEAs are covered, including System FMEAs, Design FMEAs, Process FMEAs, FMECA, DRBFM, Fault Tree Analysis, Reliability-Centered Maintenance, Hazard Analysis, Concept FMEA, Software FMEA, and more. The focus of the book is application, and it includes end of chapter problems to support learning in industry and academia.
Information about the book can be found on the website http://www.effectivefmeas.com. The website includes links to FMEA articles and useful FMEA checklists to support a variety of applications. The book is available for purchase on Amazon.com.
I sincerely believe this book will help people from industry and academia in their quest to achieve safe and trouble-free products and processes.
Hilaire Perera says
Failure mechanisms are the processes by which physical, electrical, chemical and mechanical stresses induce failure. Knowledge of the failure mechanisms that cause product failure is essential to design and qualify reliable products. The standard Failure Modes and Effects Analysis (FMEA) and Failure Modes, Effects and Criticality Analysis (FMECA) procedures do not identify the product failure mechanisms and models, which limits their applicability to provide a meaningful input to critical procedures such as virtual qualification, root cause analysis, accelerated test programs, and to remaining life assessment.
Failure Modes, Mechanisms and Effects Analysis (FMMEA) enhances the value of FMEA and FMECA by identifying high priority failure mechanisms and failure models. High priority failure mechanisms determine the operational stresses, and the environmental and operational parameters that need to be controlled. Models for the failure mechanisms help in the design and development of a reliable product. This prioritization overcomes the shortcomings of the RPN prioritization used in FMEA, which can provide a false sense of granularity. Thus the use of FMMEA provides additional quantitative information regarding product reliability, and opportunities for improvement, as it takes into account specific failure mechanisms and the stress levels induced by environmental and operating conditions in the analysis process.
CALCE ( http://www.calce.umd.edu/ ) has developed the FMMEA process and helped several organizations implement the tool in their product development process
Bruce Wayne says
Well i will go for fixed scoring and prefer such scales that focus on the high priority or highest overall risk areas.