I've mentioned in previous episodes that it's best to do FMEA early in the design concept phases of development.
Well, if we do FMEA early, then what can with do with it?
We explore how to study any risk analyses (system risks, FMEA, hazard analysis) to help design-out problems, set-up design inputs, and help us figure out test methods. We also talk a bit about why a team is a necessary part of risk analyses.
**NEW COURSE** FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Visit the course page for more information and to sign up today! Click Here
**FREE RESOURCES** Quality during Design engineering and new product development is actionable. It's also a mindset. Subscribe for consistency, inspiration, and ideas at www.qualityduringdesign.com.
About me Dianna Deeney helps product designers work with their cross-functional team to reduce concept design time and increase product success, using quality and reliability methods.
She consults with businesses to incorporate quality within their product development processes. She also coaches individuals in using Quality during Design for their projects.
She founded Quality during Design through her company Deeney Enterprises, LLC. Her vision is a world of products that are easy to use, dependable, and safe – possible by using Quality during Design engineering and product development.
Speaker 1:
So we've reached the end of a preliminary F M E A or hazard analysis. We worked with our team. We developed a list of risks or failure modes, and we rated it with severity, occurrence and maybe detection two. What do we do with this now? Let's talk more about it after this brief introduction. Hello and welcome to Quality During Design, The place to use quality thinking to create products, others love for less. My name is Diana. I'm a senior level quality, professional, and engineer with over 20 years of experience in manufacturing and design. Listen in and then join the conversation@qualityduringdesign.com. So we did a thought experiment with our team, talking about potential stuff that could go wrong, potential failure modes, potential risks besides being in a negative space, this is also a very useful exercise for a team to do. But now that we have it, what do we do with it? We have severity ratings that our team agreed to, and we have occurrence ratings that are based on qualitative data or our best guesses. Maybe we look to other programs or other projects and what was the occurrence or failure rate in those product designs? Or we, we may actually have some field data and complaint information from competitive products. We may have also gotten our users involved in generating all of this, but now that we have it, what do we do with it? Well, now we need to step back and study it. We can think of this as a starting point to explore the product design more, to learn more about it and change it if we need to. So let's step back and study this F M E A or risk analysis and look at what's important. What has a high severity, meaning that it's really bad if it happens. What has a high detection rating, meaning we can't detect it at all, and what seems to happen a lot. What has a high occurrence rating? The first thing to think about is the prevention controls. What? What can we do to prevent this from happening? If we do this risk analysis early in concept development, we might have some pretty obvious answers. There could be redesigns to our product that we could do to change the cause or eliminate a failure mode, or even change the design to be able to detect it and improve the detection rating. We want to look first to how we can prevent causes and failure modes from happening. We can even look at things like, Do we understand the root cause of this problem? Or do we need to explore this more in a lower level? F M E A or another analysis? And what keeps getting repeated? What cause keeps getting repeated to lead to different failure modes? These are all things that we can look at for prevention controls, changes to our design that we can make to just get rid of these problems. Our prevention can also be a requirement for our design. We could be developing our design inputs. If you have more problems than you can realistically handle, then that's where you can start ranking them in order either by picking the highest severity, making sure all the high occurrence ratings are down, and the detection ratings are at least a five, for example. And you can prioritize stains based off that risk priority number, which is the product of the severity, occurrence and detection. These are just ways for your team to prioritize it, but it still needs to be explored within the context of the whole analysis and the whole product. Looking at the big picture will also tell us what to test. We want to look at the failure mode and the cause combination. Does this cause really create this failure mode, or what else causes this failure mode? We can also look to test to bolster or get more specific about our occurrence rating. How often do we think this failure mode could happen because of this? Cause using N F M E A or risk analysis, we can get more specific about what it is we wanna get out of a test, and that helps us with test design. Again, we're exploring the product design more to learn more about it and change it if we need to. We have these team based risk analyses and we have actual testing that we can do, and our risk analyses can inform us with what kind of tests need to be performed. Now, what about those things that aren't important? What if they really are important? If we learn something new through our testing or through subsequent iterations of our design, we're going to analyze it. We need to put it back into our risk analysis and meet with our team and have a discussion about it. And this is also why we use the team of people when we're creating risk analysis. We casting a net over people with different backgrounds, experiences, and knowledge to analyze and discuss our product design, our system, our user's process. This is what helps us capture the things that are important versus what's not important. We need to give our teammates space to be honest about their input. We wanna get team consensus, and we don't want anybody to be bullied into group think. So what's today's insight to action? Those risk analyses that we do with our team, the FM EAs, and the Hazard Lyses, these are ways that we can use as a starting off or kicking off point toward other design activities. We don't wanna do the analysis and just put it on a shelf. We want to step back and take a look at the big picture so we can make design decisions. So a preliminary fm e a is just that. It's preliminary. It's a starting point for our team to take the next step to decide what needs to be redesigned, what feature needs to be eliminated, what new feature we might need, and what do we wanna test, how do we wanna test it, and what do we wanna get out of it? We need to take these risk analyses past just doing them and getting them done to using them for design. If you like the content in this episode, visit quality during design.com where you can subscribe to the weekly newsletter to keep in touch. This has been a production of Dean Enterprises. Thanks for listening.