I don't really agree. The model you describe presupposes a functional framework for decision making -- constraints are in place and respected; controls exist, e

I don't really agree. The model you describe presupposes a functional framework for decision making -- constraints are in place and respected; controls exist, etc. Most of the time the result of the Whys process is, in my experience: "oh, we really need a framework for constraints/controls/etc around this". I guess it looks very different depending on the business you're in and how codified everything already is. If you're investigating failures in, say, a manufacturing process, everything is pretty rigid already and you're finding problems with the rules you already have. If you're investigating failures in a hodgepodge software engineering organization, the problem is that there is no rigidity in the first place, and those processes need to be created from scratch. I'm mostly familiar with the latter, and usually the result of whatever you come up with is a place where leadership ought to be directly applied. (I'd hazard to claim that: if you do a 5-Whys in an organization and the leader of the organization doesn't see something that they can go fix directly -- not by delegating but by leading, themselves -- either you did it wrong, or they're a bad leader.)