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.

Episode Transcript

SPEAKER_00 (00:00):
As engineers, we're usually managing risks daily.
There's a lot of decisionshappening, especially in product
development.
At all phases of the productdevelopment lifecycle, there's
decisions being made.
You may not realize that it'srisk management, but that's
essentially what you're doing.
You're making decisions tomanage the risk of whatever

(00:22):
you're developing.
Sometimes those decisions canget really complicated.
And they can also develop tohave huge impacts to the
project, whether it involves asetback where we need to retest
things.
It could cost us exponentiallymore money to design it one way
versus another.
But what are the othertrade-offs?

(00:43):
If our gut instincts are toreach for a risk tool, some sort
of tool that will help us toflush out these risks and
quantify them, then our gutinstincts are right on.
But many times we reach for thewrong risk analysis tool and we
end up spinning our wheels andit actually makes things worse.
Let's talk more about this hangup and what we can do about it

(01:05):
after this brief introduction.
Welcome to Quality DuringDesign, the place to use quality
thinking to create productsothers love, for less time, less
money, and a lot less headache.
I'm your host, Diana Deaney.
I'm a senior quality engineerwith over 20 years in
manufacturing and productdevelopment and author of Pierce

(01:25):
the Design Fog.
I help design engineers applyquality and reliability thinking
throughout product development,from early concepts through
technical execution.
Each episode gives youframeworks and tools you can
use.
Want a little more?
Join the Substack for monthlyguides, templates, and QA where
I help you apply these to yourspecific projects.

(01:47):
Visit qualityderingdesign.com.
Let's dive in.
I was talking with anengineering team that was trying
to implement FMEA morethoroughly in their design
process.
They had done them before, butthey wanted to do more of them
to help them make decisions.
And when I hopped on the callwith them, we talked a lot about

(02:08):
FMEA, but they were asking somepretty specific questions.
And after a while, the leadengineer hopped on and described
that they really had a problem.
They had a design decision thatthey needed to make.
And they were trying to use FMEAto be able to help them
understand the problem to make adecision.

(02:28):
Where their gut instinct wasright to reach for some sort of
risk tool to help them figureout this problem, they pick the
wrong tool.
FMEA is not great when you're inan emergency trying to make a
decision and creating FMEA to beable to help you make the

(02:50):
decision.
I'm a big proponent of FMEAs,but they're more of an early
phase.
Let's understand some of thepotential risks and decide what
we can do about them.
If you already have an FMEAcreated for your project and you
did it in the early stages, bythe time you get to these later
stages, you can reference yourFMEA as a source of information.

(03:15):
Source of information when youwere thinking, having deep dives
with your team about potentialrisks, and capturing all the
information that you knew aboutit at the time.
So it can be a source ofinformation to help you make a
decision, but FMEA is the wrongtool for this particular
scenario.

(03:35):
There are two main uses of riskanalysis tools.
One is to identify risks, andthe other is to help us make a
decision.
And those are related to thetype 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'reabsolved from not trying to

(03:58):
manage the risks that couldhappen when we're developing a
new product and introducing itto the market and giving it to
people to be able to use.
We still need to try to discoverthose unknown unknowns, which
means that we systematicallyidentify the types of risks that
our new product may introduce.
It's our responsibility tounderstand what effects it could

(04:22):
have on the environment, to theuser, to the other equipment
within the environment that it'sbeing used, to the performance,
the unperformance of the device,and to people's safety.
These are the type of unknownunknowns that we still need to
explore and try to identify tothe best of our ability.

(04:44):
Other unknown unknowns could bethings like a supplier that goes
bankrupt, or a competitorhappens to make it to the market
before we do.
Or regulations change.
All of a sudden, there is a newregulation that's affecting our
design decisions.
Some of these unknown unknownswe can't test for.

(05:04):
Instead, they're managed throughorganizational resilience.
So we want to acknowledge theseother unknowns and push those
into the appropriate system, butyet still identify potential
unknown unknowns of our productand try to address them through
our design decisions.
So that's one set of risk-basedtools.

(05:26):
And that's where FMEA,preliminary hazard analysis, and
those kind of tools reside.
The other aspect of these risktools is actually helping us to
make a decision.
With these, we're usuallydealing with a known unknown.
We have a risk, we have aproblem, it's worrying to us,

(05:48):
we're trying to solve it, we'rehaving a hard time making a
decision.
We're not sure how to address itnext or how big of a problem it
is or how bad it is.
Our gut feeling is that it'sbad, but we're not sure which
direction to take it.
And we're also having a hardtime communicating it with the
rest of our team.
In these situations, we have aknown unknown.

(06:11):
We know about a problem, wedon't understand the risk or
what to do about it.
And this is the other categoryof risk-based tools that we can
use to help us.
They can help us betterunderstand the impact when
things go wrong and can help usto capture our uncertainty about
it.
And then knowing this and beingable to acknowledge it, work it

(06:35):
out with the team, andunderstand where you are on the
risk map can really help drivethe activities that can help you
make a decision.
So for our problem, one of thefirst things that we can do is
just capture the problem.
What are we trying to do?
Do we have a lot of unknownunknowns where we need to

(06:56):
identify risks?
Then that would be one sort ofset of tools.
Or is it a problem that we knowabout?
Do we have a known unknown?
Is it a question we can writedown?
Is it a threat to the success ofour product?
Can we test it?
And can we further name it as aproblem and define its scope?
In that case, we want to userisk tools that help us to make

(07:19):
decisions.
This is what that engineeringteam really needed.
They didn't need to identifyrisks.
They didn't need tosystematically perform an FMEA.
They needed some sort of a toolto help them be able to describe
the scope, the impact, and theiruncertainty about it to help
them make decisions.

(07:40):
In the next episode, I'llintroduce a two by two matrix
that will actually help usquantify this information and
help decide what to do next.
What's today's insight toaction?
You may have some standard risktools that you either like to
use or you've used before, orthat are just readily available
to be able to pull out and startfilling in information, but that

(08:04):
doesn't mean that it's the rightkind of risk tool to aid you and
your team in making a decision.
Whether that's identifying riskson the front end and deciding
how to handle them there, orlater in development, having a
particular problem, a knownunknown, that you're not sure
what to do with.
We should apply risk basedthinking to both scenarios, but

(08:26):
they're different and theyrequire different tools.
Understanding what it is youwant to accomplish with your
risk based analysis will helpyou pick the right tool for the
job.
This has been a production ofDini Enterprises.
Thanks for listening.