6 ms·

It's also worth pointing out that you may not be able to fix the root cause. The sailing example is great here: - Can you fix the crack in your hull whilst you

It's also worth pointing out that you may not be able to fix the root cause. The sailing example is great here: - Can you fix the crack in your hull whilst you're out at sea? Almost certainly not. - Can you even tell you have a crack in the hull until you've reduced the water in the bilges by running the pumps for a time? Again, quite possibly not. Treating the symptom is really the only sensible option, unless it's serious enough that you need to put out a Mayday. Again, not a course of action that addresses the root cause but, in some situations, absolutely the right thing to do. To take things up many, many notches, the sinking of the Titanic was an appalling tragedy from which relatively few people were saved, but I guarantee that nobody at all would have been saved if the people on the ship had opted for a series of committee meetings about how to solve the problem of the iceberg. (Not to say there weren't a very large number of hideous blunders in the management of that situation going all the way back to the ship's design and fit-out.) Moreover, another problem with Five Whys is that, applied heedlessly, it's an extraordinarily arrogant philosophy, because it makes the assumption that you can know the answer to those five whys. Often you can't, at least not without going on a journey, and fixing a few things along the way, and without that, you can simply be wasting your time trying to answer questions that you can't answer in your present situation. And that really, and somewhat poignantly, cuts to the root cause of why I view the kind of thinking frameworks/fads popular in business with a degree of scepticism: over-applied or misapplied, they paralyse people into inaction, and thereby provide fertile stock for breeding mediocrity.

taeric 8y ago
Just want to agree with you. Treating the symptom during an event really is about the best you can do. I'll also agree with the "you may not be able to know a why." For systems, that can be a good guide on instrumentation to add. Sucks, in that you won't prevent the next event. Good that you should be able to get more from it.
williamdclt 8y ago
The 5 Whys is just meant as a simple tool easy to use, of course it won't solve your big picture problems and nobody is questionning that. You're raising a strawman. Any methodology applied heedlessly will lead to bad result.
- ljw1001 8y ago
  This is exactly right. It was meant for people with (a) a high school education to (b) fix problems in a repetitive manufacturing process where if you don't fix the problem on this car, it will appear again on the next car, and the one after that. If your damn boat is sinking, you should just get to safety ASAP, but if you're in the boat making business, it may be of some interest to know why your hulls are cracking.
  - Retric 8y ago
    Your missing the point, if some critical piece of equipment is out of alignment and you fix that then the next car is not going to have an issue. Five why's is about avoiding the next case of a piece of equipment being out of alignment not the current case. You can have a reasonable policy of waiting 3 weeks before doing 5 why's so you have a better understanding of what's going on.
roenxi 8y ago
If you get the iceburg as a root cause then you are really doing something wrong; in fact I would suggest the point of a 5-Whys would be to move people past thinking that the iceburg is the problem and get to the actual root cause :P. Why is the ship sinking? Hit an Iceburg. Why did we hit an iceburg? [Equipment or command failure] What is wrong with [maintenance strategy/command structure] that allowed this mistake to slip through? [technical details] If you have a team of people and something goes wrong, it is overwhelmingly likely that a human could make a decision differently or do some task that is not being done that would mitigate the worst of the damage. People absolutely are saved by the committee process, in the same way that items tend to roll downhill. Pretending that humans have perfect control over their environment and could have done something more has proven remarkably successful at getting results. It isn't very impressive, it feels very unreasonable, and it isn't going to work on its own, but it is a very useful tool to let people to stand up and ask "sure something is going on that is out of our control, so why aren't we ready for it? This happens sometimes and we need to be prepared". Basically, if you just ask why 5 times without any sense of personal responsibility you'll get stupid results. True of any process. But if an uncontrollable event has impacted your endeavor, it is absolutely worth asking "why are we exposing ourselves to a risk we can't control? could we somehow have avoided this".
- jjoonathan 8y ago
  Exactly which part of this is supposed to help the ship that just hit an iceberg and is in the process of sinking? If your answer is "the relevant committee would have met before the accident" or "the committee would reduce / mitigate future accidents," you have missed GP's point.
  - Moto7451 8y ago
    Root Cause Analysis isn’t really meant for active emergencies like that where you can’t take time to analyze “why”. It’s a retrospective tool. If you’d like a mental model in your toolbox for an active emergency the OODA loop[0] is well tested. RCA is good for figuring out how to keep others out of the mess you’re in after the fact. [0] https://www.fs.blog/2018/01/john-boyd-ooda-loop/ https://www.fs.blog/2018/01/john-boyd-ooda-loop/
CPLX 8y ago
Much depends on context. If you're the captain of the Titanic it doesn't make sense to focus on the iceberg as the root cause. If you're the CEO of White Star lines it certainly does.
jdietrich 8y ago
The tech industry is badly re-inventing processes that the rest of the world developed decades ago. Other industries have learned to deal with far more complex and serious issues of quality. If there is arrogance in our approach, it's our failure to learn from other industries; lots of people in the tech industry have heard of the Five Whys, but very few have actually read Taiichi Ohno's Workplace Management, W. Edwards Deming's Out Of The Crisis or Walter A. Shewhart's Economic Control of Quality of Manufactured Product. I frequently recommend this lecture on the Piper Alpha disaster, a fire on an offshore oil rig that killed 167 men. It eloquently summarises the findings of the Cullen Enquiry, a six month study of exactly why the disaster happened and what could be done to improve safety in the offshore industry. The enquiry found a complex and interconnected set of factors encompassing process, training, culture and design. It is densely packed with lessons that can be applied to our industry, not least of which is the idea of conducting intensive and systematic inquiries into major failures. https://www.youtube.com/watch?v=S9h8MKG88_U https://www.youtube.com/watch?v=S9h8MKG88_U
- dano 8y ago
  Thank you for this very considered response - I've enjoyed all of those books! There is a tendency to read secondary sources that are presented in a current consumable format. Rare is it that someone has read the primary sources or even referenced them. As a gentle introduction to the impact of engineering for quality, I give people copies James P. Womack and Daniel T. Jones's The Machine That Changed the World : The Story of Lean Production. If this leads to questions for further study, I point them to Ohno and Deming. As for the topic of this thread, Root Cause analysis is only one method of problem solving and other systemic methods may be more appropriate depending on the issue. For a thorough and in-depth treatise on critical thinking and methods, one could read Problem Solving, Decision Making, and Professional Judgment by Paul Brest and Linda Hamilton Krieger. They provide examples of many decision making frameworks, cognitive biases, in a readable format. I did appreciate the link to the Piper Alpha resource. For another read along these lines there is the BEA Air France 447 disaster final report. https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp090601.en.pdf https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp09060...

taeric 8y ago

Just want to agree with you. Treating the symptom during an event really is about the best you can do. I'll also agree with the "you may not be able to know a why." For systems, that can be a good guide on instrumentation to add. Sucks, in that you won't prevent the next event. Good that you should be able to get more from it.

williamdclt 8y ago

The 5 Whys is just meant as a simple tool easy to use, of course it won't solve your big picture problems and nobody is questionning that. You're raising a strawman. Any methodology applied heedlessly will lead to bad result.

ljw1001 8y ago
This is exactly right. It was meant for people with (a) a high school education to (b) fix problems in a repetitive manufacturing process where if you don't fix the problem on this car, it will appear again on the next car, and the one after that. If your damn boat is sinking, you should just get to safety ASAP, but if you're in the boat making business, it may be of some interest to know why your hulls are cracking.
- Retric 8y ago
  Your missing the point, if some critical piece of equipment is out of alignment and you fix that then the next car is not going to have an issue. Five why's is about avoiding the next case of a piece of equipment being out of alignment not the current case. You can have a reasonable policy of waiting 3 weeks before doing 5 why's so you have a better understanding of what's going on.

roenxi 8y ago

If you get the iceburg as a root cause then you are really doing something wrong; in fact I would suggest the point of a 5-Whys would be to move people past thinking that the iceburg is the problem and get to the actual root cause :P. Why is the ship sinking? Hit an Iceburg. Why did we hit an iceburg? [Equipment or command failure] What is wrong with [maintenance strategy/command structure] that allowed this mistake to slip through? [technical details] If you have a team of people and something goes wrong, it is overwhelmingly likely that a human could make a decision differently or do some task that is not being done that would mitigate the worst of the damage. People absolutely are saved by the committee process, in the same way that items tend to roll downhill. Pretending that humans have perfect control over their environment and could have done something more has proven remarkably successful at getting results. It isn't very impressive, it feels very unreasonable, and it isn't going to work on its own, but it is a very useful tool to let people to stand up and ask "sure something is going on that is out of our control, so why aren't we ready for it? This happens sometimes and we need to be prepared". Basically, if you just ask why 5 times without any sense of personal responsibility you'll get stupid results. True of any process. But if an uncontrollable event has impacted your endeavor, it is absolutely worth asking "why are we exposing ourselves to a risk we can't control? could we somehow have avoided this".

jjoonathan 8y ago
Exactly which part of this is supposed to help the ship that just hit an iceberg and is in the process of sinking? If your answer is "the relevant committee would have met before the accident" or "the committee would reduce / mitigate future accidents," you have missed GP's point.
- Moto7451 8y ago
  Root Cause Analysis isn’t really meant for active emergencies like that where you can’t take time to analyze “why”. It’s a retrospective tool. If you’d like a mental model in your toolbox for an active emergency the OODA loop[0] is well tested. RCA is good for figuring out how to keep others out of the mess you’re in after the fact. [0] https://www.fs.blog/2018/01/john-boyd-ooda-loop/ https://www.fs.blog/2018/01/john-boyd-ooda-loop/

CPLX 8y ago

Much depends on context. If you're the captain of the Titanic it doesn't make sense to focus on the iceberg as the root cause. If you're the CEO of White Star lines it certainly does.

jdietrich 8y ago

The tech industry is badly re-inventing processes that the rest of the world developed decades ago. Other industries have learned to deal with far more complex and serious issues of quality. If there is arrogance in our approach, it's our failure to learn from other industries; lots of people in the tech industry have heard of the Five Whys, but very few have actually read Taiichi Ohno's Workplace Management, W. Edwards Deming's Out Of The Crisis or Walter A. Shewhart's Economic Control of Quality of Manufactured Product. I frequently recommend this lecture on the Piper Alpha disaster, a fire on an offshore oil rig that killed 167 men. It eloquently summarises the findings of the Cullen Enquiry, a six month study of exactly why the disaster happened and what could be done to improve safety in the offshore industry. The enquiry found a complex and interconnected set of factors encompassing process, training, culture and design. It is densely packed with lessons that can be applied to our industry, not least of which is the idea of conducting intensive and systematic inquiries into major failures. https://www.youtube.com/watch?v=S9h8MKG88_U https://www.youtube.com/watch?v=S9h8MKG88_U

dano 8y ago
Thank you for this very considered response - I've enjoyed all of those books! There is a tendency to read secondary sources that are presented in a current consumable format. Rare is it that someone has read the primary sources or even referenced them. As a gentle introduction to the impact of engineering for quality, I give people copies James P. Womack and Daniel T. Jones's The Machine That Changed the World : The Story of Lean Production. If this leads to questions for further study, I point them to Ohno and Deming. As for the topic of this thread, Root Cause analysis is only one method of problem solving and other systemic methods may be more appropriate depending on the issue. For a thorough and in-depth treatise on critical thinking and methods, one could read Problem Solving, Decision Making, and Professional Judgment by Paul Brest and Linda Hamilton Krieger. They provide examples of many decision making frameworks, cognitive biases, in a readable format. I did appreciate the link to the Piper Alpha resource. For another read along these lines there is the BEA Air France 447 disaster final report. https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp090601.en.pdf https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp09060...