
The Problem with ‘5 Whys’ (2016) - zdw
https://qualitysafety.bmj.com/content/26/8/671
======
CobrastanJorji
Many years ago, I worked at Amazon, and at the time they LOVED "5 Why"
analysis. I had to write a couple of them. The second and final one I wrote
came back from my manager, who told me that it was unacceptable for my "5
Whys" to blame something outside our team's control when the most immediate
cause was a bug written by our team, and I needed to come up with a different
ultimate cause. This was really frustrating, but it was easy enough to
completely change the cause without being dishonest. "5 Why" style analysis is
really easy to steer toward whatever you want to blame.

~~~
awill
You can't end a 5 Whys with 'another team I depend on screwed up'. You have to
own your software or service. If you depend on something, you need checks,
alarms, and whenever possible the ability to handle dependency failure well.

Imagine you're built on a public cloud in a single Data Centre. That DC has an
issue. Your 5 Whys shouldn't end with 'the Data Centre had an issue' It should
continue with 'my service was only in one DC.... Why?' and continue from
there.

~~~
perlgeek
> You can't end a 5 Whys with 'another team I depend on screwed up'. You have
> to own your software or service.

Our service was down.

Why?

Because the platform it runs on went down.

Why only one platform?

Because management doesn't want us to spend several years engineering for
multiple platforms.

\---

I find it hard to imagine a realistic path of 5 whys that leads us back to a
cause within our own team.

~~~
Karrot_Kream
> Because management doesn't want us to spend several years engineering for
> multiple platforms.

Yes and that's fine. It's okay to end up with an RCA like that and note that
as a known risk. If a cost-benefit analysis shows that the risk is dwarfed by
the solution, then it's not worth fixing. Knowing the existing risks of your
system and reevaluating these risks in the face of changes (more people
available, inefficient context switching, etc) is a key component of making
progress.

~~~
awill
True. In a case this simple, you likely wouldn't have to write an RCA.

However, most real life situations I've seen show that there's always room to
improve. For example, how quickly did your service recover once the underlying
platform recovered. Rare events (like DC failure) can be a bad thing for
operational training. Teams forget how to recover. No runbooks, no training,
or tooling that's infrequently used no longer works.

~~~
grogenaut
You actually want to assign to root cause and track that. Them over time you
build up data on if it's worth it to stay on one platform or not. Eg doing
this let's you build a risk profile to counter the $/time argument against.
Then you get to make an informed decision.

You don't just shruggie and move in "that ship has sailed" at least if you're
doing it right.

------
cle
This argument seems rather pedantic to me, possibly because the author's
context is different from mine. Of course you shouldn't treat the 5 Whys as
orthodoxy. Of course it's not a silver bullet in RCA. Of course it's not
always sufficient. It's a useful tool for getting yourself into the right
mindset for RCA: when you think you have an answer, dig a little deeper and
you might find something more fundamentally wrong.

In the author's context (healthcare), 5 Whys may in fact be dangerous to
promote. In software, where many of us are building CRUD sites and consumer
apps, it's a huge improvement over the norm. I'd be very skeptical of the idea
of an engineering team trying to employ CAST (linked in the article to analyze
cardiovascular surgery mistakes) unless they're building something mission-
critical.

My point is: consider _when_ to use a tool. In many contexts, the 5 Whys is a
fantastic tool and should be used. In other contexts (likely this author's),
it can oversimplify.

~~~
chrisseaton
> Of course you shouldn't treat the 5 Whys as orthodoxy. Of course it's not a
> silver bullet in RCA. Of course it's not always sufficient.

This problem is similar to what happens in tech with big new ideas. People do
present it as orthodoxy, people do present it as a silver bullet, people do
present it as always being sufficient. Then people inevitably find it's not
quite that hard-and-fast and get upset.

See the massive backlash against 'agile'. It was supposed to be a flexible way
to approach doing things and some general ideas. But a generation of
programmers have been told it's an absolute rule that you must do things a
certain way - you must have a standup and it must be so many minutes long -
and now they're angry.

~~~
cle
Yes I've observed the same thing. It doesn't mean we should give up on
coherent frameworks though. It just means we need to emphasize and be vocal
about the dangers of orthodoxy (which is what I'm constantly trying to do).

~~~
pintxo
For me it's not about orthodoxy. It's rather about teaching WHY we should do
certain things instead of HOW. If we focus on the why, is sufficiently easier
for people to decide this fits or does not.

~~~
reificator
> _For me it 's not about orthodoxy. It's rather about teaching WHY we should
> do certain things instead of HOW. If we focus on the why, is sufficiently
> easier for people to decide this fits or does not._

Of course. But you shouldn't stop at one _why_. You should keep digging until
you find more. I'd say... five of them should be enough.

------
beat
The problem with 5 Whys? Taking it too literally, and then using this as basis
for an argument criticizing the whole concept.

To be fair, the idea of multiple root causes (and the difficulty 5 whys has in
uncovering multiple causes) is important. But that's not grounds for total
dismissal. Because the value of 5 whys isn't "ask why 5 times and you arrive
at the root cause", but rather "Don't stop at the first answer you find".
Since rather a lot of people stop at the first cause they see rather a lot of
the time, it's a valuable approach.

~~~
alexandercrohde
Agreed.

The argument "tool is misusable and therefore has no value" is absurd. Of
course any discussion framework is going to rely on intelligent people using
it sincerely, and even then will only provide some additional insight. It's a
tool to help people make 10% better conclusions.

~~~
agentultra
I read the conclusion much differently. It said that in a system with a high
rate of error the 5W analysis is insufficient at directing investigators to a
reasonable solution. A definition for reasonable in the case of healthcare is
given. It suggested that context was important and that Toyota's engineering
practices are sufficiently different from health care that the technique
cannot be recommended.

I think the same may be true for networked software services as well. At a
certain scale "root cause" becomes a matter of opinion or interpretation.
Attempting to use a 5W methodology will lead you to one of many different,
possible, causes but will ignore other confounding factors depending on who is
doing the investigation and how it is conducted.

In my experience finding the root cause of a particularly nasty error in a
production cloud system required a formal model to prove that a particular
error was triggered under very specific circumstances. The error was not
reproducible and a test case elusive and yet it frequently ate up our error
budget. There was no way any kind of root-cause analysis could have detected
that error. It was a behavior comprised of over a dozen steps where the
conditions had to be right to trigger it. Humans are not good at finding
things like that on their own and simply asking, "Why?" like a parrot is not
helpful... the system is simply too complex.

Instead of _root cause_ I like to think in terms of _factors_. What is the
probability that a given factor has a high impact on our SLOs? Let's fix that.
If we don't understand what the source of the problem is let's write a formal
specification and test our assumptions and find the factor. Most of all, build
for o11y and make reliability an engineering concern.

~~~
beat
Of course 5 whys is no substitute for the scientific method. It isn't meant to
be. Criticizing 5 ways because it's not good at science is unhelpful. It's a
way to dig pretty deep into a problem very quickly with a simple heuristic. A
5 whys analysis of anything shouldn't take more than a couple of minutes. If
your problem is going to need more than a couple of minutes of analysis, don't
do 5 whys.

------
delias_
We haven’t acknowledged that trying to ‘find causes’ at all is misleading!

Causes are something we create and construct afterwards. They aren’t a
primitive that make up incidents. They don’t fundamentally exist to be found.

Causal explanations limit what we find and learn and the irony is that root
cause analysis is built on an idea that incidents can be fully
comprehended—they can’t!

Instead think about the conditions that allowed an incident to occur. Separate
out everything you think looks like a cause and explore each of them.

Talk about the properties and attributes that were present. There are so many
aspects to incidents that aren’t even causes at all, and they don’t follow a
linear chain of this-led-to-that.

People are presented with RCA and 5 whys as really getting to the bottom of
what matters, but the reality is this approach is a linear simplification. We
need to kick it up a notch and practice more holistic investigations of
incidents.

Stop getting at why people didn’t do what they thought they should have done,
and start getting to the point of what actually happened and how those actions
seemed reasonable at the time.

[https://www.oreilly.com/ideas/the-infinite-
hows](https://www.oreilly.com/ideas/the-infinite-hows)

~~~
tunesmith
Basically, causal analyses are graphical data structures. They're not linear
or strictly hierarchical. They're directed graphs.

------
darksaints
This is a rant that I've had for so long, and it's so hard to concisely
summarize. This does a great job of explaining in detail, but it is much
harder to tell your boss to read a long blog post when you disagree with him
about the correct approach. I found a metaphorical approach to _sometimes_ be
helpful. I use this:

 _On a dark night, a blind man jaywalked and was nearly hit by a drunk driver
who swerved and killed a pedestrian wearing black on the sidewalk. What was
the root cause? Was it because the man was jaywalking? What if he was
jaywalking because he was blind and didn 't know any better? If the driver
wasn't drunk, could he have braked instead of swerving? If the pedestrian was
wearing brighter colors, could the driver have swerved a different direction?
Sometimes there is no singular root cause, but rather a complex interaction of
multiple failures that may or may not arise if you take one failure away.
There may be a better approach than to use a tool that is designed to hone in
on a singular root cause._

Unfortunately, this only sometimes works. The rest of the time, they actually
do try to pick apart the example and claim there is a root cause. The only
recourse then is to present an alternative singular root-cause and say that by
trying to force a single root cause interpretation instead of accepting the
complexity of reality, that your root cause will ultimately reflect your own
biases rather than reality (for example, who do you hate more: jaywalkers,
drunk drivers, or pedestrians that wear black at night?).

I still wish I had a better way of explaining this succinctly, in a way that
makes it more clear.

~~~
vkou
The real man at fault here, of course, was the bartender that served the
driver his last drink. Isn't it obvious? /s

~~~
mechanismo
No, it's the car that allowed the drunk person to drive it. The corrective
action is cars should have breathalyzer interlocks as standard equipment.

I'm not actually joking - applying this process seriously requires looking at
not just who did what (people) but the presence or absence of mechanisms.
Corrective actions that rely on the good intentions of people "remembering to
do the right thing" rarely work.

I review several RCAs a week in my job. If I saw one for a scenario like this
where the actions or inattention any of the humans involved here was
identified as the ultimate root cause, it'd get kicked back for re-work.

~~~
c22
Hey now, the street also allowed jaywalking.

~~~
a1369209993
Pedestrians and heavy vehicles shouldn't be routed on the same level
(/altitude/z-layer) in the first place.

------
lucisferre

        Problem: The Washington Monument is deteriorating
    
            Why? Harsh chemicals are being used to clean the monument
    
            Why? The monument is covered in pigeon droppings
    
            Why? Pigeons are attracted by the large number of spiders at the monument
    
            Why? Spiders are attracted by the large number of midges at the monument
    
            Why? Midges are attracted by the fact that the monument is first to be lit at night.
    
        Solution: Turn on the lights one hour later.
    
    

This is a massive over simplification of the 5 whys process. The author seems
to be implying that this is the core of the process when it is not, it is
merely a simplified example what the process would look like to someone
unfamiliar with it.

Without getting into a massive amount of details the following things are
important to note about 5 whys in lean.

5 whys isn't meant to arrive a a single conclusion or solution, it is meant to
provide deeper analysis so that an appropriate and proportional set of
countermeasures can be proposed and considered. The key concepts being a "set"
of countermeasures and "considered".

5 whys does not need to exist in a vacuum as a problem solving tool. It is
often just one such tool in a more thorough approach such as the A3 process

There is no reason to limit the number of whys to 5 or even go that far in
some cases.

The countermeasures that come out of a 5 whys analysis are not expected to be
implemented and immediately forgotten about. They are part of a plan that
expects follow-ups, measurement and observation of the results.

The underlying causes of the analysis are not assumed to be the only causes or
problems. The purpose of 5 whys is to limit over analysis. This may not make
sense in life-or-death situations, but for most business processes it is
appropriate and efficient to make decisions at a reasonable point in the
analysis and move forward rather than investing a disproportionate amount of
resources in that analysis.

The concept of a "proportional response" is important to lean. If the outcome
of a problem is a patient's death, then the proportional response can be
expected to be considerably more significant that just doing 5 whys.

If all a team does is ask 5 why questions then propose and implement a
solution based on the last answer, this would be a pretty textbook example of
a lean cargo cult.

~~~
andrelaszlo
"this would be a pretty textbook example of a lean cargo cult"

This is indeed the problem, at least according to people close to me that work
in healthcare. Lean does _not_ have a good reputation in these circles.

~~~
lucisferre
I've heard similar from people I know in healthcare. Healthcare has bought
into the six-sigma consultants hard and "the gemba" is being taken along for
the ride in something that very much appears to be the antithesis of lean.

I'm not sure what can really be done about that though. It isn't my industry
so my understanding of the problem is pretty peripheral.

------
vajrabum
The 5 whys are part of the justly famed Toyota Production System for managing
factories. The key to TPS and the part that's always transferable is to get
teams to think about their their work and its results (cause and effect) in an
effective way and then to use the results of that thinking to improve their
products and processes. Anything that contributes to that goal is well
founded. Anything else is cargo cult.

Requiring causal analysis to make direct claims about cause and effect, which
5 whys does, is important otherwise its hard to check or even identify those
claims or evaluate the evidence. It's especially good for getting labor and
suppliers to think which they often are not paid to do. It also oftens lays
bare shallowness in that thinking. I can easily see that other tools might be
better in other circumstances, but management is still going to need explicit
claims about cause/effect and evidence to support those claims in order to
make process improvements.

It's also worth pointing out that there are other shop floor tools in the
quality toolbox we've inherited from manufacturing engineering other than the
5 whys which are easy to apply and can be very useful and helpful
([https://en.wikipedia.org/wiki/Seven_basic_tools_of_quality](https://en.wikipedia.org/wiki/Seven_basic_tools_of_quality)).
Pareto charts for example are often seen in computer monitoring systems and
can be super helpful in seeing changing or developing failure patterns.
Control charts are less often seen in the computer biz but are very useful for
visualizing variability and understanding when processes and systems are and
are not stable.

------
rcdmd
The conclusion is basically this (the last sentence before the "conclusion"
section... > But it does mean that we cannot afford to compound these problems
through the use of an RCA tool that is so deeply and fundamentally flawed.
Other more systems-focused techniques, such as fishbone75 or lovebug
diagrams,72 causal tree diagrams,21 Causal Analysis based on Systems Theory
(CAST)76 or even prospective risk assessment approaches,77–81 should be
considered instead.

I find it odd that the paper cites so many theoretical problems with "5 whys"
and then elevates these other methods as preferred solutions without any
discussion. It's possible RCA committees already recognize the limitations of
"5 whys" and use it as a heuristic that helps focus their efforts. That
doesn't mean these committees all sit around a table and say "well, X sounds
like a major problem, but it doesn't fit our '3rd why,' so we have to ignore
it."

~~~
gowld
Those other systems are either based on 5 Why's or have essentially the same
core. The author's complaint is that there exists an informal approximation to
his technical system, that's easy to understand and which can be used
effectively if you don't have a RCA team that's gone through a bunch of
certification classes. It's like a Java programmer mad that someone launched a
product using Python.

------
chrisseaton
The problem is

> the potential for users to rely on off-the-cuff deduction, rather than
> situated observation when developing answers, as well as difficulty in
> prioritising causes[, and thinking the causes are a linear list rather than
> a branching tree and the problem therefore with 5 Whys being greedy in
> picking a single branch of that tree]

~~~
cle
About half the 5 Whys analyses I've seen at my company end up doing this
anyway, because anyone paying attention realizes this immediately. It's pretty
easy to do a branching 5 Why analysis that branches off in different
directions. It's not an orthodoxy, it's a tool and is so simple that it's easy
to modify for your use cases.

------
cirgue
The value of the 5 whys, IMO, isn't to find absolute truth, it's to avoid
making stupid and easily avoidable mistakes by forcing people to talk to one
another while developing solutions. In many places, people have multiple
concurrent demands on their time, and that can force people into a reactionary
get-it-done-quick mindset. The 5 whys are a way to minimize the impact of time
pressure by having a thorough problem-solving rubric that is expected to be
followed. Basically, it's cover for people to devote more time to
communication and critical thought.

------
peterwwillis
5 Whys is not intended to solve problems, or find a 'definitive' cause. It is
just one way to identify _a_ cause.

 _" Not all problems have a single root cause. If one wishes to uncover
multiple root causes, the method must be repeated asking a different sequence
of questions each time."_ \-
[https://en.wikipedia.org/wiki/5_Whys](https://en.wikipedia.org/wiki/5_Whys)

When you work on incidents, you should already know that the incident you're
looking at could have wide-spread effects, and may only be a symptom of a
series of complex events. You may be able to find _a_ cause with 5 Whys, but
probably not _the_ cause, because the causal chain is almost always complex. 5
Whys is just a shoot-from-the-hip way to find the first, most obvious cause
from the perspective of the person doing 5 Whys.

You might not be able to identify the "real" root cause right away, but by
documenting each incident's cause and linking them into a value chain, and
reflecting these in runbooks, you can over time eventually see where the root
causes are coming from. But you also don't need to immediately solve the root
cause to begin adding safeguards around the known incidents.

------
rjmunro
When we did 5 whys at a company I used to work for, we built a tree of 'whys',
5 levels deep, many branches wide. Then picked several things that could be
improved.

Is 5 whys normally just 5 causes in a line?

~~~
mey
Short answer is no. Five is not a magical limit, nor is one root cause.

[https://en.m.wikipedia.org/wiki/5_Whys](https://en.m.wikipedia.org/wiki/5_Whys)

------
gweinberg
I don't think I have heard the monument story before. It sounds quite
ridiculous, and is about as counterproductive as an example as one could think
of, as it gets the 5 whys thinking completely wrong. Obviously there is
nothing magic about the number 5 nor is it the case that every problem has a
unique cause which has its own unique cause in turn. The point to asking "why"
as many times as you have to is that instead of just solving one particular
problem you want to prevent similar problems in the future. More specifically,
instead of saying "the problem is human error and we fired the guy who fucked
up", you want to improve processes to make human error less likely and/or less
damaging when it occurs.

------
bluGill
5 whys has never claimed to find all root causes. The idea is you don't really
know when you have found all the root causes - they are known unknowns meaning
you don't know that there is at least one root cause, but you don't know how
many are in the full tree so you can never be sure you are done analyzing.
However you don't need to find them all: by finding any root cause and putting
something into place to stop that you have made things better.

In short finding one root case not all avoids analysis paralysis and gets a
solution in place quick.

------
mtnGoat
I think "5 whys" works great for software dev, i still rely on it for RCA
often.

That said, I really wish the healthcare industry would stop using ideas from
manufacturing. LEAN, 5 whys, etc. came from manufacturing widgets,
humans(patients) are not widgets. They should use their brains and come up
with unique ideas to their unique problems rather then piggy backing off ideas
that aren't meant to deal with one-off's.

This is also why i left healthcare and will not go back. Such an important
sector, ripe for disruption, it seems to be lacking so much.

------
TimTheTinker
> The real problem with ‘5 whys’ is not how it is used in RCA [root cause
> analysis], but rather that it so grossly oversimplifies the process of
> problem exploration that it should not be used at all. It forces users down
> a single analytical pathway for any given problem, insists on a single root
> cause as the target for solutions, and assumes that the most distal link on
> the causal pathway (the fifth ‘why’) is inherently the most effective and
> efficient place to intervene.

^ That's the best section of the article. Also, I think the causal tree they
included for an incident at a hospital (patient received the wrong medicine)
is _fascinating_ (see Figure 1; I included a direct link to the JPG[0] below).
They explored one chain of causal subtrees to a depth of 11, and the total
number of nodes is 78 (although some subtrees are repeated - it would have
been better as a DAG[1] instead of a tree). It exposes significant policy and
work culture issues at the facility and gives the reader a sense that they
already know a lot about what it must be like for the nurses who work there.

[0]
[https://qualitysafety.bmj.com/content/qhc/26/8/671/F1.large....](https://qualitysafety.bmj.com/content/qhc/26/8/671/F1.large.jpg)

[1]
[https://en.wikipedia.org/wiki/Directed_acyclic_graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph)

------
thidr0
Whenever I try to do a ‘5 Whys’ analysis on a belief I have (“I believe X.”
“Why?”) I almost always have multiple answers (“Because Y and Z”). Then I have
to recursively apply another “Why” to both Y and Z, and it ends up being a
pretty wide tree of answers.

I’m always left wondering “how am I supposed to really get something out of
this?”

~~~
gowld
5 Whys can't solve something that isn't a problem.

------
mcguire
The most interesting thing that I learned in the first six months working at
the NASA Enterprise Applications Competency Center was that Root Cause
Analysis meetings _were_ the punishment for screwing up. If you didn't have a
good story and the political capital to push it, you were in the hot seat.

------
chiefalchemist
I'm a fan of T5W. But even I don't see it as a panacea. For me it's a reliable
way to vet your original assumption. That is, have you identified a (root)
problem or only a symptom.

T5W is the sanity check before you leap to problem solving, and perhaps solve
the wrong problem - which often is no solution at all.

------
mirceal
Here:
[https://web.mit.edu/2.75/resources/random/How%20Complex%20Sy...](https://web.mit.edu/2.75/resources/random/How%20Complex%20Systems%20Fail.pdf)

Read this. Read it again. RCA FTW!

------
soapboxrocket
I was working with a large aircraft manufacture in Seattle, let's call them
Doeing. We, as a supplier, had an issue and put together a 5 why workshop with
all the stakeholders from both sides. We get a good list of primary whys, and
work all of them out. Then the Doeing lead gets up and points to the two top
causes and states, "we have to eliminate these, because we can't tell
management that the failure is on our side." So we finished the workshop with
secondary failures on our side and spent a year and who knows how much money
on a fix that never worked.

------
tkahnoski
I've had my head buried in software post-mortems lately.

I particularly appreciate the treatment DevOps Handbook gives them as far as
spelling out Systems are Complex, there will be many contributing factors, you
need to take in multiple perspectives to fully illustrate what happened.

This lines up with the article's analysis although the conclusion is a bit
sensationalist, I'm loving the long list of 'other techniques' they present
right before it.

5 Whys should really be considered a place to start and encourage people to go
deeper into failure analysis, then work towards more formal methods.

------
ta1234567890
The main problem is that why just doesn't exist. There is no why.

I can choose an arbitrary answer to a why question every single time.

We are mostly satisfied with a how answer to a why question. And most why
questions are in fact how questions or just used for something else (like
defiance from a kid asking why they have to go to bed).

Also we stop asking why when we are subjectively satisfied with the answer,
not when we've found "the cause". And we've been conditioned since we were
kids to feel it's rude to ask why more than once or twice.

~~~
gowld
> And we've been conditioned since we were kids to feel it's rude to ask why
> more than once or twice.

That's why "5 Whys" is so important -- to re-kindle the intellectual curiosity
that is snuffed out in children.

------
z3t4
My kids also use the "5 whys". It's quite powerful together with "Explain Like
I'm Five". (five year olds are actually smart, while consequences may seem
obvious for a grown-up, it seems consequences are difficult to predict and are
mostly learned by experience!? for example, it's not obvious that the
Washington Monument is deteriorating because of Midges )

------
nswest23
I've never understood the "5 Why's" method to be taken that literally. In my
experience at a major manufacturing company it was taught as a way of
reminding people to think deeper about a problem and not stop at the first
level and think that you have arrived at the root cause. Sometimes it's four
Whys', sometimes it's six.

------
galaxyLogic
It seems to me it is more like something bad happened what could have
prevented it? Then find out multiple things that could have prevented it. Then
figure out which of those ways would be most economically feasible and also
would avoid many other similar problems.

But in general it is good to ask questions, and it's good to allow multiple
answers to the same question.

------
phyzome
I only skimmed the article, but it looks like a textbook case in "doing 5 Whys
wrong".

Like... no one held a gun to your head and said "find a single causal
pathway!" That's something you inflicted on yourself.

There are _plenty_ of problems I could call up with regard to 5 Whys and how
I've seen it practiced, but this is just a silly one.

------
andrelaszlo
I think the conclusion is super interesting:

"HROs commonly aim for a reliability rate of ‘six sigma’ (three errors per
million opportunities). By these measures, healthcare is struggling to move
beyond two sigma (308 500 errors per million opportunities, or a 30.85% error
rate). [...]

But healthcare is far more complex than automobile manufacturing, and takes
place amid processes and systems that are woefully underdesigned in comparison
to a modern factory. [...]

As a result, approaches developed for solving problems in the automotive
manufacturing context may not be as effective in the healthcare arena."

So, in a way, the problem isn't really with 5 Whys. The problem is that it's
applied to processes where errors/defects are much more common.

I've seen it applied to my own domain as well, keeping computer systems (web
sites, mainly) running. If we have one incident with possible downtime per
year, there are probably still way too many potential root causes for 5 Whys
to be useful... and that's still probably at least a magnitude better than
anything I've personally worked on.

~~~
csours
In manufacturing you strive to reduce exceptions (problem states, differences,
inconsistencies), but in healthcare you are pretty much dealing with
exceptions by default - healthy people generally don't go to the doctor.

In manufacturing you should ideally fix one problem at a time. In healthcare
you don't have that opportunity, you have to deal with comorbidities.

In manufacturing you can fire troublemakers (eventually). In healthcare you
have to treat them.

------
localhostdotdev
after experimenting for a while, I now prefer "for what purpose?" instead of
"why?".

"why?" easily leads to cycles and going back down the abstraction hierarchy,
where "for what purpose?" always goes up the abstraction ladder.

\- why are you eating? because it's 7pm

\- for what purpose are you eating? to satisfy my hunger

~~~
icebraining
For what purpose only works if there is a purpose. "For what purpose are you
hungry" doesn't really work.

~~~
fwip
You can probably make up reasons. "To induce me to ingest nutrients" "To
provide me with energy" "To fulfill some biological imperative" is one
possible route.

------
mesozoic
Pretty valid reasoning it seems though it doesn't provide much in the way of
alternatives.

------
gowld
Why does HN consistently upvote ill-iformed poor analyses to the front page?

------
peter_d_sherman
The article summarized: Basically, for any given event, there may be two or
more "whys" which feed into it, which in turn may have have two or more "whys"
which feed into it.

We see this pattern in databases, where there are 1..n relationships out of
something, or, in reverse, n..1 relationships into something.

The "5 Whys" described whys only as having a single cause feeding into each
successive cause. This article describes the problem with that, which is
simply that in the real world, a single result, a single "why", might have
multiple (1..n) causes feeding into it, and multiples into those.

Now... get ready to have your mind blown... Here's the "problem" with this
article (I know, this article makes more sense than the "five whys" alone, but
hear me out!)

Think of "The Five Whys" as level 1 reasoning and this article as level 2.

Level 2 is smarter because it considers more.

So what's level 3?

Level 3 then, which I think will be discovered (or at least expounded upon by
some person vastly brighter than myself), is using the level 2 method, and
expanding that set of predecessor causes even more to everything in life,
which theoretically should result in the observation that _everything is
circular_.

That is, all events, causes and circumstances -- eventually feed back on
themselves! Some to lesser degrees, some to greater degrees, but I think it
will be discovered that all causes move in circular loops, even though the
cause->effect->cause chain (or chains) might have thousands, perhaps hundreds
of millions of elements...

I think the ancient Greeks (well, some of them, the enlightened ones anyway)
had an understanding of this. I think that Shakespeare and Dante Alighieri
understood this, at least in terms of the human character.

Consider Toyota... If Toyota is asking "why" some failure occurred and tracing
it back 5 levels, then one might ask _" Why does Toyota have to make cars in
the first place?"_, because that sets the stage for all other "whys" that come
next...

Eventually, with enough "whys", everything has to be circular... You just need
to go enough why levels "deep" to see this. And some causes feed other causes
to lesser degrees, some to greater degrees.

And I believe that people in antiquity who were men of great learning...
somehow knew or intuited this... while not provable, it seems "logical"...

Loops inside of loops inside of loops... all with different loop lengths...

------
PaulHoule
This is also something I hear people talk about and never use.

~~~
robluxus
Do you have other examples? FWIW I find 5-why's useful for personal
introspection, but never found it very efficient in professional settings.

~~~
ken
I find it tremendously helpful with software -- but I also always include the
_user_ as a component of the system (e.g., in architecture diagrams), which
apparently isn't very common.

So rather than something technical like "process crashed", most of my
investigations begin with "user is frustrated because they did not accomplish
their task". Then my why-tree will have branches for, say, "the label on this
control was unclear", "there was no documentation for this feature", "it was
not clear how to get to the correct documentation page", "user was afraid to
click it -> because there was no Undo", "user didn't know this feature already
exists", etc.

Usually, I have to go a few questions deep before I get to a geeky technical
solution that can be solved by more programming. I'll typically come up with 4
to 6 actionable improvements, and half will be completely non-technical, and
most of the rest will be less than one line of code (e.g., to rearrange or
clarify).

Users don't like going to the effort of filing bug reports, so whenever
someone does, it's a good indicator to me that 10 or 100 other people also
failed at a similar task with my software, or will soon. Users are also
resourceful, and will try 2 or 3 ways to solve something, so if they
ultimately fail, it means the software failed at every path they tried. By
attacking every problem at multiple levels, it's possible to improve results
for a whole lot of people at once.

------
throw7
what was the solution to the washington monument/lincoln memorial
deteriorating? was it just using less harsh cleaning chemicals?

~~~
bluGill
Water. Chemists call water the universal solvent for a reason: is dissolves
nearly anything.

~~~
fwip
Including the Washington Monument? :P

~~~
bluGill
Given enough of it for enough time...

