Megaproject management

Me­gapro­ject man­age­ment is a new-ish sub­field of pro­ject man­age­ment. Origi­nally con­sid­ered to be the spe­cial case of pro­ject man­age­ment where the bud­gets were enor­mous (billions of dol­lars), it is de­vel­op­ing into a sep­a­rate spe­cial­iza­tion be­cause of the high com­plex­ity and tra­di­tion of failure among such pro­jects. The driv­ing force be­hind treat­ing it as a sep­a­rate field ap­pears to be Bent Flyvb­jerg, pre­vi­ously known around here for Refer­ence Class Fore­cast­ing as the first per­son to de­velop an ap­plied pro­ce­dure. That pro­ce­dure was mo­ti­vated by megapro­jects.

I will make a sum­mary of the pa­per “What you should know about megapro­jects, and why: an overview” from 2014. For ca­sual read­ing, there is an ar­ti­cle about it from the New Yorker here.

History

Me­gapro­jects got their name from the as­so­ci­a­tion of mega with big, so think mega-city rather than mega-joule. It did match the unit pre­fix in the be­gin­ning how­ever, as such pro­jects were mostly dams, bridges, or very large build­ings in the early 20th cen­tury.

The next shift up­ward took place with the Man­hat­tan Pro­ject and then the Apollo pro­gram, which are also fre­quently drawn on as pos­i­tive ex­am­ples. The term ‘megapro­ject’ picked up steam in the 1970s, at the same time pro­ject costs crossed over into the billions.

Cur­rently pro­ject costs of 50-100 billion are com­mon, with even larger pro­jects less com­mon but not rare. If you were to view cer­tain things which need ded­i­cated man­age­ment as a pro­ject, like the stim­u­lus pack­ages from 2008 or US defense pro­cure­ment, then we have crossed over into the trillions and are en­ter­ing a ‘tera era’ of megapro­jects.

Ig­nor­ing these spe­cial cases, but count­ing in­fras­truc­ture and in­dus­tries where billion dol­lar pro­jects are com­mon, megapro­jects ac­count for ~8% of global GDP.

Four Sublimes

Th­ese are four rea­sons which drive the pop­u­lar­ity of megapro­jects. They are kind of a group bias for each type of stake­holder. They are:

  • Tech­nolog­i­cal sub­lime: be­cause en­g­ineers and tech­nol­o­gists love mak­ing the newest/​tallest/​fastest things.

  • Poli­ti­cal sub­lime: be­cause poli­ti­ci­ans love be­ing able to as­so­ci­ate with huge pro­jects and the pub­lic­ity that comes with them.

  • Eco­nomic sub­lime: be­cause unions, con­trac­tors, and busi­ness peo­ple love all the jobs and fees.

  • Aes­thetic sub­lime: be­cause de­sign­ers love mak­ing beau­tiful things, and the pub­lic loves to adopt big beau­tiful things as dis­tinc­tive for their city/​coun­try.

Pre­dictably with bi­ases, there are side effects:

The fol­low­ing char­ac­ter­is­tics of megapro­jects are typ­i­cally over­looked or glossed over when the four sub­limes are at play and the megapro­ject for­mat is cho­sen for de­liv­ery of large-scale ven­tures:
1. Me­gapro­jects are in­her­ently risky due to long plan­ning hori­zons and com­plex in­ter­faces (Flyvb­jerg, 2006).
2. Often pro­jects are led by plan­ners and man­agers with­out deep do­main ex­pe­rience who keep chang­ing through­out the long pro­ject cy­cles that ap­ply to megapro­jects, leav­ing lead­er­ship weak.
3. De­ci­sion-mak­ing, plan­ning, and man­age­ment are typ­i­cally multi-ac­tor pro­cesses in­volv­ing mul­ti­ple stake­hold­ers, pub­lic and pri­vate, with con­flict­ing in­ter­ests (Aal­to­nen and Ku­jala, 2010).
4. Tech­nol­ogy and de­signs are of­ten non-stan­dard, lead­ing to “unique­ness bias” amongst plan­ners and man­agers, who tend to see their pro­jects as sin­gu­lar, which im­pedes learn­ing from other pro­jects. 3
5. Fre­quently there is over­com­mit­ment to a cer­tain pro­ject con­cept at an early stage, re­sult­ing in “lock-in” or “cap­ture,” leav­ing al­ter­na­tives anal­y­sis weak or ab­sent, and lead­ing to es­ca­lated com­mit­ment in later stages. “Fail fast” does not ap­ply; “fail slow” does (Cantarelli et al., 2010; Ross and Staw, 1993; Drum­mond, 1998).
6. Due to the large sums of money in­volved, prin­ci­pal-agent prob­lems and rent-seek­ing be­hav­ior are com­mon, as is op­ti­mism bias (Eisen­hardt, 1989; Stiglitz, 1989; Flyvb­jerg el al., 2009).
7. The pro­ject scope or am­bi­tion level will typ­i­cally change sig­nifi­cantly over time.
8. De­liv­ery is a high-risk, stochas­tic ac­tivity, with over­ex­po­sure to so-called “black swans,” i.e., ex­treme events with mas­sively nega­tive out­comes (Taleb, 2010). Man­agers tend to ig­nore this, treat­ing pro­jects as if they ex­ist largely in a de­ter­minis­tic New­to­nian world of cause, effect, and con­trol.
9. Statis­ti­cal ev­i­dence shows that such com­plex­ity and un­planned events are of­ten un­ac­counted for, leav­ing bud­get and time con­tin­gen­cies in­ad­e­quate.
10. As a con­se­quence, mis­in­for­ma­tion about costs, sched­ules, benefits, and risks is the norm through­out pro­ject de­vel­op­ment and de­ci­sion-mak­ing. The re­sult is cost over­runs, de­lays, and benefit short­falls that un­der­mine pro­ject vi­a­bil­ity dur­ing pro­ject im­ple­men­ta­tion and op­er­a­tions.

The Iron Law of Megaprojects

  • Over time.

  • Over bud­get.

  • Un­der uti­lized.

Th­ese aren’t lit­tle, ei­ther: cost over­runs of 1.5x are com­mon, in bad cases they can run more than 10x, and 90% of pro­jects have them; it is com­mon for pro­jects to have 0.5x or less uti­liza­tion once com­plete. This holds for the pub­lic and pri­vate sec­tors, and also across coun­tries, so things like ex­ces­sive reg­u­la­tion or cor­rup­tion aren’t good ex­pla­na­tions.

They start off badly, but they do still man­age to get com­pleted, which is due to...

Break-Fix Model

Since man­age­ment of megapro­jects doesn’t know what they are do­ing or don’t have the in­cen­tives to care, in­evitably some­thing breaks. Then ad­di­tional time and money are spent to fix what broke, or the con­di­tions of the pro­ject are rene­go­ti­ated, and it limps along to the next break. This pro­cess con­tinues un­til the pro­ject is finished.

If it is so ter­rible and we know it is ter­rible, why do we do it this way?

Hirschman’s Hid­ing Hand

Be­cause a lot of im­por­tant stake­hold­ers don’t know how ter­rible it is. From Willie Brown, former mayor of San Fran­cisco:

“News that the Trans­bay Ter­mi­nal is some­thing like $300 mil­lion over bud­get should not come as a shock to any­one. We always knew the ini­tial es­ti­mate was way un­der the real cost. Just like we never had a real cost for the [San Fran­cisco] Cen­tral Sub­way or the [San Fran­cisco-Oak­land] Bay Bridge or any other mas­sive con­struc­tion pro­ject. So get off it. In the world of civic pro­jects, the first bud­get is re­ally just a down pay­ment. If peo­ple knew the real cost from the start, noth­ing would ever be ap­proved. The idea is to get go­ing. Start dig­ging a hole and make it so big, there’s no al­ter­na­tive to com­ing up with the money to fill it in.”

Nor are they with­out jus­tifi­ca­tion, for ar­gu­ments have been made that sup­port it. The first ar­gu­ment is ex­actly as Willie made it: if we knew how difficult large pro­jects were, we would never build them.

For the sec­ond, note the ti­tle of the sec­tion is hid­ing, not hid­den. This ar­gu­ment was made by Albert O. Hirschman on the ba­sis of ear­lier work by J.E. Sawyer, and it says that there is an er­ror in both the es­ti­ma­tions of costs, and in the es­ti­ma­tion of benefits, and this er­ror should roughly can­cel out. The prob­lem is that Sawyer’s work just pointed out that this was pos­si­ble based on a picked sam­ple of 5 or so. Hirschman then gen­er­al­ized it into a “Law of the Hid­ing Hand” and thereby le­gi­t­i­mated ly­ing to our­selves.

Alas it is bunk. Aside from be­ing falsified by the ac­tual data, Flyvb­jerg points out the non-mon­e­tary op­por­tu­nity costs through the ex­am­ple of the Syd­ney Opera House. It’s ar­chi­tect, Dane Jorn Ut­zon, won the Pritzker Prize (the No­bel of ar­chi­tec­ture) in 2003 for the Syd­ney Opera House. It is his only ma­jor work—the catas­trophic de­lays and cost over­runs de­stroyed his ca­reer. Con­trast with Frank Gehry, an­other in­spired ar­chi­tect, and it looks like man­age­ment’s bungling of the Opera House prob­a­bly cost us half a dozen gor­geous land­marks.

Sur­vival of the Unfittest

The pre­vailing at­ti­tude that it is perfectly ac­cept­able to lie about and then badly man­age megapro­jects leads to a weird sce­nario where worse pro­jects are more likely to be cho­sen. Con­sider two com­pet­ing pro­jects, one with hon­est and com­pe­tent man­age­ment, and one with dishon­est and in­com­pe­tent man­age­ment. The costs look lower for the lat­ter pro­ject, and the benefits look higher, and the choosers be­tween them prob­a­bly ex­pect them to both be over bud­get and be­hind sched­ule by about the same amount. There­fore we sys­tem­at­i­cally make worse de­ci­sions about what pro­jects to build.

Light at the End of the Tunnel

For­tu­nately there are bright spots. Dur­ing the Obama ad­minis­tra­tion these failings were iden­ti­fied as an im­por­tant policy area for the US gov­ern­ment. It is now much more com­mon for a megapro­ject failure to re­sult in con­se­quences for lead­er­ship, like the CEOs of BP and Deep­wa­ter Hori­zon, or Air­bus and the A380 su­per­jumbo. There are megapro­jects that go well and serve as ex­am­ples of how to do it right, like the Guggen­heim Mu­seum in Bilbao. Lastly, there is scat­tered adop­tion of vary­ing lev­els of good prac­tices, like refer­ence class fore­cast­ing and in­de­pen­dent fore­cast­ing.

End

For those in­ter­ested in learn­ing more, Oxford has Ma­jor Pro­gramme Man­age­ment at the mas­ters level. In books there is the Oxford Hand­book of Me­gapro­ject Man­age­ment, and Me­gapro­ject Plan­ning and Man­age­ment: Essen­tial Read­ings, both from Flyvb­jerg. I have read nei­ther, and both are col­lec­tions of pa­pers—I may just hunt them down in­de­pen­dently, for bud­getary rea­sons.