3 ms·
> Or maybe several people are sluggish today because they’re sick. ... When the boulder falls, it means that the collection of processes weren’t able to compens
by xyzelement 5y ago
> Or maybe several people are sluggish today because they’re sick. ... When the boulder falls, it means that the collection of processes weren’t able to compensate for the disturbance. But there’s no single problem, no root cause, that you can point to.
Perhaps I agree with the idea in an academic way, but in practice seeking the deepest root cause possible is valuable.
OK - the boulder fell because enough people were sick that day.
How did we end up with a staffing policy that allowed this?
OH - because the person in charge of this is a junior manager
How did a junior manager get to be in charge?
OH - because our top leadership didn't realize how important this boulder is.
Oh - so the real thing we need to do is educate top leadership on how important this mission is. Then they will find a good leader for it. He will then design a robust staffing policy.
The point here is that this fixed other problems along the way - getting a better leader in place solves more than just this one instance of a problem.
I get it, it's all recursive systems of balancing the boulder all the way down. But in practice you can make things exponentially better by digging for the deepest root and fixing there.
- di4na 5y ago[Citation needed] cause the academic research on complex system safety disagree with the fact that doing what you said make the system better
- kqr 5y agoBut there is not "a deepest" root cause. It's a complex network of causality. By limiting yourself to one path of the network, and by restricting yourself to blaming the deepest politically acceptable thing to blame (this is what happens in practise) you're not fully exploring the network and you are bound to end up in a situation at least as expensive as a more thorough process that casts a wider net, e.g. a system-based causal analysis based on constraints and dynamic control structures. ---- If I had time, I'd type out the steps more explicitly, but important questions that an analysis process must raise: - Why is this rock here to begin with? Did it need to be before? Does it need to be now? - How far can we move it? - What do we do to salvage the situation when it tumbles down? - Why do we need people to hold it up? What other solutions were explored? Why were they rejected? Has the context changed? - Why isn't there a system that monitors how well the rock is held up? Why do we not have systems that warn about faltering assumptions, like cliff slippiness? - Can we make it cheaper to roll the rock back up? Etc. These questions come up when you dig wider, not deeper. Any process that doesn't produce (and ideally answer) these questions is suboptimal.
- xyzelement 5y agoI agree with the questions you're asking, in reality I'd ask those too but wanted to constrain my post to make a point. That point is, again, the attempt to get to root cause (whether you go deep or wide) is valuable. The idea that you won't get the ONE TRUE ANSWER shouldn't stop that effort. An organization that landed at either your or my answer is better off than one that landed at neither.
- kqr 5y agoWith that clarification, I think we agree on content, but disagree on terminology. "Root cause" tends, in my experience, to make people think of a singular causal path (sometimes even called a chain) which just... stops, at some convenient place. And this is "the root cause". I strongly oppose that picture of failure.
- rramadass 5y agoRelevant, Rasmussen's Model: https://medium.com/10x-curiosity/boundaries-of-failure-rasmussens-model-of-how-accidents-happen-58dc61eb1cf https://medium.com/10x-curiosity/boundaries-of-failure-rasmu... Be sure to watch Richard Cook's video presentation linked on that page.
- kqr 5y agoAnd I keep recommending the CAST Handbook, which completely changed the way I look at failure. It goes through a method by which you are prompted to dig wider and deeper. The author has graciously released it to the public for free, too! http://sunnyday.mit.edu/CAST-Handbook.pdf http://sunnyday.mit.edu/CAST-Handbook.pdf
- kqr 5y agoAdditional questions: - Was there another way to satisfy customer demand without balancing a rock on a hill? - Must the rock balance on the hill, or just a hill? Must it be the rock or just a rock? - What level of modifications would cause the hill to no longer count as the hill? What attributes would need to be transferred from the hill to another hill to make another hill count as the hill? - Does the rock have to be made of this material? Does it have to be this shape? - If the rock tumbles when no-one is looking, did it really tumble? - What regulatory bodies are concerned with this rock balancing act? What are their opinions on our performance? - Are records kept of our performance? Does it vary or is it constant? Is it acceptable? If not, why not? Who is responsible for this judgment, and who is responsible for ensuring our performance? What tools do they lack? - What are the operating procedures of the balancing team? Are they followed? Why not? Does circumstances require not following procedures? - Are people getting tired balancing? Why? Are there sufficient breaks? Why not? Do people need nutritious meals and are they getting it? - Who is responsible for updating operating procedures based on operational experience? Are workers' opinions on improvements taken seriously? - Are new people receiving sufficient training? Why not? Who is responsible for training? What qualified them for that? - Does the culture value successful rock balancing? Does management? Is the motivation there? What are the levels of absenteeism? Why not? Why? - Does communication between workers happen? Do they have a shared language? Are misunderstandings common? Why? ---- There's just so many things that can (and do) go wrong, and so much that needs to be clarified in regards to how the system works that blindly strolling down a single "causal chain" is bordering on malpractice.