What is FMEA? Failure Mode and Effects Analysis Process Overview
|
What is FMEA (Failure Mode and Effects Analysis)?
Failure Mode and Effects Analysis (FMEA) is a structured process for determining potential risks and failures of a product or process during the development phase. FMEA teams examine failure modes—those potential points of failure in a product or process — and what the failure effects (risks, harm, waste, or defects) might be for the purpose of mitigating or eliminating these potential failures before release.
Product development teams have to balance many competing interests. Market competition, customer demands, and stakeholder pressures can combine to tempt teams to rush products to market and skip important steps. But the risk of skipping steps also increases the risk of future failures, recalls, or legal challenges. How can development teams design and develop products that meet safety and regulatory guidelines, satisfy customers, and produce profits for the company?
One vital piece of the development team’s process is Failure Mode and Effects Analysis (FMEA). But in order to make the best use of FMEA, teams need to understand more than just what it is; they also need to understand why it’s important and how to integrate it fully into the product development process.
Failure Mode and Effects Analysis Process Overview for Product Teams
FMEA is more than just a one-time event or a prescriptive process meant to be checked off a list. Properly performed, FMEA can improve product quality, reduce costs, and help establish compliance with safety guidelines by helping development teams identify potential failures early in the lifecycle rather during verification or validation (or even post-market!). Performing FMEA also helps capture organizational knowledge around products and preserves information for future development cycles. Finally, collecting data on a new product not only documents what could go wrong with the product, but also what suggestions were rejected, what actions were taken, and what solutions were adopted.
It can be helpful to think of Failure Mode and Effects Analysis as highly structured brainstorming. Within the confines of an FMEA structure, team members are encouraged to consider all possibilities for product failure and use team and organizational knowledge to arrive at possible solutions or actions to solve the problems. Instead of being just a template to fill in, proper FMEA is a systematic group of activities intended to:
- Recognize and evaluate potential failures of a product or process;
- Evaluate the effects of failures;
- Identify actions which could eliminate or reduce the chance of potential failure; and
- Document the process and record decisions.
In this overview, we will review the history and purpose of FMEA, define key terms, and provide an outline for how to perform FMEA as part of the development process.
What is FMEA?
First used in the 1940s, FMEA started as a military process designed to test mission-critical safety. Since then, FMEA has expanded into industries as diverse as automotive, medical devices, and aerospace. As a tool to help mitigate risk and comply with international standards such as ISO 14971, ISO 13485, IATF 16949, and AS9100, FMEA supports many risk management tasks and helps establish proof of compliance.
What is a failure mode?
Failure modes are ways that an element, component, system, function, or process can fail. For example, a bicycle hand brake works by creating friction between the rotor and the brake pads. Events that interfere with that friction are failure modes — for instance, heavy rains might cause a reduction in friction when the brake is applied leading to failure of the brakes.
Once you know the failure mode, the effects can be determined. Effects are the ways that failures can cause harm, waste, or defects for the customer. In our bicycle example above, failure of brakes could lead to serious injury of the bicycle operator. The analysis piece of FMEA is where failure modes and effects are identified and prioritized so that they can be reduced or eliminated before new product release.
RELATED POST: What is Requirements Traceability and Why Does it Matter for Product Teams?
How are failure modes found?
Failure modes are discovered through testing and brainstorming as part of the development process.
How is FMEA calculated?
What is a risk priority number (RPN), and how is it used in FMEA?
A risk priority number (RPN) is a number assigned to the specific process or step within a process to quantify the likelihood of detection or probability of occurrence of a failure mode and the severity of its impact. The RPN is the product of three scores: 1) the likelihood of the failure occurring, 2) the likelihood that the failure will not be detected, and 3) the impact of the failure in terms of harm or damage to a person or equipment.
In FMEA, every failure mode is assigned an RPN. The goal of the FMEA is to reduce the RPN; the higher the risk of severe impact, the more the FMEA process will seek to reduce it before product release or re-release through corrective actions.
FMEA can also simply be calculated by a simple SxO – severity times occurrence.
RELATED POST: Why You Need to Make More Time for FMEA
What are the most common types of FMEA?
There are two types of FMEA that are most common: design FMEA and process FMEA.
Design FMEA
In a design FMEA (dFMEA), the product team reviews potential product malfunction, the possibility of reduced product life, and safety and regulatory concerns. The team looks at every aspect of the product, such as material properties, geometry, tolerances, interfaces with other components or systems, environments, user profile, degradation, and systems interactions.
Process FMEA
A process FMEA (pFMEA) looks for possible failures that reduce product quality or reliability and result in customer dissatisfaction. It also looks at safety concerns that might arise from human factors, processing methods, materials, machines, measurement systems, and environmental factors.
FMEA Levels and Scope
FMEA is context dependent; a proper analysis can only be performed if the team understands where the process or design feature lives in the overall system.
At the highest level, a product as a whole is one system. Under that system are sub-systems. Each sub-system has assemblies and/or processes, and each assembly or process has components and/or activities.
Image Courtesy of ETI Group 2019
FMEA should be performed at each of these levels and for each item within that level.
Within each item or level, the FMEA team needs to set the boundary of analysis, or scope. A clear scope will answer the following questions:
- What is our focus—design or debug? (Where is the product on the development-to-launch timeline?)
- Which item and level is being covered by this FMEA—system, sub-system, component, process, etc.?
- What triggered this FMEA—changed regulation? Product redesign? New environment?
- What aspect of design or process are we addressing (reliability, environmental impact, serviceability, etc.)?
- Who is the customer, and what are the customer requirements?
RELATED POST: An Interview with Award-Winning Medical Device Risk Management Educator and Author Bijan Elahi
Why perform a FMEA?
For many companies and product development teams, the biggest worry around product release is a major misstep that results in harm to users, bad publicity, recalls, product corrections, lawsuits, or worse. But even smaller product issues can erode a company’s reputation and bottom line. If engineers and customer service teams spend their time fighting product fires and resolving customer complaints, they aren’t spending time designing new features and products to drive company growth.
Image Courtesy of ETI Group 2019
Making an FMEA procedure a routine piece of the product development process moves risk assessment to an early part of the development cycle. It helps ensure that risks are reduced early in the process, saving time, money, and reputation in the long run. Performing FMEA early in the process allows teams to think critically about potential design and process failures when it’s still possible to control risks, costs, and reputation.
The time to control costs is early in the development process, before costs are incurred. Failure Modes and Effects Analysis helps companies accurately evaluate and plan for costs by providing a structured way to evaluate and analyze potential risks and failures.
Product cost vs. time graphic—Dr. David M. Anderson, Design for Manufacturability: Optimizing Cost, Quality, and Time-to-Market
When should we perform a FMEA?
FMEA is a proactive tool to use any time you are:
- Developing a brand new design, technology, or process;
- Modifying an existing design or process;
- Changing the environment, location, application, or usage profile of a design or process; or
- Responding to a change in regulation affecting a design or process.
It’s also important to remember that FMEA is a continuous process, not a one-time event. In fact, it is most effective when it is implemented at different times for different objectives across the development cycle. For best results, gather as many cross-functional minds as possible. This is not a call to have everyone in the company involved at every stage, but rather to gather people with different perspectives and insights who can focus on one system or sub-system at a time.
RELATED POST: Requirements Management Tools and Software
What is the FMEA process? How should we perform an FMEA?
While FMEA can seem overly structured at first, in reality, this structure is actually one of its valuable strengths. Within the FMEA structure, teams have the ability to ask questions, provide insights, and brainstorm solutions in a way that captures knowledge for the organization and improves product performance and safety at the same time.
But while the structure is a great strength of FMEA, it can be daunting for teams that have little experience with it.
Image Courtesy of ETI Group 2019
Here is an orderly way to approach FMEA:
Step 1: Prepare the FMEA document. Typically, this step can be done by a single person familiar with the design or process being analyzed—a member of the design team, for example. The temptation is to make this document too large or too encompassing. Remember, it should include only one system or sub-system or even one process or attribute at a time.
Step 2: Invite the team. This step can happen concurrently with step one. A member of the product team should form a non-permanent team of four to six people from inside and outside the development team. Your cross-functional team might include people from procurement, planning, finance, sales, marketing, and production—and, of course, the customer or end user.
Step 3: Input information. When the team is assembled and the document is in place, it’s time to brainstorm. Look at all potential failure modes. Evaluate potential causes, risks, and potential effects of the failure mode, and fill them in accordingly on the FMEA document.
Step 4: Assign RPNs. Calculating and assigning RPNs can often happen concurrently with inputting information, but if it doesn’t, be sure that these are assigned before moving on to prioritizing and brainstorming solutions.
Step 5: Prioritize failure modes. The failure modes with the highest RPNs are the most high-risk failure modes and should be evaluated and reviewed first.
Step 6: Coordinate with other teams. Of course, it’s preferable to have many FMEA teams reviewing systems, sub-systems, and other items within each level at the same time. Teams should be sure to coordinate with each other. If one team’s solution actually causes another team’s failure mode, or if one team’s effect could mean a consequence for another team’s system, it’s important to discover that as early in the development cycle as possible.
Step 7: Integrate with requirements management and compliance and regulatory guidance. As FMEA teams complete their analyses and resolve potential failures, those results should be integrated into the requirements management process and relevant safety and compliance guidelines. Using a requirements management tool such as Jama Connect, teams are able to link FMEA items directly to sources of potential failure and to mitigating requirements or verifications.
Image courtesy of ETI Group 2019
Are there templates for running an FMEA?
There are many templates available for running an FMEA. A simple search can turn up multiple results.
Heres a sample FMEA in Jama Connect
Are there software tools that can help streamline the FMEA process for product teams?
Jama Software integrates FMEAs directly into the design process by providing customizable templates that allow teams to collaborate, relate mitigations, track changes, review, and track workflow status.
Don’t let a rushed development cycle put you at risk for bad reviews, recalls, lawsuits, or worse. By integrating a thorough FMEA into your development process, you’ll bring better products to market and ensure safety and compliance.
To learn more about how Jama Software can help you connect your FMEA to your requirements management, contact us.
Subject matter experts from Jama Software provide guidance and best practices on requirements management, test management, compliance and regulation, risk management, and complex product and software development.
Latest posts by Jama Software (see all)
- Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls - November 19, 2024
- The Clear Choice: Why Jama Connect® Surpasses Codebeamer for Requirements Management and End-to-End Traceability - November 12, 2024
- Jama Connect® Receives Buyer’s Choice for 2025 on TrustRadius! - October 30, 2024