dFMEA: 8 Secrets for a Successful Implementation

dFMEA 8 Secrets for a Successful Implementation

In this post, we’re going to explore the dFMEA or design failure mode and effects analysis. This is a must-use tool for product design engineers to use during the early product design and development process to assure that the product will fulfill your requirements and your customers’ expectations. By doing this analysis, manufacturers are able to de-risk the product design early on, finding and avoiding problems (failure modes) that might otherwise find their way into production.

I’ll show you what the analysis is, what to do with it, what’s included, and, later on, 8 secrets to implementing it successfully that too many companies miss!

 

What is a dFMEA?

dFMEA stands for ‘design failure mode and effects analysis’ and it’s a risk analysis process that is typically done early on in your product’s design and development process, also known as the NPI process, done to find potential ‘failure modes’ and decide on how to alter the design to correct or prevent them.

Ideally, all failure modes like this would be avoided, however, mishaps happen and the design and development teams tend to be very busy with numerous variables and factors that they have to keep in mind. So, unfortunately, here and there sometimes based on the schedule they may either forget about something or cut corners in quality, reliability, or testing that would cause failures like this not to be identified.

The real purpose of the dFMEA is to de-risk the design before development has gone too far so that later on in production and when the product has been sold to customers you wouldn’t have any kind of serious failure modes that can either impact the performance and use of the product or result in a catastrophic failure that can cause death or a huge impact on users.

FMEAs can be used in any product type, but those where failure is very risky, such as vehicles, medical devices, construction materials, etc, are key candidates.
For example, a classic worst-case scenario that perhaps could have been avoided with an adequate dFMEA would be the failure of the Samsung Galaxy Note 7 which caught fire and exploded due to a defective design that impacted the battery.

 

When to do a design failure mode and effects analysis?

The best time to do the dFMEA is early on during the product development process, probably during EVT, or even earlier!

The earlier you do the dFMEA the better because as you go through the development phases and the product design is cemented it becomes harder to make changes if the dFMEA identifies that some design areas must be changed in order to avoid any kind of failure risks.

Is it a standard EVT activity?

The way to look at it is that should be an extended part of a development phase if you have a professional engineering team who follows a best-in-class design process, however, it’s not a mandatory part of a product design and development. Some companies will use it, while some companies don’t, especially those who are short in staff, time, and resources.

For larger projects like an airplane, space shuttle, tank, or any kind of projects like medical devices where failure is not an option or risks can cause death or immense catastrophic failures or immense costs, the FMEA process must be followed.

 

How to implement the dFMEA? (10 steps)

How would we implement such a process during new product development so that it can actually successfully work for the purpose that we want?

A dFMEA template will usually be used. It may be in excel or sometimes in a software format where you just input the data and it comes back with an RPN number (which we’ll come back to it later).

DFMEA template

Template example courtesy of Calpoly.edu

There are 10 steps you must follow to be able to de-risk the product design, adding the information to the template.

  1. Examine the product design and understand its systems and functions and its requirements and create lists for each – you need to fully understand the product design, its components, and its functions before you can start working on potential failure modes.
  2. Brainstorm the product’s failure modes – e.g. what would happen if you overload a car’s chassis? Potential failures would be clear, for example, the driver would lose control of the vehicle and that’s a severe risk as someone could die.
  3. List the effects and assign severity ratings from 1-10 to each possible failure mode – e.g. risk of death as above would result in a very high rating of 9 or 10.
  4. Figure out the causes of the failure modes – the failure modes you have now listed have causes, so look into the root cause which could be design, component, or function-related.
  5. Implement mistake-proofing or preventive measures and assign occurrence ratings from 1-10 – once the causes are known, put in place measures to fix or stop them from occurring and assign an occurrence rating on how likely the failure mode is to occur with the measures in place.
  6. Put in place detection activities and assign detection ratings from 1-10 – detection activities such as inspections and testing will be put in place and the rating will indicate how likely it is that such a failure will be detected before a product ends up in customers’ hands.
  7. Calculate the RPN (Risk Priority Number) – this is the overall relative risk ranking of a failure mode and it can be found by using this calculation: Severity x Occurrence x Detection = RPN. You may implement a limit beyond which the failure mode must be tackled.
  8. Recommend actions – based on the RPN numbers, prioritize which failure modes to work on. The engineers will then tackle these, making recommendations for improvements to solve the issues.
  9. Take action – carry out the improvements recommended by the engineers, while documenting them carefully. This could be design and materials changes, for example, followed by product validation testing.
  10. Re-calculate the new RPN after improvements have been made – it’s time to re-evaluate. Have the improvements resulted in a reduced RPN? Is it now at an acceptable level? If so, the product design can move to the next phase of the NPI process.

This is the dFMEA methodology in a nutshell. Many product R&D teams are already very familiar with this process, but where such an analysis falls down is how it’s implemented.

 

8 dFMEA secrets for more successful implementations

There are a number of secrets to implementing a dFMEA successfully that product design and development teams can often miss or get wrong:

1. Create a dedicated team for the analysis

To be able to successfully implement the dFMEA you must create a team of experts drawn from your design, manufacturing, mechanical and electrical engineering, quality, reliability, and test engineering teams (and more where appropriate) because they know the product design well enough to agree on potential failure modes and root causes.

2. Nominate one of the experts as ‘project manager’

You need to have a person who coordinates these meetings and schedules weekly or bi-weekly meetings, documents all the information asks the right questions, and basically manages this whole process. Typically this person will be either from the reliability or quality departments and it’s important that you choose a very senior-level experienced individual who has plenty of experience in de-risking, risk analysis and the FMEA process.

Once you have figured out what the failure modes are, it’s also very important that whoever is coordinating these meetings and documenting all the information from every expert also has a logical process of asking the right questions, because the team under the management of this person is looking to them to guide and manage this process. If they don’t have, say, experience in doing an FMEA, they may not ask the right questions resulting in not getting the right answers, therefore the analysis process would fail.

3. Do a very thorough risk analysis

It’s quite possible to miss one of the critical failure modes that could happen, leaving it undocumented and untracked. This might happen if you’re pressed for time or if an expert designer misses a meeting, for example. That’s a huge mistake, so it is extremely important that you have the right team members (department experts) on board and that everyone understands that it’s critical not to cut corners and to take enough time to discuss the various potential failure modes freely (brainstorming).

4. Draw on the project manager’s experience to ask the right questions

The project manager needs to be a senior figure with plenty of de-risking and dFMEA analysis experience, otherwise, there’s a chance that they won’t ask the right questions and important failure modes may never be explored.

5. Ask the ‘5 whys’ to get to the root cause of failure modes

Following on from the last secret…the project manager needs to ask the panel of experts why a failure mode would occur and can use the 5 whys interrogative technique developed by Toyota. Given each reason, ask why again a further four times, each time constructing the question in relation to the next answer and finally getting to the root cause.
Here’s an example of an engine not starting:

  1. Why? – The battery is dead. (First why)
  2. Why? – The alternator is not functioning. (Second why)
  3. Why? – The alternator belt has broken. (Third why)
  4. Why? – The alternator belt was well beyond its useful service life and not replaced. (Fourth why)
  5. Why? – The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)

6. Follow through on implementing preventive actions

After you have gone through the process to find the failure modes and their root causes, the next step is to implement preventive actions. I have seen companies go through the trouble of doing the dFMEA and never actually implement the preventive action plan far too many times! This means failures keep happening as if nobody ever did the FMEA, so it’s critical that whoever is coordinating and documenting this analysis is also making sure an individual or team is responsible for preventive actions, such as rework. If it is carried out, you’re truly able to de-risk the product design.

7. Test the fix based on dFMEA

After you’ve done the dFMEA and implemented the fix (preventive actions), you must test the product based on the dFMEA to assess whether the potential failure modes discovered are failing now.

An effective way to do this is to design a test. For example, you might overload the system and see what kind of failures happen. After the implementation of the preventive action plan, if none of those failures happens it’s a success because the original failure/s is no longer happening.

8. De-risk one final time and do ORT

Finally, you must de-risk one more time by doing another dFMEA. This focuses on the failure modes’ RPN in the first analysis, and then after implementation of the preventive action plan and a subsequent second dFMEA, the new RPN is compared. If it has been reduced from 200+ to, say, 10, you may consider that the risk is low enough to be acceptable (depending on the acceptable risk limit). Then, once you have de-risked the process and have tested, implemented, and made sure that these things couldn’t happen again, the final thing that should be happening is to manufacture the product and ship it.

As a part of ORT (ongoing reliability testing), you could periodically do the overload test and other critical tests that are necessary to verify that the preventive actions implemented after the dFMEA are still effective and working properly.

 

Conclusion

In conclusion, the FMEA should be an important part of an NPI product development phase and must preferably be implemented early on in the development before EVT one or at EVT.

Not every dFMEA is successful. Some of the key secrets to success to remember are as follows:

  • Creating a coordinated team of experts to do the analysis and making sure they meet weekly, if not daily for a few days, in the beginning, is a very important driver for a successful dFMEA project.
  • Making sure everyone in the team understands the function of the product and typical and serious failure modes that could happen will make it a lot easier to devise effective preventive action to be put in place.
  • After you calculate the RPN numbers, you must sort them from the highest RPN (meaning the highest risk item) down to the lowest risk and you must communicate with the design team to focus on the highest first as these are the most damaging.
  • Remember to follow up after the preventive actions are done with another dFMEA will show you if the risk priority number numbers actually went down from high risk to low risk.
  • Monitoring is really critical. If you have fixed something you need to make sure that it’s going to work for a long period of time, so when the product has already been in production you’ll need to monitor it for the first few days or even months, and during that time period, you’ll continue to do tests to confirm and verify that the preventive action plan implemented actually is working.

The dFMEA is one of the most important design tools that every product design team should keep in mind to do, especially and particularly if the product is of critical and important function such as a heart monitor, a missile, or an airplane. When developing these types of products where failure is not an option, it’s critical to go through the FMEA at the beginning of the design process.

Do you have any questions about doing your own design failure mode and effects analysis? Let me know by commenting or contacting us, as we can help advise you.

 

P.S. Read even more on the topic

If you enjoyed this post, you can learn even more about the dFMEA and FTA (fault tree analysis) here: Product Design FMEA and Fault Tree Analysis: Addressing Issues Preventively


 

The Author

Our head of New Product Development, Andrew Amirnovin, is an electrical and electronics engineer and is an ASQ-Certified Reliability Engineer.

He is our customers’ go-to resource when it comes to building reliability into the products we help develop. Before joining us he honed his craft over the decades at some of the world’s largest electronics companies such as Nokia, AT&T, LG, and GoPro.

At Agilian, he leads the New Product Development team, works closely with customers, and helps structure our processes.

This entry was posted in Product Development and tagged , , . Bookmark the permalink.

Comments are closed.