.jpg)
Quality during Design
Quality During Design helps engineers build products people love—faster, smarter, and with less stress. Host Dianna Deeney, author of Pierce the Design Fog, shares practical tools and quality thinking from concept to execution. Subscribe on Substack for monthly guides, templates, and Q&A.
Quality during Design
How to Choose Risk Tools That Actually Help Decisions
If you reach for the nearest “risk” template, it might cause more problems.
There are two very different jobs we ask risk tools to do. In this episode, we talk about how to pick the one that actually moves your project forward.
- identification tools for unknown unknowns (like FMEA and preliminary hazard analysis) that systematically surface risks to users, systems, and environments
- decision tools for known unknowns that clarify impact, likelihood, and uncertainty so teams can choose a path with confidence.
Along the way, we call out organizational risks—supplier failure, regulation shifts, competitor timing—that belong in resilience planning, not product FMEAs.
Are your teams struggling with poor communication and rushed timelines? Is your product vision clouded by a lack of clarity? It's time to find your way through the confusion and build products that truly resonate with users.
Introducing "Pierce the Design Fog" by Dianna Deeney, the essential guide to turning abstract ideas into high-quality products. This book offers a proven playbook with practical frameworks and tools to help you foster team synergy, lead with vision, and ma
JOIN ME ON SUBSTACK Subscribe today. Get themed Q&As, live chats, in-depth analysis, comprehensive guides, and access to my Strategy Vaults. Founding Member spots are open now.
PICK MY BRAIN Got a particular problem you’d like clarity on? Schedule a 60-minute virtual call with me - we’ll work through it together.
ENROLL IN MY COURSE FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling now. Lifetime access, practical tools, and over 300 students already learning.
GET THE BOOK Pierce the Design Fog is your playbook for concept development to engineering design inputs.
VIEW MY OTHER SERVICES Visit my website to learn more.
ABOUT DIANNA
Dianna Deeney is a quality advocate for product development with over 25 years of experience in manufacturing. She is president of Deeney Enterprises, LLC, which helps organizations and people improve engineering design.
As engineers, we're usually managing risks daily. There's a lot of decisions happening, especially in product development. At all phases of the product development lifecycle, there's decisions being made. You may not realize that it's risk management, but that's essentially what you're doing. You're making decisions to manage the risk of whatever you're developing. Sometimes those decisions can get really complicated. And they can also develop to have huge impacts to the project, whether it involves a setback where we need to retest things. It could cost us exponentially more money to design it one way versus another. But what are the other trade-offs? If our gut instincts are to reach for a risk tool, some sort of tool that will help us to flush out these risks and quantify them, then our gut instincts are right on. But many times we reach for the wrong risk analysis tool and we end up spinning our wheels and it actually makes things worse. Let's talk more about this hang up and what we can do about it after this brief introduction. Welcome to Quality During Design, the place to use quality thinking to create products others love, for less time, less money, and a lot less headache. I'm your host, Diana Deaney. I'm a senior quality engineer with over 20 years in manufacturing and product development and author of Pierce the Design Fog. I help design engineers apply quality and reliability thinking throughout product development, from early concepts through technical execution. Each episode gives you frameworks and tools you can use. Want a little more? Join the Substack for monthly guides, templates, and QA where I help you apply these to your specific projects. Visit qualityderingdesign.com. Let's dive in. I was talking with an engineering team that was trying to implement FMEA more thoroughly in their design process. They had done them before, but they wanted to do more of them to help them make decisions. And when I hopped on the call with them, we talked a lot about FMEA, but they were asking some pretty specific questions. And after a while, the lead engineer hopped on and described that they really had a problem. They had a design decision that they needed to make. And they were trying to use FMEA to be able to help them understand the problem to make a decision. Where their gut instinct was right to reach for some sort of risk tool to help them figure out this problem, they pick the wrong tool. FMEA is not great when you're in an emergency trying to make a decision and creating FMEA to be able to help you make the decision. I'm a big proponent of FMEAs, but they're more of an early phase. Let's understand some of the potential risks and decide what we can do about them. If you already have an FMEA created for your project and you did it in the early stages, by the time you get to these later stages, you can reference your FMEA as a source of information. Source of information when you were thinking, having deep dives with your team about potential risks, and capturing all the information that you knew about it at the time. So it can be a source of information to help you make a decision, but FMEA is the wrong tool for this particular scenario. There are two main uses of risk analysis tools. One is to identify risks, and the other is to help us make a decision. And those are related to the type of unknown that we're facing. We might have unknown unknowns, meaning we don't know what we don't know. But it doesn't mean that we're absolved from not trying to manage the risks that could happen when we're developing a new product and introducing it to the market and giving it to people to be able to use. We still need to try to discover those unknown unknowns, which means that we systematically identify the types of risks that our new product may introduce. It's our responsibility to understand what effects it could have on the environment, to the user, to the other equipment within the environment that it's being used, to the performance, the unperformance of the device, and to people's safety. These are the type of unknown unknowns that we still need to explore and try to identify to the best of our ability. Other unknown unknowns could be things like a supplier that goes bankrupt, or a competitor happens to make it to the market before we do. Or regulations change. All of a sudden, there is a new regulation that's affecting our design decisions. Some of these unknown unknowns we can't test for. Instead, they're managed through organizational resilience. So we want to acknowledge these other unknowns and push those into the appropriate system, but yet still identify potential unknown unknowns of our product and try to address them through our design decisions. So that's one set of risk-based tools. And that's where FMEA, preliminary hazard analysis, and those kind of tools reside. The other aspect of these risk tools is actually helping us to make a decision. With these, we're usually dealing with a known unknown. We have a risk, we have a problem, it's worrying to us, we're trying to solve it, we're having a hard time making a decision. We're not sure how to address it next or how big of a problem it is or how bad it is. Our gut feeling is that it's bad, but we're not sure which direction to take it. And we're also having a hard time communicating it with the rest of our team. In these situations, we have a known unknown. We know about a problem, we don't understand the risk or what to do about it. And this is the other category of risk-based tools that we can use to help us. They can help us better understand the impact when things go wrong and can help us to capture our uncertainty about it. And then knowing this and being able to acknowledge it, work it out with the team, and understand where you are on the risk map can really help drive the activities that can help you make a decision. So for our problem, one of the first things that we can do is just capture the problem. What are we trying to do? Do we have a lot of unknown unknowns where we need to identify risks? Then that would be one sort of set of tools. Or is it a problem that we know about? Do we have a known unknown? Is it a question we can write down? Is it a threat to the success of our product? Can we test it? And can we further name it as a problem and define its scope? In that case, we want to use risk tools that help us to make decisions. This is what that engineering team really needed. They didn't need to identify risks. They didn't need to systematically perform an FMEA. They needed some sort of a tool to help them be able to describe the scope, the impact, and their uncertainty about it to help them make decisions. In the next episode, I'll introduce a two by two matrix that will actually help us quantify this information and help decide what to do next. What's today's insight to action? You may have some standard risk tools that you either like to use or you've used before, or that are just readily available to be able to pull out and start filling in information, but that doesn't mean that it's the right kind of risk tool to aid you and your team in making a decision. Whether that's identifying risks on the front end and deciding how to handle them there, or later in development, having a particular problem, a known unknown, that you're not sure what to do with. We should apply risk based thinking to both scenarios, but they're different and they require different tools. Understanding what it is you want to accomplish with your risk based analysis will help you pick the right tool for the job. This has been a production of Dini Enterprises. Thanks for listening.
