MegaProjects

Why do mega projects constantly have cost overruns and hardly ever finish on time? For an incisive and insightful analysis, I recommend How Big Things Get Done by Bent Flyvbjerg and Dan Gardner. Flyvbjerg is probably the leading authority on mega projects and his organization maintains probably the only useful database that classifies projects into categories such as building hydroelectric dams, airports, pipelines, and even hosting the Olympic Games. The book is short, engaging, and organized according to key takeaways.

 

I learned that nuclear power and storage have the worst overruns. The Olympic Games and large IT projects are also in that mix. The best cases are solar and wind farms. Why is that? The authors argue that a key ingredient to reducing the overrun problem is having lots of modularity; their catchphrase is “build with Lego”. The advantage of a modular approach is that you can quickly and systematically improve the process as you move along. It’s partly why the Empire State building is one of the few skyscrapers that finished on time at lower than the projected cost.

 

But modularity isn’t enough, you need an overseer with a lot of experience in the field – a “master builder”. And there needs to be a great team doing the work. It’s why the best contractors bring in their own experienced teams, people they trust and they’ve worked with on other projects. The planning phase is also essential. It’s so crucial that the authors spend the first chapter hammering this point, and repeating it in subsequent chapters. When you plan and simulate in detail, you can eliminate many (but not all) potential problems that may arise. Then you execute swiftly – because dragging out the time frame when actual physical work is being done increases the problem of a “black swan” occurrence – a global pandemic, for example. The authors’ catchphrase: “Think Slow, Act Fast”.

 

My industry is higher education. I’m not building anything physical so at first glance it doesn’t seem like much of this would apply. I’m trying to help students build abstract knowledge so they can apply it, but I can’t look into their minds so I don’t really know if they’re learning or not until I assess that knowledge. Even then, my assessments may not provide me sufficiently valid inferences. A chapter in the book reminded me how to ask “why?” to any project. I have a tendency to quickly think up solutions and actions to a perceived problem without stepping back and asking the why questions to get at the heart of the matter – like a good detective should (I’ve been watching old TV police procedurals.) The vague “I want my students to learn better” is the ultimate goal but I need to drill down a little more into the details of why a particular activity or curricular goal is appropriate. That’s a lot of planning work!

 

I was once involved in a building project, except I was a partial contributor to the cost overrun. I was part of starting up a new liberal arts college outside the U.S. where such institutions are rare. As a faculty member, my main focus was building the curriculum, but somehow I got dragged into becoming the college’s building liaison to the architects because of poor planning before I arrived. By the time I saw the plans for the woefully inadequate science facilities, foundations were being laid. Every suggested modification made would increase the cost and time overrun. I didn’t understand the politics surrounding the different stakeholders, I didn’t have any experience, but the architects on the ground kept coming to me because I was available. So I learned fast. There were many compromises made. I tried my best on a tight timeline, but I can’t say I did very well.

 

As to the non-physical parts of starting up a new college, I can see many parallels to the good advice given in How Big Things Get Done. It was a big project. The most experienced overseer left before I joined. When I arrived, I found a mixed team – certainly not the best, and most of us lacked experience, myself included. Planning was rushed and inadequate. While initially hired as a faculty member, I quickly found myself becoming an administrator. Much of my time was spent anticipating problems coming down the pipeline so I could get ahead of them. It was exhausting. I left after eighteen months. I knew nothing about big projects and I had little preparation and insufficient experience. Trial by fire. I’ve learned a lot since then. If I ever get the chance to work on another big project, I’d be more wary, less idealistic, and most importantly much better prepared.