[mrazomor]

I don't interpret it the same way as you.

My understanding of Munger's intent: find the issues and risks that you are not aware of, by looking at the project from a different perspective.

What Google X (and many others) do: do the most risky parts first, so you fail fast and minimize the wasted effort (save time and money by not doing the less risky parts first, in case the project is doomed).

[sdwr]

Its exactly the same thing, in that it guards against wishful thinking by making you finish your dinner before you have dessert.

[mrazomor]

I don't see it that way.

Munger gives a tool to identify new (yet unknown) risks. Seeking what needs to be addressed so that the project doesn't fail.

The other thing is a tool to help us deal with the known risks (derisking the project, identifying the complete blockers). Checking if the project is doomed, and should not receive more investment.

I see it as two very different things from the project management perspective.

[andyferris]

Don't you have to explore the first (theoretically) before designing and committing to the fail-fast stage?

It's an extension, not a distinct approach.

[mrazomor]

From your experience, what's usually done when new projects start?

What I've seen, people focus on the business requirements and only the obvious risks. That's for the regular projects.

I have seen Munger's proposal in practice. In form of intentionally breaking production (in a controlled manner) to uncover unknown issues (similar to Netflix's Chaos Monkey), and in form of think tanks with senior engineers who take time to think about potential reliability issues.

What Munger describes is exactly the latter approach. From my experience, it's done very rarely. And never in some companies. While Munger advocates to do it for every project.