Failure Mode Effects Analysis (FMEA) is a tool that helps us anticipate what might go wrong with a product or process. We can also use it to identify the possible causes and probabilities of failures.
What’s a Failure Mode?
A failure mode is a chance for a process to go wrong. Or, to look at it another way, it’s an opportunity for a defect or variation to occur in a product.
Every process has potential weak spots. If we can recognize these in advance, we go a long way toward minimizing the damage caused. That’s why FMEA is such a handy tool.
When to Use FMEA
Perform an FMEA when you’re:
- Setting up a new process before you start running it in a production environment.
- Improving an existing process.
- Changing an existing process – for example, modifying the type of material used.
- Looking for existing quality control (QC) issues within a process.
The analysis can be of use in all of these situations.
DMAIC Phases
You can use an FMEA in the Analyze and Improve phases of a DMAIC project, which will depend on the purpose of your project.
If your project aims to find issues in an existing process, then you’ll perform the FMEA in the Analyze phase. This is to help you figure out where things are already going wrong.
If your project has another aim–other process improvements, adding a new process, etc.–then the FMEA’s use is slightly different. Then, you’ll use it in the Improve phase to look for issues in your solution to the problem. You’re essentially double-checking yourself.
Types of FMEA
Design (DFMEA)
A DFMEA focuses on a product or service. You’ll typically do these before you put a new product or service into manufacture or when you change the design of either. When you perform one, you look at potential failures, safety issues, and regulatory concerns with the end product. Then, you rank the severity of these. The next step is to find causes for those potential issues.
Use a DFMEA to minimize the effects of product failure on your customers. By the end of your DFMEA, you should have strategies in place to correct all design issues identified.
Process (PFMEA)
A PFMEA looks at a process. Unlike a DFMEA, it looks at the end product or service only to find issues with the process that produced it. More commonly, you’ll look at the output from the process instead. Why are these two things different? Because most products and services are the result of multiple processes, not just one. For example, a digital camera has many parts, each of which is produced using at least one process–often more. To find an issue with the shutter, for example, you’d look at processes that produce the shutter and processes that fix the shutter into the camera.
Start a PFMEA at or after the feasibility study and before production begins. Typically, you’ll perform a PFMEA after the DFMEA, as the latter is focused on design, and the PFMEA is focused on how you bring the design to life.
System (SFMEA)
It is also known as a functional FMEA (FFMEA). A System Failure Modes and Effects Analysis looks at the entire system highly. When you perform one, you look at things like the interrelationships between components and processes. An SFMEA can be useful because problems don’t just occur within processes or specific machines. They also occur between multiple processes or machines.
Where possible, perform an SFMEA before the design phase. This helps you anticipate and resolve issues that would otherwise affect your DFMEA.
Inputs
Your input for an FMEA typically comes from people who know the process, product, service, or system very well. You’ll usually sit down and brainstorm potential failure points with these subject matter experts.
Measurements
During the FMEA process, you’ll need to provide three key scores:
- Severity: How large will the consequences of a failure mode be? Some effects could be catastrophic (think a nuclear power plant meltdown). Others might be very mild (for example, a slight variation in product weight).
- Occurrence: How likely is the failure mode likely to occur? Some failures might be very likely – for example, a laptop computer overheating outdoors in summer in Texas. Others might be very unlikely – for example, the nuclear power plant meltdown mentioned in the previous list item.
- Detection: How capable are the current processes of detecting the failure? Will the responsible person know about this failure mode immediately if it occurs?
These all use a scale from 1 to 10. You’ll note that these are somewhat subjective – you can’t simply use a tool to measure any of them. If you find that your team has trouble reaching a consensus on the scorings, try taking individual scores and calculating the mean score for each.
Note: Some people use a scale of 1-5 instead. As long as you’re consistent, your scale isn’t too important.
Outputs
The main output from an FMEA is a Risk Priority Number (RPN) for each failure mode. The RPN is an objective priority measure for fixing any failure mode or failure mode effect. The bigger the RPN, the higher the priority.
The formula for calculating an RPN is:
RPN = Severity * Occurrence * Detection
How to Create an FMEA
Understanding your goal is the first step in creating a failure modes and effects analysis. We’ve listed the basic types of FMEA above; read through these and decide on what type of analysis you’ll be performing and what the end result should be.
Before starting the FMEA
Your preliminary work will depend on the analysis you plan to perform. Essentially, you need to ensure that the whole team understands what you’re analyzing so that you can brainstorm potential failure modes.
- PFMEA: Map your process. Draw a flowchart so that you have a visual representation of the entire process.
- DFMEA: List the attributes of your product or service. What it does, its measurements (services can have these too!), parts, etc.
- SFMEA: Map the components of your system. An interrelationship diagram might assist.
Writing your FMEA
- Get your team together and brainstorm possible failure points in your process, product, service, or system.
- For each possible failure point, list the effects that failure could have.
- Draw up a blank table with columns for:
- Process step
- Potential failure mode
- Potential effects of failure
- Cause of failure
- Severity
- Occurrence
- Detection
- RPN
- Enter the steps from your flowchart into the Process step column. Leave a few rows between each.
- Add failure points for each step into the Potential failure mode column. Leave a couple of rows between each.
- Enter the effects each failure could have into the Potential effects of the failure column.
- For each effect:
- Add a cause.
- Enter a score for the scale of the consequences of the effect in the Severity column.
- Enter a score for the likelihood of the effect in the Occurrence column.
- Add a score for the probability of detecting the failure effect in the Detection column.
- Calculate the RPN for effect by multiplying the effect’s Severity, Occurrence, and Detection scores. Enter this number in the RPN column.
Your next steps
So, you’ve created your FMEA document. Your job doesn’t finish there. Next, look at ways that your team can modify the product, service, system, or process to decrease RPN scores.
It would be overly simplistic for this article to suggest always working on the highest-scored (hence, highest priority) failure modes first. However, that can be done in a vacuum. Other sort-orders are possible. For example, ASQ recommends “The team should use their experience and judgment to determine appropriate priorities for action.” (source)
Once you’ve lowered the risks of failure modes as much as is feasible, add two more columns to the FMEA:
- Recommended action
- Responsibility.
Then:
- Add at least one recommended action. This is a process that should be followed if the potential failure effect actually occurs.
- Enter the name or job of the person who will be responsible for carrying out the recommended action(s).
Example of Using an FMEA in a DMAIC Project
A company is putting together a new customer support department. It’s developed several processes for various customer queries as part of that process. The Level 2 support team must complete a design FMEA for one of its processes.
Preliminaries
The team’s process analyst puts together a flowchart of the process. It shows the team five high-level steps in the process:
- Get details from the Level 1 support team.
- Ask the customer to run a diagnostic test and email the results.
- Analyze results to find any issues.
- Explain the analysis to the customer.
- Fix the problem if it’s within Level 2 abilities. If not, refer to the Level 3 support team.
Constructing the blank FMEA
The team lead uses Excel to create a spreadsheet for the FMEA.
Adding process steps
They add the five high-level process steps to the FMEA table.
Brainstorming failure modes
The team sits down together with the incomplete FMEA table. They discuss the process steps and brainstorm things that could go wrong. Once they’ve talked through all options, they enter the agreed failure modes.
Recording potential effects
The team records the effects of each failure mode, sticking to objective measures that affect KPIs.
Finding causes
While some situations might require a tree diagram or other tools to chart potential causes, the team decides that this situation doesn’t need anything too complex. They record causes where the issue would reasonably originate in the customer service teams.
Scoring
The team used a simple discussion method to score Severity, Occurrence, and Detection for each failure effect. Then, they calculate the RPN for each by multiplying the three scores.
Prioritizing
The team sorts the spreadsheet from highest to lowest RPN.
Next steps
Now that the team has a prioritized list of failure modes, it can get to work on mitigating them. Beginning at the top of the list, they’ll work on decreasing the RPN by making the failure less severe or less likely to occur. On the other hand, making it harder to detect isn’t generally recommended.
Once the team has decreased the RPNs for its FMEA as much as possible, it adds a basic response plan for each failure mode.
FMEA Excel Download
D: A Risk Priority number multiplies each failure mode’s severity, occurrence, and detection numbers. In this case, 9 * 2 * 1 = 18.
When you’re ready, there are a few ways I can help:
First, join 30,000+ other Six Sigma professionals by subscribing to my email newsletter. A short read every Monday to start your work week off correctly. Always free.
—
If you’re looking to pass your Six Sigma Green Belt or Black Belt exams, I’d recommend starting with my affordable study guide:
1)→ 🟢Pass Your Six Sigma Green Belt
2)→ ⚫Pass Your Six Sigma Black Belt
You’ve spent so much effort learning Lean Six Sigma. Why leave passing your certification exam up to chance? This comprehensive study guide offers 1,000+ exam-like questions for Green Belts (2,000+ for Black Belts) with full answer walkthroughs, access to instructors, detailed study material, and more.
Comments (9)
My question is from where the inputs of FMEA?
Is it from Executive management? Supplier? Accountant? Purchaser?
Hi Icom,
In practical terms the inputs for a FMEA could come from anywhere.
Could you please elaborate on how FMEA use Risk Priorities Numbers to evaluate the modes. I want some clearness about it.
We’ll add an example.
The short answer is that the higher the RPN number, generally the greater likelihood that we will want to prioritize some kind of action.
Practically speaking, the FMEA is a great tool to create conversations about what we should do. Cost, Schedule, and Scope realities can dictate what gets addressed and what gets accepted or deferred.
Hi Ted, you have a few videos that are no longer available and the Step by Step link is broken. Mind taking a look?
Hi Matt,
This article is scheduled for a re-write. I’ll remove the videos and see about moving the rewrite ahead of original schedule.
Best, Ted.
Hi Ted,
What scoring criteria would be used to score a DFMEA?
There is the AS13004 scoring for PFMEA in Aerospace, but would like more information on how to score the Detection for a DFMEA if possible?
Thank you in advance!
Ted, as per my experience the inputs for FMEA normally come from:
1) Voice of Customers(+ warranty/complaint data)
2) Voice of Regulatory
3) Voice of Business etc.
All requirements for FMEA are better taken with the help of Boundary diagrams and Interface analysis.
Yes, those are popular external sources. However, on many technology teams that I’ve led we use these proactively to assess & prioritize our Agile backlogs.