Book Summary of How Big Things Get Done: The Surprising Factors That Determine the Fate of Every Project, from Home Renovations to Space Exploration and Everything In Between

How Big Things Get Done is a book that studies the success and failure of large scale projects and the factors that impact their outcomes. Here are some of my takeaways from the book.

• Failure is by Far the Default Outcome: Most projects fail and people tend to be way too optimistic. The two stats in the book that really drilled this point home for me were (1) Of the 16K projects that the author studied only 0.5% of them came in on time, on budget and with the promised benefit. This means that 99.5% failed in some major way. (2) When students were asked to predict, with 99% confidence, when they would be done with their midterm papers, they only actually hit that date 45% of the time.
• Good Planning is Involves Experimental Iteration: Good planning is key to project success. But planning is not a passive process, it is an active iterative process. In the case of Pixar they plan by doing storyboards of the movie with increasing levels of fidelity before they actually move into production. Good planning consists of iterative experimentation in a way that does not risk very much. In software this might mean prototyping and in engineering this may involve building a high quality model.
• Shorten Your Window of Execution: Once you enter the costly phase of a project in which you are either leveraging expensive human capital or using expensive resources you want to move as fast as possible. The period of expensive execution is a vulnerable time for your project because black swan events can derail your project and become very expensive. You want to execute quickly because you want to exit this period of vulnerability as fast as possible. Therefore, you want to spend lots of time in the low stakes planning phase and as little time in the high stakes execution phase as possible.
• One in a Million Events are the Default on Sufficiently Large Projects: Black swan events such as an earthquake, or a political change, or a worker strike or an health problem of a key worker are all unlikely events individually, but for sufficiently large and interconnected projects the aggregate probability of a black swan event becomes high. So you want to operate under the assumption that you are going to encounter these really bad rare events and plan accordingly. This is the main reason you want to execute quickly.
• Think Hard About One Way Door Decisions, and Bias For Action on Two Way Door Decisions: The tech sector encourages its employees to “bias towards action.” What this principle means is that builders should not get stuck in planning cycles and should just dive into building the thing. At first glance it might seem like this is at odds with the above bullets, but its really not. The reason is that in tech most decisions are fairly cheap to reverse and change course on. Unlike making a movie or constructing a bridge, writing code is generally not that expensive to start executing on. So often the best way to sharpen your “planning” in tech is just to start executing. But while the line between planning and executing in tech might be blurrier than some other industries, the principle of planning well and then executing quickly during the expensive period of a project still holds true in tech.
• Start with Why: Good planning starts by asking why questions. In order to keep a project on track and team members rowing in the right direction its important to have a strong conviction about where you are headed and why that is a good place to head towards. One awesome way I have seen this applied in my work is by writing a year end press release for a product in advance of actually building it. This defines a vision that motivates the team and acts as a guiding star.
• A Detailed Plan Does Not Imply a Good Plan: It is actually pretty easy to write a plan that looks detailed and well thought through, but actually misses a bunch of important concerns. The way you protect against this narrow detailed plan is to become obsessed with learning about your domain and to engage in intentional practice of your domain by pushing the boundaries of what you don’t know. A good plan will outline roughly how all the important parts of a problem will be solved, a bad but detailed plan will include impressive sounding understanding of a narrow part of the problem and neglect other important parts of the problem.
• Good Planning is Like Good Learning: Good planning looks a lot like good learning. It is an active, iterative, intentional process that pushes the boundaries of what you don’t know in pursuit of building deeper mental models.
• Don’t Go First (and Probably Don’t Go Second Either): The importance of the first mover advantage is overstated for large projects. As has been established, most big projects fail, so you don’t win by going first you win by executing better than others. In fact not being first can be an advantage because you get to learn how others have failed before you.
• Use Battle Tested Technology: Having an experienced team is a benefit to your project, but people are not the only thing that can be experienced — technology can also be experienced. Some pieces of technology are more battle tested than others. It can be tempting to reach for the new shinny technology to solve your problem, but often reaching for the older battle tested piece of technology is the better bet.
• Don’t Try to be Smart in Your Estimations: When estimating how long a large project will take don’t try to figure it out from first principles, and don’t assume your project is special. Instead, just look for other similarly shaped projects and assume your project will take about as long as other projects in its reference class did. It can be tempting to assume your project will go better than projects in the reference class or that you can estimate it more accurately by doing a bottom up time estimation, but this is human over-confidence bias — just taking the average of projects in the reference class will give you a better estimation.
• Get the Best People and Treat Them Well: People are not fungible, some people are way more qualified than others to execute on a given project. It can be tempting (especially for upper management) to treat head count as a fungible resource, but its not. Its important to get the most qualified people on the most important projects and treat them well because a great team will execute much better than a good team.
• Find Your Lego Block: Having an experienced team executing the project is important, but experience can also be built up during the execution of the project if its done right. If a large project is constructed out of small repeatable lego blocks rather than treating the whole project as a single monolithic thing, then the team will get progressively better at building/using that lego block over the project’s lifetime. This is one of the reason the construction of the Empire State Building was such a massive success — every floor is basically a copy of the one below it. So the team got progressively better at cranking out that single floor. Try to figure out how to deconstruct a project into a small lego block that you can just keep hammering out.