Balenet

Book notes: How big things get done

Image.tiff

I read "How Big Things Get Done" over the Summer holidays. It's a relatively new book (published in 2023) that explores why large-scale projects often fail to meet expectations in terms of time, cost, and quality, and how to improve outcomes in such ventures. The authors draw on extensive research, including case studies from various industries like construction, technology, and entertainment.

As I was reading the book, I thought about my experience with projects large and small. Sadly most of them failed in one way or another, but I can find consolation in the fact that many of the reasons were listed in this book. I reflect on some of these projects in the rest of this post.

Takeaways

  1. Project are not late, they are estimated wrongly. Many large projects fail because of over-optimism and underestimation of time, costs, and risks. Often, an estimate starts by anchoring to a wrong number, such as the time available, and it’s difficult to move away from it afterwards.
  2. Think Slow, Act Fast: The authors advocate for thorough and careful planning ("think slow") before execution, but once the planning is complete, move quickly and decisively ("act fast"). Often, there is a rush to commit to a project without doing proper analysis, which leads to poor planning. Typically this happens because of politics, when a decision to proceed comes from some political need, such as making management happy. I have seen this many times over: projects that just "need to be done" are estimated optimistically because if the true cost was known, they would never get started.
  3. Start from the right: be clear about what the project wants to achieve and why, and what success will look like. This is similar to "Begin with why", "Begin with the end in mind", "Work backwards". If there is one "first principle" of project management it's this, and it's also the most easily ignored. This is what "vision" is all about.
  4. Experiment: you get better estimates by trying to build the thing you want to build, in the cheapest and fastest way possible, e.g. by using computer simulation or rapid prototyping. For example at Pixar, a movie is first put together as a sequence of hand-drawn sketches with voiceovers.
  5. Hire a master builder: If you are building something big, it helps if you have done it before. Ideally, you should hire someone who has led a similar project before, no matter how much they cost, and they will probably take their team of builders with them.
  6. Learn from the Past: Historical data and case studies are invaluable. Learning from past successes and failures can help in better forecasting and avoiding common pitfalls in project management. Using the technique called Reference Class Forecasting will lead to better estimates. Always assume that your project will take as long as the average, if not more.
  7. The importance of a committed team for flawless execution: in order to "act fast" you need a team that believes in the project, is committed to get it done and works well together. Building such a team is critical for a project's success.

My experience

The important of experience was very visible at Nokia while building Meego: we had two projects going on, one was the N900 and the other what became the N9. To speed things up the two were run in parallel, but this way none of the experience, nor the experienced people, of one could be used in the other.

I have never seen historical data used in any of the projects I've been involved with, and I think it comes partly from lack of data, and partly from the fallacy that every project is unique: it isn't, and any difference from the norm will just make it take longer.

I've been in many projects where the team was skeptical and cynical, and it showed.

One principle that didn’t stick with me is "modularity". This is not modularity in the software sense, where things are decomposed in independent blocks that can be reused, but rather building a bigger thing by putting many small, almost identical building blocks. For example a school made of classrooms, or a residential area made of similar houses. The thesis is that as you build these modules over and over again, you get better at it. This however doesn't apply to the software industry IMO, where there is no production and all the problems are in the "design" phase.

Side track: when reading about Reference Cost Forecasting, I started thinking whether LLMs could help with distilling historical data. One could train a model using data from past projects, and describe the new project to the LLM to estimate its duration.

Conclusion

I find huge projects fascinating and mysterious, especially in domain like construction and space travel. This book didn't really remove the mystery, but I'm glad I read it. Its lessons come from other fields than software developement, but they are applicable nonetheless. I have found many of them to be true based on my experience.