Key Insights from "How Big Things Get Done" by Bent Flyvbjerg
- Reference Class Forecasting: Comparing projects to similar past projects improves forecasting accuracy.
- "Think Fast, Act Slow" vs. "Think Slow, Act Fast": Failed projects tend to drag on, while successful ones progress quickly to completion.
- Project Planning and Execution: Projects often start wrong, with optimism leading to unrealistic forecasts and poor planning.
- Importance of Asking "Why?": Projects should start with questions and consideration of alternatives rather than jumping straight to solutions.
- Customer-Centric Approach: Starting with the customer experience and working backward leads to successful projects.
- Learning from Experience: Understanding that projects are often not unique helps in forecasting and managing risks.
- Modularity and Repetition: Breaking projects down into basic building blocks enables experimentation and improvement.
- Hiring the Right Team: A great team can turn a mediocre idea into success, emphasizing the importance of team selection.
- Continuous Improvement: Success isn't just about winning but also about avoiding losses and learning from mistakes.
Improve Forecasting by having a reference class
The book discusses the importance of having a reference class to compare your project to. This can help in forecasting and understanding the scope of the project. Rather than just thinking about the project in isolation, having a reference class can provide valuable insights. For example, if you are building a new bridge, you can compare it to other similar bridge projects to understand the challenges and timelines involved. If you are building a new software product, you can compare it to other software projects to get a sense of the effort and resources required. Let's take an example of a website, you can compare it to other websites that have similar features and functionalities to get a sense of the time and resources required.
So if it's a finance project, you can compare it to other finance projects. If it's a marketing project, you can compare it to other marketing projects. Having a reference class can help in improving forecasting and understanding the scope of the project. Then if you see that all finance projects take 6 months to complete, you at least have that as a baseline.
Key outcome for Cub
We need to have a database of reference class projects that we can use to compare our projects to. This can help in improving forecasting and understanding the scope of the project. We can start by creating a database of past projects and categorizing them based on the type of project, industry, and complexity. This can help in identifying patterns and trends that can be used to improve forecasting and planning. We can also use this database to benchmark our projects against similar projects and identify areas for improvement. This can help in improving the efficiency and effectiveness of our projects and ensure that we deliver high-quality results on time and within budget.
The project dragged on and on. I call this pattern “Think fast, act slow,” for reasons I’ll explain later. It is a hallmark of failed projects.
Successful projects, by contrast, tend to follow the opposite pattern and advance quickly to the finish line. That’s how the Nepal schools project unfolded. So did the Hoover Dam, which was completed a little under budget in fewer than five years—two ahead of schedule. Boeing took twenty-eight months to design and build the first of its iconic 747s. Apple hired the first employee to work on what would become the legendary iPod in late January 2001, the project was formally approved in March 2001, and the first iPod was shipped to customers in November 2001. Amazon Prime, the online retailer’s enormously successful membership and free shipping program, went from a vague idea to a public announcement between October 2004 and February 2005. The first SMS texting app was developed in just a few weeks. Then there’s the Empire State Building.
In a 1931 publication, the corporation boasted that before any work had been done on the construction site “the architects knew exactly how many beams and of what lengths, even how many rivets and bolts would be needed.
At the height of construction, the pace hit a story a day.
The Empire State Building had been estimated to cost $50 million. It acually cost $41 million
I call the pattern followed by the Empire State Building and other successful projects “Think slow, act fast.”
“Project estimates between 1910 and 1998 were short of the final costs an average of 28 percent,”
In total, only 8.5 percent of projects hit the mark on both cost and time. And a min-uscule 0.5 percent nail cost, time, and benefits. Or to put that another way, 91.5 percent of projects go over budget, over schedule, or both And 99.5 percent of projects go over budget, over schedule, under benefits, or some combination of these.
Wealth, for example, is fat-tailed. At the time of writing, the wealthiest person in the world is 3,134,707 times wealthier than the average person. If human height followed the same distribution as human wealth, the tallest person in the world would not be 1.6 times taller than the average person; he would be 3,311 miles (5,329 kilometers) tall, meaning that his head would be thirteen times farther into outer space than the International Space Station.
18 percent of IT projects have cost overruns above 50 percent in real terms. And for those projects the average overrun is 447 percent!
Or consider what another IT blowout did to the legendary jeans maker Levi Strauss: Originally forecast to cost $5 million, the project forced the company to take a $200 million loss and show its CIO the door.
Why is that? Think of the duration of a project as an open window. The longer the duration, the more open the window. The more open the window, the more opportunity for something to crash through and cause trouble, including a big, bad black swan.
Of course, a project can’t be completed instantly, so we can’t close the window entirely. But we can make the opening radically smaller by speeding up the project and bringing it to a conclusion faster. That is a main means of reducing risk on any project. In sum, keep it short!
PROJECTS DON’T GO WRONG, THEY START WRONG
Unchecked, optimism leads to unrealistic forecasts, poorly defined goals, better options ignored, problems not spotted and dealt with, and no contingencies to counteract the inevitable
Instead, as Klein demonstrated, people ordinarily take the first option that occurs to them and quickly run it through a mental simulation. If it seems to work, they go with that option. If it doesn’t, they search for another and repeat the process.
HOFSTADTER’S LAW Forty years ago, Kahneman and Tversky showed that people commonly underestimate the time required to complete tasks even when there is information available that suggests the estimate is unreasonable. They called this the “planning fallacy,”
Planning is working on the project. Progress in planning is progress on the project, often the most cost-effective progress you can achieve.
If you feel the urge to commit—and you probably will—commit to completing that process before you draw conclusions about your big project.
Projects are often started by jumping straight to a solution, even a specific technology. That’s the wrong place to begin. You want to start by asking questions and considering alternatives. At the outset, always assume that there is more to learn. Start with the most basic question of all: Why?
With no motive but curiosity, he explores the client’s needs, aspirations, fears, and everything else that has brought them to his door. The whole conversation starts with a simple question: “Why are you doing this project?”
Projects are not goals in themselves. Projects are how goals are achieved.
Developing a clear, informed understanding of what the goal is and why—and never losing sight of it from beginning to end—is the foundation of a successful project.
“You’ve got to start with the customer experience and work backwards to the technology,” Steve Jobs told the audience at Apple’s 1997 Worldwide Developers Conference. “You can’t start with the technology and try to figure out how you’re going to try to sell it. I made this mistake probably more than anybody in this room, and I’ve got the scar tissue to prove it.” Today, “work backwards” is a mantra in Silicon Valley.
To pitch a new project at Amazon, you must first write a PR and FAQ, putting the goal smack in the opening sentences of the press release. Everything that happens subsequently is working backwards from the PR/FAQ, as it is called at Amazon.
Projects are pitched in a one-hour meeting with top executives. Amazon forbids PowerPoint presentations and all the usual tools of the corporate world, so copies of the PR/FAQ are handed around the table and everyone reads it, slowly and carefully, in silence. Then they share their initial thoughts, with the most senior people speaking last to avoid prematurely influencing others.
The construction of the Sydney Opera House was an outright fiasco. Setbacks piled up. Costs exploded. Scheduled to take five years to build, it took fourteen. The final bill was 1,400 percent over the estimate, one of the largest cost overruns for a building in history.
“In our practice, we don’t allow the client to start construction until we are sure we are doing a building that’s within their budget and meets their requirements. We use all the technology available to us to quantify in the most precise way the elements of the build so there’s not a lot of guessing,” he told me.
“I want to guarantee that we can build that vision. And I want to guarantee that we can build it at a price that the owner can afford.”
Planning, as I see it, is not merely sitting and thinking, much less a rule-based bureaucratic exercise of programming. It is an active process. Planning is doing: Try something, see if it works, and try something else in light of what you’ve learned.
Similar large-scale IT projects continue to be deeply troubled. Planners don’t value experience to the extent they should because they commonly suffer yet another behavioral bias, “uniqueness bias,” which means they tend to see their projects as unique, one-off ventures that have little or nothing to learn from earlier projects. And so they commonly don’t.
But the first-mover advantage is greatly overstated. In a watershed study, researchers compared the fates of “pioneer” companies that had been the first to exploit a market and “settlers” that had followed the pioneers into the market. Drawing on data from five hundred brands in fifty product categories, they found that almost half of pioneers failed, compared to 8 percent of settlers. The surviving pioneers took 10 percent of their market, on average, compared to 28 percent for settlers. Getting into the market early was indeed important—“early market leaders have much greater long-term success,” the researchers noted—but those “early” market leaders “enter an average of 13 years after pioneers.
Better to be—like Apple following Blackberry into smartphones—a “fast follower” and learn from the first mover.
Highly experienced project leaders like Frank Gehry and Pete Docter overflow with tacit knowledge about the many facets of the big projects they oversee. It improves their judgment profoundly. Often, they will feel that something is wrong or that there is a better way without quite being able to say why. As a large research literature shows, the intuitions of such experts are, under the right conditions, highly reliable.
SO YOU THINK YOUR PROJECT IS UNIQUE? Think again. Understanding that your project is “one of those” is key to getting your forecasts right and managing your risks.
You just need to start over with a different perspective: See your project as one in a class of similar projects already done, as “one of those.” Use data from that class—about cost, time, benefits, or whatever else you want to forecast—as your anchor. Then adjust up or down, if necessary, to reflect how your specific project differs from the mean in the class. That’s it. It couldn’t be simpler.
Daniel Kahneman wrote in Thinking, Fast and Slow that using reference-class forecasting is “the single most important piece of advice regarding how to increase accuracy in forecasting through improved methods.”
But if the project’s time and cost had been forecast using renovations of old New York homes as the reference class, the frequency and severity of such nasty surprises would have been encoded into the data. As a result, the estimated cost and time would have accounted for unknown unknowns that can’t be predicted.
cub to build a reference class database, tagging how long all of our projects have taken to build
BAA understood, as so many others do not, that “lowest bid” does not necessarily mean “lowest cost,”
Decommissioning Monju is expected to take another thirty years and cost a further $3.4 billion. If that forecast proves more accurate than the rest, the project will have taken sixty years, cost more than $15 billion, and produced zero electricity.
The core of modularity is repetition. Put down one Lego block. Snap on another. And another. And another. Repeat, repeat, repeat. Click, click, click. Repetition is the genius of modularity; it enables experimentation.
What is our basic building block, the thing we will repeatedly make, becoming smarter and better each time we do so? That’s the question every project leader should ask. What is the small thing we can assemble in large numbers into a big thing?
In The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger, the definitive history of containerization, the economist Marc Levinson argued compellingly that the humble shipping container was nothing less than a major cause of globalization.
HIRE A MASTERBUILDER I sometimes say that this is my only heuristic because the masterbuilder—named after the skilled masons who built Europe’s medieval cathedrals—possesses all the phronesis needed to make your project happen. You want someone with deep domain experience and a proven track record of success in whatever you’re doing, whether it’s a home renovation, a wedding, an IT system, or a skyscraper.
GET YOUR TEAM RIGHT This is the only heuristic cited by every project leader I’ve ever met. Ed Catmull explained why: “Give a good idea to a mediocre team, and they will screw it up. Give a mediocre idea to a great team, and they will either fix it or come up with something better. If you get the team right, chances are they will get the ideas right.” But who should pick the team? Ideally, that’s the job of a masterbuilder. In fact, it’s the masterbuilder’s main job.
A rider in the grueling three-week Tour de France bicycle race explained that participating is not about winning but about not losing, each day for twenty-one days. Only after that can you consider winning.
“I’m actually as proud of the things we haven’t done as the things we have done.