Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
SPEAKER_00 (01:21):
Welcome back to the
Quality During Design podcast.
In Quality During Design, wewere talking about engineering
aspects of product development.
Pierce the Design Fog coversconcept development, which is
early product development beforewe've actually designed
anything, although we have anidea, but we still need to work
(01:42):
with our team to develop thatidea into a product.
Now here in October, November,December on Substack, we're
exploring late stage designfailures.
So we're through productdevelopment, we've already
settled on a design, we'reverifying and validating it, and
we've found a problem or ahiccup, or there's a decision we
(02:06):
need to make and we're not thatconfident in it.
This is different than planningthings out ahead of time when
there's a space of cool headsand calm planning.
This is more of an emergencysituation.
Something unexpected came up andwe're trying to address it.
In the last episode, I talkedabout evidence stacking.
(02:28):
In October, we identified moreabout the problem, describing
it, and assigning a confidencelevel.
And that gives us a startingpoint to do other things.
It gives us an inkling of whatactivities we should do based on
the problem that we're facing.
It also gives us a startingpoint for stacking evidence.
Because if we are 40% confidentin something, how do we get to
(02:51):
80% confidence?
So we can start looking atstacking evidence to be able to
get to the confidence level thatwe need.
Today I want to talk about howwe can choose the right sequence
of activities to boost ourconfidence efficiently without
wasting time and cost.
Let's talk more about it afterthis brief introduction.
(03:14):
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
the Design Fog.
I help design engineers applyquality and reliability thinking
(03:36):
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.
Visit qualityderingdesign.com.
(03:56):
Let's dive in.
Here's the scenario.
I described it a little bit inthe introduction, but let's get
a little more into it.
Late stage failure, what do wedo about it?
We've already assessed the riskof it, meaning we've identified
what kind of impact it has andour confidence level in it, and
that's helping us to makedecisions and what to do.
(04:18):
And now we also recognize thatwe can stack different tests or
analysis methods to be able toget us to a more confident
decision.
Again, these are really usefultools in the heat of the moment.
It helps us to avoid thoseknee-jerk reactions, and it
gives us a systematic approachto be able to solve a problem
(04:40):
that everybody's panickingabout.
You can also use this in yourplanning in the earlier stages
of product development.
But for now, we have a problem,we already have evidence, we
have a low confidence, it's ahigh impact to our project.
What do we do first?
At this point in the project,well, let me back up.
(05:00):
At any point in the project,we're always considering time
and cost.
In late stage development, whenwe're in late stage development
with these surprises, thesesurprises are introducing a time
and cost debt.
I want you to think about whenyou're deciding what to do first
to improve your confidencelevel, is to think of three
(05:23):
dials.
Think of time, cost, and yourconfidence boost.
Every type of test, research,expert consultation that can
help you improve your decision.
Consider not just the time andcost, but also the confidence
boost that you're going to getfrom it.
(05:43):
This kind of goes along withwhat we talked about last month,
assigning a confidence.
As engineers, we would do wellto get better at assigning
confidence in some of ourdecisions, and then be able to
back that up with the reasonswhy we're assigning that type of
confidence level, whether it'sour uncertainty, whether it's
(06:04):
the level of impact, what isleading us to that uncertainty.
And then we can also do thatwhen we're choosing activities
in order to boost ourconfidence.
Really think about how thatactivity is going to be adding
confidence to your decision andname the confidence, name the
confidence level, assign it avalue.
(06:27):
This forces you to be strategicabout what you're doing.
For example, a literature searchis low cost and low time, and it
might give you a moderate boostin your confidence.
Compared to a system level test,which is going to cost a lot,
perhaps take a lot of time, andwould give you an extremely big
(06:48):
confidence boost.
Which one should you do?
Should you do both?
Should you do both at the sametime?
Should you skip the literaturesearch and only focus on the
system level test?
It depends.
We need to make a decision.
And we can use the time cost andconfidence boost to help us make
a decision.
Here's a strategy that you canuse when you're facing this kind
(07:10):
of decision.
Use the work backwards strategy.
You can start with the mostdifficult, expensive endpoint,
which could be your systemtesting, but then walk backwards
from that to find cheaperpreliminary steps that build
toward it.
If your options are literaturestandards, consultation,
(07:32):
analysis, or simulation,component testing, and then
system level testing, maybedon't just jump to system level
testing.
And maybe don't just do them allat once trying to fast track
your decision.
Think backwards from what youthink you might need to these
earlier problem solvingmethodologies, like the
(07:52):
component testing or theanalysis and simulation.
Always consider those threedials: time, cost, and
confidence boost.
I know that this concept isn'tforeign, and as you're listening
to it, it probably sounds prettyobvious because we're engineers,
we're trained to be able to workthrough problems like this, to
(08:13):
be able to make decisions.
But we can get stuck when we'rehaving these emergencies in
focusing on not just the timeand cost, but also getting
explicit about the confidenceboost that whatever analysis is
going to give us is going tohelp us make decisions about
what to do first instead ofdoing all the things.
(08:35):
Really pause and give it anassignment.
When you step back and look atit, you may realize that, you
know what, a literature search,an expert consultation, this
isn't going to help us in thissituation.
It's only going to give us a 5%boost in total.
So we're not going to waste ourtime doing that.
(08:56):
By assigning a confidence boostto your test plans, you're more
critically assessing andthinking through what kind of
information that you need thatyou really need to be able to be
more confident in your decision.
This is the switch that Iencourage you to make.
Take these natural thoughtprocesses that you have toward
(09:18):
test design and solving problemsand stop and start assigning a
confidence level to them.
Assign a confidence level to theproblem, and then assign a
confidence level boost towhatever solution that you have.
This is going to not only helpyou plan out how to react to the
situation, it can also help youwork with your team to develop a
(09:39):
test plan that will actuallyhelp you make a decision.
And if it ends up being that youreally need that component test
or that system level test inorder to solve this problem,
having a confidence boost andusing confidence levels will
help you articulate the level ofimpact that this kind of test
(10:01):
will have on your decision andon the project as a whole.
Combining that all with evidencestacking and acknowledging that
there are time and costconstraints that we need to
think about, but these othermethods aren't going to give us
what we need, or they will getus pretty far, and let's start
with those.
(10:22):
Where you might get stuck is itis difficult to start assigning
confidence to things.
For one, it's uh it's like amuscle that we need to train
with.
We need to practice it in orderto get good at it.
But breaking it apart, like I'veshown on Substack, on the posts
in October, really help us getfar in being able to assign a
(10:44):
confidence level, which is why Ipromote it.
And another reason is that wedon't want to look like bad
engineers or indecisive people.
We want to be seen astechnically competent and um
good at our engineering jobs andat our design.
But would you rather work withsomebody that was overconfident
or somebody that had an honestuncertainty that they
(11:07):
communicated with the team?
Would you rather have anengineer who's 90% confident but
can't explain why?
Or an engineer who's 60%confident and articulates
exactly what they're uncertainabout and what would increase
confidence.
Most of us would say B.
(11:29):
Being strategic with theselate-stage design decisions and
problems that pop up is going tohelp us be the engineer who can
describe their confidence andarticulate what they're
uncertain about.
When we don't do this, we riskover testing.
So wasting months on tests thatonly move our confidence 2%, or
(11:52):
under testing, missing criticalunknowns until it's too late and
reaches production, or testingthe wrong things, meaning we're
testing what's easy versus whatmatters.
So the fix for all of this isn'tmore testing, it's strategic
testing.
It's understanding the impactand our current confidence
(12:12):
level, understanding how we canstack evidence and how each
layer of our evidence stackinggives us a confidence boost.
And being able to assign whatconfidence boost that would give
us.
So what's today's insight toaction?
Start flexing and using thoseconfidence assigning muscles.
(12:33):
Start using it in your planning,your test planning sequences,
and start using it when you'rereacting to problems and issues
that come up later indevelopment.
It will help you to make betterdesign decisions.
Now from this month, you havethe stacking principle, the
three-dial model, and the workbackwards strategy.
(12:53):
If you want the sequence and thecase study and ready-to-use
templates that save you time andprevent errors, subscribe to the
Substack.
This is the toolkit you need toimplement this framework.
Why am I pushing you to Substackand not just describing it here?
Because these are not easyconcepts to be able to explore
(13:13):
in a 10-minute podcast.
On Substack, I'm providing moredetails about it, guidelines,
visuals, and examples that helpyou apply this idea to your
work.
So visit qualityduringdesign.substack.com, or
you can get the transcript ofthis episode and many other
(13:34):
podcast episodes atDinienterprises.com.
This has been a production ofDini Enterprises.
Thanks for listening.