Intro
This was a pretty interesting book which was recommended to me by a friend colleague of mine at Rolls-Royce named Andy Yardley. Andy works on a nearby team and worked on a delivery project with our organization. We got to talking about both hard projects as well as books and he told me this was a good one that had made an impact on him. That is exactly the kind of recommendation which gets my notice so this went in my wishlist. I finally got to reading it last fall, and I'm only now getting around to writing up the review.
Main Concept
Throughout the book the authors discuss countless big projects that went well, or that fell apart. They gathered these from a one-of-a-kind database where they tracked information related to large projects, their costs, their outcomes, and their problems. They call this database the "Megaprojects Database". It includes 16,000 projects. Only 8.5% were delivered on-time, and only 0.5% delivered the expected benefits. Those are serious numbers and should make you pause if you were considering a new "large project" in your future.
Below I'll hit a few points that stuck out to me that (I think) will be useful later even when not trying to deliver large projects.
Think Slow, Move Fast
This is one of the biggest lessons in the book. The authors make the case for doing vastly more upfront work than you think you should. This upfront work includes not only planning, but things which are less obvious like: Part of that upfront planning needs to include getting commitment from the right people in the right way. Specifically, everyone needs to be onboard with the outcome, what the project will achieve, the value it should provide, and other key details.
Finding a leadership and execution team with real experience doing this kind of work.Validating your timeline and budget against other similar projects and with people who have relevant experience.Ensuring the planned project will actually deliver on the outcome expected. For instance, if the goal is to transport people, maybe a rail line isn't the only option.
By taking a lot of time upfront you can de-risk the whole project. This phase is relatively cheap, easy to iterate in, and isn't usually part of any project overruns. Once you finally get moving, however, you need to get moving!
Getting everyone on the project to pull together will very much predict the amount of success you reap. At this point the clock is ticking and it is critical that everything and everyone are pulling in the same direction; towards delivery.
You should be careful not to allow specifics to be part of this early commitment as that can lock the project into a bad direction too early. There are many examples of this described in the book.
You Aren't a Special Unicorn
The authors make this case using the language "So, you think your project is unique?" I like the unicorn phrasing as I often use it in meetings. People at work tend to act like our problems are unique, or that our organizational problems are unique. They aren't, pretty much without exception. The problems we're seeing have been not only been seen before, but often solved by someone else. I've found solving a problem can be as simple as naming it.
Back to the book, the authors make a strong case that the project you are delivering can be approximated to another class of project. Once part of a group, the models and lessons can be applied. This is useful as they have strong data to show that past experience in a project is an enormous predictor of future success.
Find Your Lego
The final point that stuck with me was the concept of finding a small reproducible block of delivery you can iterate on for efficiency gains. The authors show that some of the best projects are those where the delivery teams can deliver the same small thing over and over again. For instance, the Empire State Building was a well-run project. One of the reasons it went so smoothly was that every floor was a reproducible unit. The construction crews got incredibly efficient at building that one floor until every detail was optimized, simplified, and practiced. By the end of the project the building of a single floor became a choreographed ballet of people, steel, and materials.
The alternative of this Lego model is what they call "one big thing". Building something like a nuclear power plant is more of this kind of project. It would be rare for a single crew to get experience building many nuclear power plants simply because they take decades to build. It is hard to accumulate learning, efficiencies, and knowledge on projects where the whole project is "one big thing". In these projects, each step of delivery may only happen once.
Summary
Finally, the book summarizes the learning in a nice summary of 11 heuristics to keep in mind. As a general read I found this book fascinating, entertaining, and useful. Even if you don't deliver big projects as your full-time job, the heuristics and stories are worth it. It was also great to hear stories about famous projects which I had little understanding of. I'm not much of a project manager, but if I had to deliver a big project I would certainly be carrying a copy of this book with me every day.