How Big Things Get Done

Waar gaat dit boek over?

In bijna elke organisatie loopt op dit moment minstens één groot project uit. Een IT-implementatie, een verbouwing, een fusie-integratie, een productlancering, een strategisch programma. De budgetten klopten niet, de planningen klopten niet, en het rapport waarin "we lopen op koers" stond is in stilte vervangen door een rapport waarin "we ramen de scope opnieuw" staat. Iedereen herkent het. Iedereen wijst naar de uitvoering: te weinig capaciteit, te veel scopewijzigingen, te onhandelbare leveranciers, te politieke besluitvorming.

How Big Things Get Done zet daar een ander verhaal tegenover. Bent Flyvbjerg, Deens econoom en hoogleraar in Oxford, heeft samen met zijn team de grootste empirische dataset over grote projecten ter wereld opgebouwd: ruim 16.000 cases, van Olympische Spelen tot kerncentrales, van transportprojecten tot IT-implementaties, van Burj Khalifa tot keukenverbouwingen. Zijn vraag was simpel: wat onderscheidt de projecten die slagen van de projecten die de mist in gaan?

Het antwoord is verrassend en confronterend. Het probleem zit zelden in de uitvoering. Het zit bijna altijd in wat ervóór gebeurt. De projecten die slagen, plannen disproportioneel veel langer en grondiger dan de gemiddelde. Ze simuleren, prototypen, herzien en herzien opnieuw, totdat het ontwerp staat. Pas daarna bouwen ze, en dan bouwen ze snel. De gefaalde projecten doen het omgekeerd: ze haasten zich de uitvoering in en blijven daar jaren hangen, eindeloos retrofittend wat ze in een paar weken planning hadden kunnen voorkomen.

Het boek is geen klassiek projectmanagement-handboek. Er staan geen Gantt-charts, geen RACI-matrices, geen PRINCE2-fasen in. Het is een strategisch werk over hoe groepen mensen iets ambitieus voor elkaar krijgen, en welke psychologische, organisatorische en methodologische valkuilen ze daarbij systematisch in lopen. Voor managers en bestuurders die ooit een groot project hebben zien ontsporen, en dat zijn ze allemaal, is het verplichte stof.

Over de auteurs

De combinatie Flyvbjerg en Gardner verklaart waarom dit boek én academisch zwaar én leesbaar is.

Bent Flyvbjerg is van origine Deens econoom en geograaf, en sinds 2009 de eerste BT Professor of Major Programme Management aan de Saïd Business School van Oxford. Eerder was hij hoogleraar in Aalborg en Kopenhagen. Hij geldt internationaal als dé autoriteit op het gebied van megaproject-management en wordt frequent geraadpleegd door overheden, multilaterale organisaties (Wereldbank, OESO) en grote infrastructuurprogramma's. Zijn academische werk over reference class forecasting is mede gebaseerd op de inzichten van Daniel Kahneman, met wie hij heeft samengewerkt om de methodologie operationeel te maken. Wat zijn werk bijzonder maakt: hij praat niet over megaprojecten, hij heeft ze gemeten. Zijn database is uniek en verleent het boek een autoriteit die anekdotische literatuur niet kan evenaren.

Dan Gardner is Canadese journalist en auteur van onder andere Risk (2008) en Future Babble (2010). Hij schreef eerder samen met Philip Tetlock het invloedrijke Superforecasting (2015), een boek over voorspellen en oordeelsvermogen. Zijn rol in How Big Things Get Done is die van vertaler en verteller: hij brengt Flyvbjergs empirische werk in een vorm die leesbaar is voor managers en bestuurders zonder dat de nuance verdwijnt. De combinatie van een data-gedreven academicus en een ervaren wetenschapsjournalist levert een boek op dat zowel intellectueel rigoureus als praktisch toepasbaar is.

Het fundament: de planningsfout in het kort

Het theoretische fundament van het boek is het werk van Daniel Kahneman en Amos Tversky over de planningsfout (planning fallacy): de systematische neiging van mensen om de tijd, kosten en risico's van toekomstige projecten te onderschatten, ook als ze precies weten dat vergelijkbare projecten in het verleden zwaar zijn uitgelopen. Het is geen kennistekort. Het is een kenmerk van hoe de menselijke geest plant: vanuit het beste denkbare verloop, niet vanuit de werkelijke verdeling van uitkomsten.

Flyvbjerg voegt daar een tweede mechanisme aan toe: strategische misrepresentatie. Veel grote projecten worden bewust te optimistisch ingeschat om goedkeuring te krijgen, met de veronderstelling dat als het project eenmaal loopt, niemand het meer durft te stoppen. De combinatie van eerlijke optimisme en strategische verkleining levert op systeem-niveau een verwoestende uitkomst op: de meeste grote projecten kosten substantieel meer dan beloofd, duren substantieel langer, en leveren substantieel minder.

De vier pijlers onder zijn aanpak om dit te doorbreken:

1. Think slow, act fast. Investeer disproportioneel veel in plannen, simulatie en repetitie. Bouw daarna in een rechte lijn.
2. Reference class forecasting. Anker je voorspelling op werkelijke uitkomsten van vergelijkbare projecten, niet op je eigen bottom-up schatting.
3. Modulariteit en mastery. Bouw uit herhaalbare blokjes, beheers eerst kleinschalig voordat je opschaalt.
4. Pre-mortem en tail-risk. Anticipeer expliciet op het catastrofale scenario, niet alleen op het gemiddelde.

De 7 lessen uitgewerkt

Les 1, Denk traag, doe snel

De meest contra-intuïtieve les uit het boek is ook de belangrijkste. De gangbare wijsheid in moderne organisaties is "stop met plannen, begin met doen". Snel iteratief leren, agile werken, fail fast. Flyvbjerg laat zien dat dit voor sommige typen werk goed kan werken, maar voor grote, kapitaalintensieve of moeilijk omkeerbare projecten catastrofaal verkeerd is.

Het sprekendste voorbeeld in het boek is een vergelijking tussen twee iconische bouwprojecten. Het Sydney Opera House werd snel goedgekeurd, snel begonnen, en duurde uiteindelijk veertien jaar langer en kostte veertien keer meer dan begroot. Pas tijdens de bouw werd duidelijk dat de daken constructief niet konden, en moest het hele ontwerp opnieuw worden uitgewerkt terwijl het beton al stond. Het Guggenheim Bilbao daarentegen werd ontworpen met een digitaal model dat tot in detail werd doorgerekend en gevisualiseerd voordat er één paal de grond in ging. Resultaat: op tijd, binnen budget, en sindsdien een internationaal icoon.

Het verschil zit niet in talent of geluk. Het zit in waar de moeilijke beslissingen worden genomen: op papier, in software, in een prototype, of in beton.

Praktische opdracht. Voor elk groot project: schrijf op hoeveel weken je aan plannen denkt te besteden vóór de uitvoering. Vermenigvuldig dat getal met drie. Dat is je realistische ondergrens.

Les 2, Plan in je hoofd, niet in de wereld

De tweede les bouwt voort op de eerste. Iteratie is essentieel om iets goeds te maken, maar de prijs van iteratie verschilt drastisch per medium. Een schets op papier scheur je verfrommeld weg. Een 3D-model herzie je in minuten. Een prototype repareer je in uren. Beton, code in productie of getekende contracten zijn ordes van grootte duurder om aan te passen.

De principes die hieruit volgen:

• Maximaliseer goedkope iteratie. Tekeningen, modellen, simulaties, scenario-discussies, gebruikersonderzoek. Zo lang en zo grondig mogelijk.
• Minimaliseer dure iteratie. Beton, productie-code, juridische contracten, organisatie-aanpassingen die niet terug te draaien zijn.
• Bouw eerst een prototype. Voor elk project van betekenis is er een goedkopere versie waarop je de risicovolle aannames kunt testen.

In de IT vertaalt dit zich naar: bouw een proof of concept op kleine schaal voordat je een enterprise-implementatie uitrolt. In strategie: voer een pilot uit in één regio of afdeling voordat je organisatiebreed implementeert. In productontwikkeling: test met klanten op papier of in een mockup voordat je productie inricht.

Vuistregel. Voor elke beslissing in het project, vraag jezelf: kan ik deze beslissing maken op een medium dat tien keer goedkoper te corrigeren is?

Les 3, Verken via referentieklassen, niet via je eigen plan

Dit is misschien de meest praktisch krachtige techniek uit het boek. Reference class forecasting werkt als volgt:

1. Identificeer de referentieklasse waar jouw project bij hoort. Niet "ons project", maar de verzameling vergelijkbare projecten in de wereld.
2. Verzamel de werkelijke uitkomsten van die referentieklasse, niet de geplande maar de geleverde resultaten.
3. Plot de verdeling: gemiddelde, mediaan, P10, P90.
4. Gebruik die verdeling als je verwachting, niet je eigen bottom-up schatting.

Een voorbeeld. Stel je leidt een ERP-implementatie. Je bottom-up schatting komt uit op achttien maanden en €4 miljoen. Vraag in plaats van die schatting te accepteren: wat hebben vergelijkbare ERP-implementaties in vergelijkbare organisaties wérkelijk gekost? Bekend cijfer uit de literatuur en Flyvbjergs database: gemiddeld 45% over budget, 7% van projecten gaat 200% over budget of meer. Verdeling: mediane uitkomst ergens rond €5,8 miljoen, en een vijfde percentage neemt €10 miljoen of meer.

Dat is je vertrekpunt, niet je bottom-up plan. En met dat vertrekpunt komt een ander gesprek: hoe brengen we dit project terug van de mediaan naar de bovenkant van de verdeling? Wat doen de 10% best presterende ERP-implementaties wel dat de rest niet doet?

Praktische opdracht. Voor elk groot project: voordat je je eigen plan presenteert, presenteer eerst de uitkomstenverdeling van de referentieklasse. Het gesprek dat volgt is fundamenteel ander dan het gesprek vanuit een bottom-up plan.

Les 4, Beware of singular case bias

Iedere projectleider denkt: ons project is anders. We hebben betere mensen, een betere methodologie, een beter inzicht, een betere context. De referentieklasse is misschien relevant voor anderen, maar wij gaan het anders doen.

In 95% van de gevallen is dat verkeerd. Flyvbjerg noemt dit singular case bias: de overtuiging dat je eigen project zo bijzonder is dat statistische patronen er niet op van toepassing zijn. De data is onverbiddelijk: in elk type project zit de overgrote meerderheid van uitkomsten in een nauw band rond de mediaan, en die mediaan is bijna altijd substantieel slechter dan de oorspronkelijke planning.

Wat betekent dit praktisch? Aanvaard dat je gemiddeld bent totdat het tegendeel bewezen is. Pas dán mag je afwijken van de referentieklasse. En "we hebben betere mensen" is geen bewijs. Bewijs is: we hebben deze specifieke aanpak al drie keer eerder succesvol uitgevoerd in vergelijkbare contexten, hier zijn de resultaten.

Een belangrijke nuance: de 5% van projecten die wél significant beter presteren dan de referentieklasse hebben bijna altijd één ding gemeen, ze hebben de principes uit dit boek serieus genomen. Modulariteit, mastery, think slow act fast, pre-mortem, reference class forecasting. Het zijn geen wonderkinderen; het zijn projecten die het saaie werk vóór hebben gedaan.

De kernvraag. Niet "waarom is ons project anders?", maar "wat moet ik bewijzen voordat ik mag aannemen dat ons project anders is?".

Les 5, Bouw met blokjes (Lego)

Een terugkerend patroon onder de slagende projecten in Flyvbjergs database: ze zijn opgebouwd uit gestandaardiseerde, herhaalbare modules. Niet uit één groot uniek ontwerp dat in één keer goed moet, maar uit duizenden gelijke eenheden die samen iets groots maken.

De krachtigste voorbeelden:

• Zonneparken. Eén zonnepaneel is een blok. Een park is een verzameling identieke blokken. Resultaat: zonne-energie is een van de snelst opschalende technologieën ter wereld, met voorspelbare kosten en planning.
• Madrid Metro-uitbreidingen. In tegenstelling tot veel metroprojecten elders heeft Madrid een vast bouwteam, een vaste werkwijze en sterk gestandaardiseerde stationconfiguraties. Resultaat: nieuwe stations bouwen ze in ongeveer een derde van de tijd en voor een derde van de kosten die elders gebruikelijk zijn.
• Cloud-infrastructuur. Een datacenter van Amazon of Google bestaat uit gestandaardiseerde rack-units in gestandaardiseerde gebouwtjes. Het is een Lego-set op industriële schaal.

Tegenovergesteld: eenmalige iconische projecten zoals het Sydney Opera House, kerncentrales, of de eerste implementatie van een nieuwe enterprise-software. Elke eenheid is uniek, elke leerervaring is duur, en elke fout wordt op echte schaal gemaakt.

De les voor managers: vermijd uniciteit waar je het niet nodig hebt. Stel je oplossing samen uit eenheden die je al kunt bouwen. Innoveer waar het ertoe doet, repeteer waar het kan.

Les 6, Mastery before scale

Sluit nauw aan op les 5. Voordat je iets opschaalt, moet je het op kleine schaal beheersen. Schaal versterkt zowel je sterktes als je zwaktes; wie zonder mastery opschaalt, vergroot vooral zijn zwaktes.

Het sprekendste voorbeeld in het boek is Pixar. Hoe bouw je een studio die jaar na jaar wereldwijde hits aflevert? Niet door grote risico's te nemen op één film, maar door obsessief lang aan het storyboard te werken, in iteratie na iteratie, met een vast team dat de methodologie van binnenuit kent. Pas als het verhaal staat, gaat het naar productie, en dan loopt de productie in een rechte lijn. Resultaat: een trackrecord dat in de filmindustrie ongeëvenaard is.

In zakelijke termen vertaalt dit zich naar: piloteer voordat je uitrolt, perfectioneer voordat je vermenigvuldigt. Of het nu gaat om een nieuwe winkelformule, een nieuwe dienstverleningspropositie, of een nieuwe digitale tool: bewijs dat je het kunt op kleine schaal voordat je het organisatiebreed uitrolt.

Vuistregel. Een organisatie die haar pilots niet structureel afmaakt voordat ze opschaalt, krijgt in zijn projectportfolio dezelfde uitkomstenverdeling die Flyvbjerg in zijn database ziet: 80% van de projecten overschrijdt budget en planning, 20% catastrofaal.

Les 7, Het lange staartrisico is je echte vijand

Projecten falen zelden licht. Ze slagen of ze falen catastrofaal: één keer 300% over budget, één keer drie jaar vertraagd, één keer een politiek schandaal dat het hele initiatief tot stilstand brengt. De data in Flyvbjergs database laat zien dat de verdeling van uitkomsten fat-tailed is: het gemiddelde wordt sterk vertekend door een minderheid van extreme uitslagen.

De implicatie is fundamenteel anders dan hoe de meeste organisaties risico's beoordelen. Een risicoanalyse die zegt "het is onwaarschijnlijk dat we 100% over budget gaan" is niet zinvol, want het is precies die onwaarschijnlijke uitkomst die je hele project bepaalt. Wat telt, is hoe dik de staart is en welke scenario's daarin zitten.

Concrete actiepunten:

• Pre-mortem sessie. Stel je voor dat het project drie jaar later is afgelopen als een complete ramp. Wat is er gebeurd? Welke beslissing leidde tot welke gevolgen? Schrijf het scenario uit. Werk vervolgens terug: welke vroege signalen had je moeten zien?
• Tail-risk inventarisatie. Welke gebeurtenissen kunnen het hele project doen ontsporen, en hoe waarschijnlijk zijn ze? Niet "wat is de kans dat de leverancier zes weken vertraagt", maar "wat is de kans dat de leverancier failliet gaat".
• Optionaliteit inbouwen. Welke beslissingen kun je uitstellen totdat je meer weet? Welke verplichtingen kun je beperken zonder de voortgang te schaden?

Waarschuwing. Wie alleen op het gemiddelde plant, plant niet voor het project dat hij waarschijnlijk gaat krijgen.

Het reference class forecasting werkblad

Het rode draadgereedschap uit How Big Things Get Done is een protocol dat je voor elk groot project doet. De kwaliteit van je antwoorden voorspelt de kwaliteit van je voorspelling.

1. Welke referentieklasse hoort bij dit project? Niet je eigen project, maar de verzameling vergelijkbare initiatieven in jouw sector of bredere context. Wees specifiek: niet "IT-projecten", maar "ERP-implementaties in middelgrote zorgorganisaties".
2. Welke werkelijke uitkomsten heeft deze referentieklasse opgeleverd? Tijd, kosten, baten. Niet de planningen, de realisatie. Verzamel zo veel data als je kunt: publicaties, branchedata, anonimiseerde cases van collega's.
3. Wat is de verdeling, niet alleen het gemiddelde? Mediaan, P10, P90. Welke gevallen zitten in de lange staart en waardoor?
4. Wat is mijn bottom-up plan? Schat van onderaf wat dit project zou moeten kosten en duren als alles meezit.
5. Hoe groot is de discrepantie tussen mijn plan en de mediaan van de referentieklasse? Als jouw plan beter is dan de mediaan, wat doe je dan structureel anders dan de gemiddelde uitvoerder?
6. Welk scenario zit in mijn P90, en hoe waarschijnlijk vind ik dat? Eerlijk antwoord, geen geruststelling.

Dit werkblad ontkracht systematisch de twee grootste valkuilen: optimistische bottom-up planning, en negeren van de fat tail.

Vier scenario's: hoe het boek in de praktijk werkt

Scenario 1: De ERP-implementatie

Je organisatie wil een nieuw ERP-systeem implementeren. De adviseur belooft een go-live binnen veertien maanden voor €5 miljoen, inclusief migratie en training.

Waar het mis gaat (klassieke aanpak). Het stuurdocument wordt goedgekeurd op basis van de bottom-up schatting van de adviseur, gepresenteerd met een Gantt-chart en een fasering. Maand 6: eerste vertraging vanwege "complexere migratie dan verwacht". Maand 12: scope-wijziging vanuit business. Maand 18: kritieke beslissing om go-live uit te stellen. Maand 24: nieuwe stuurgroep. Eindstaat na drie jaar: €8,5 miljoen, gefaseerde uitrol, irritatie alom.

De How-Big-Things-aanpak. Eerst de referentieklasse: ERP-implementaties in vergelijkbare organisaties, gemiddeld 45-70% over budget, 30% over tijd, 17% catastrofaal. Mediaan: €7-8 miljoen, achttien tot twintig maanden. Dat is je realistische uitgangspunt, niet €5 miljoen in veertien maanden. Vervolgens: investeer drie maanden in een grondige planfase voordat je begint. Maak digitale prototypes van de belangrijkste processen, oefen met sleutelgebruikers, breng datakwaliteit in kaart. Voer een pre-mortem uit: stel je voor dat het project mislukt, wat is er dan gebeurd?

Het project dat je vervolgens uitvoert is misschien iets duurder vooraf en iets kleiner in scope, maar voorspelbaar in zijn uitvoering. Voor het stuurcomité is dat onbeschrijflijk veel waardevoller dan een vlot beginprogramma met een ongewisse einduitkomst.

Scenario 2: De strategische transformatie

Je leidinggevende kondigt een transformatie aan: in twee jaar tijd moet de organisatie van product-georiënteerd naar klant-georiënteerd worden, met nieuwe rollen, nieuwe processen, nieuwe IT en nieuwe targets.

Valkuil. De plannen worden in weken opgesteld, in PowerPoint gepresenteerd, en in maand drie begint de uitrol. Maand zes: weerstand. Maand twaalf: helft van het management vraagt zich af waar het programma over gaat. Maand achttien: de doelen worden bijgesteld. Maand vierentwintig: heroverweging.

De aanpak. Een transformatie is geen project, het is een serie van kleinere projecten waarvan elk afzonderlijk zou moeten kunnen falen zonder het geheel mee te slepen. Begin met één afdeling of regio die je tot mastery brengt. Documenteer wat werkt en wat niet. Maak van de uitkomst een referentie-implementatie. Dan, en alleen dan, schaal je op naar de tweede en derde implementatie, met aanpassingen op basis van wat je hebt geleerd.

De begintijd van de transformatie verschuift naar achteren, en dat voelt vertraagd. Het is de bewuste keuze. Wie nu vertraagt op één afdeling wint twee jaar op de hele organisatie.

Scenario 3: Het nieuwe productlancering

Je bent productmanager. Je team werkt aan een nieuw product dat over negen maanden gelanceerd moet worden.

Klassiek pad. De roadmap heeft drie sprints van drie maanden. Maand negen ligt vast in de hoofden van marketing en sales. Maand acht: laatste features blijken complex. Maand negen: gedeeltelijke launch, irritatie bij sales, klanten teleurgesteld over wat ontbreekt.

De aanpak. Eerst de referentieklasse: hoe vaak halen vergelijkbare productlanceringen in jouw sector de geplande datum, en met welke scope? Als de mediaan vier maanden vertraging is, plan je daar omheen: óf je verschuift de datum, óf je halveert de scope, óf je doet beide. Beslis vóór het project begint, niet halverwege.

Vervolgens: bouw een prototype en test het met klanten vóór de eerste regel productiecode wordt geschreven. Modulariseer de productontwikkeling zodat je in deelblokken kunt opleveren. Werk met een vaste capaciteit en variabele scope, niet andersom.

Scenario 4: De fusie-integratie

Twee bedrijven gaan samen. Het stuurcomité heeft uitgerekend dat synergiën van €15 miljoen per jaar binnen anderhalf jaar realiseerbaar zijn. De fusie is publiek aangekondigd.

Valkuil. De integratie begint direct na de aankondiging. Verschillende werkstromen lopen parallel: HR, IT, brand, processen, governance. Iedereen werkt hard, maar zonder gemeenschappelijke prioritering. Maand zes: brand-integratie loopt voor op proces-integratie, wat verwarring veroorzaakt bij medewerkers. Maand twaalf: de synergiën zijn voor 40% gerealiseerd, en de besluitvorming is gepolariseerd geraakt tussen "oude A" en "oude B".

De aanpak. Investeer disproportioneel veel in het ontwerp van de integratie voordat je begint met uitvoering. Wie beslist over welke processen worden gekozen, op welke termijn? Welke beslissingen kun je uitstellen totdat er meer duidelijkheid is? Welke modulaire werkstromen kun je in afzonderlijke teams parallel uitvoeren zonder dat ze elkaar blokkeren? Welke quick wins kun je in de eerste honderd dagen realiseren om vertrouwen te bouwen, terwijl de grote integratie nog in voorbereiding is?

Reference class data: de meeste fusies realiseren minder dan de helft van de aangekondigde synergie, en de waarderealisatie loopt tussen drie en vijf jaar in plaats van anderhalf. Plan daarop. Verlos jezelf van de illusie dat dit jouw fusie wel anders zal lopen.

De polderzieke: drie typisch Nederlandse projectvalkuilen

Een patroon dat in Flyvbjergs internationale werk minder naar voren komt, maar in de Nederlandse praktijk wel: drie cultureel ingesleten gewoontes die effectief plannen ondermijnen.

1. Polderoptimisme

Nederland is een land van besluitvorming via consensus, en consensus wordt gesmeerd met optimistische uitgangspunten. Niemand wil de eerste zijn die zegt "dit gaat niet binnen budget". Het gevolg is dat businesscases systematisch worden vormgegeven om door de besluitvorming te komen, in plaats van als realistische voorspelling. Iedereen weet dat de getallen niet kloppen. Iedereen tekent toch.

Het tegenwicht: maak de referentieklasse-data verplicht onderdeel van elk go/no-go-besluit. Niet als kritiek op de projectleider, maar als reality check op de hele organisatie. "We tekenen dit onder voorbehoud dat we de mediaan van de referentieklasse halen of beter, en hier is wat we daarvoor anders gaan doen."

2. Scope-creep als beleefdheid

In de Nederlandse zakelijke cultuur is "ja zeggen" een sociale verplichting. Een stakeholder die een wens uit krijgt zelden direct "nee" te horen. Het gevolg is dat scopes onmerkbaar groeien gedurende een project, met irritatie aan beide kanten als de oorspronkelijke deadline niet wordt gehaald.

Het tegenwicht: scheid het besluitvormingsmoment van de uitvoering. Een wijzigingsverzoek tijdens uitvoering wordt niet beoordeeld op zijn merites alleen, maar op zijn effect op planning en budget. "Ja, we kunnen dit doen, en het kost ons drie weken extra en €120.000. Wil je dat?" Driekwart van de scope-creep verdwijnt zodra de prijs zichtbaar wordt op het moment van de keuze.

3. Procesconsensus als planning

Een Nederlandse valkuil is om procesafspraken (wie beslist wanneer, welke commissie kijkt mee, hoe ziet de feedback-loop eruit) te verwarren met inhoudelijke planning (wat gaan we precies bouwen, in welke volgorde, met welke risico's). Het project heeft een mooie governance maar geen reële roadmap.

Het tegenwicht: maak inhoudelijke beslissingen voordat je procesafspraken maakt, niet andersom. Eerst weten wát je gaat doen. Daarna afspreken hoe je dat samen bewaakt.

De Pixar-les: wat goedkope iteratie echt betekent

Een onderschat hoofdstuk in het boek gaat over hoe Pixar werkt. Voor een buitenstaander lijkt het een filmstudio. Voor Flyvbjerg is het een masterclass in projectmanagement.

Wat doet Pixar dat anderen niet doen?

• Het storyboard is de planfase. Maanden, soms jaren, gaan zitten in het ontwerp van het verhaal voordat er een seconde animatie wordt gerenderd.
• Iteratie is sociaal én structureel. De "Brain Trust", een vaste groep collega-regisseurs, kijkt regelmatig naar elke film in progress en geeft scherpe, niet-bindende feedback. Het is geen besluitvormingsorgaan; het is een feedbackmotor.
• Pas naar productie als het verhaal staat. En dan loopt productie in een rechte lijn. Renderfarmen blijven niet idle terwijl het script wordt herschreven.

De universele les: goedkope iteratie is niet hetzelfde als snel beginnen. Het is langer doorgaan in de fase waarin fouten goedkoop zijn. Vraag jezelf voor elk project: wat is mijn "storyboard"? Welke vorm van het project kan ik herzien voor een fractie van de prijs van het eindproduct, en hoe lang kan ik die fase volhouden voordat ik moet committen?

Tien veelgemaakte fouten die dit boek voorkomt

1. De bottom-up schatting accepteren zonder een referentieklasse te raadplegen.
2. De planfase haastig afronden om uitvoering te kunnen starten.
3. Aannemen dat jouw project anders is dan de gemiddelde in zijn klasse.
4. Scope vergroten tijdens uitvoering zonder de tijd- en kostprijs zichtbaar te maken.
5. Tail-risico negeren omdat het "onwaarschijnlijk" is.
6. Eén keer groot inzetten in plaats van eerst klein te beheersen.
7. Maatwerk verheerlijken waar modulariteit volstaat.
8. Optimistische voortgangsrapportages zonder eerlijke reality check.
9. Agile of "snel beginnen" gebruiken als excuus om planning over te slaan.
10. Geen pre-mortem doen bij grote initiatieven.

Elk van deze tien fouten verklaart een substantieel deel van de mislukte projecten die Flyvbjergs database vult.

Pas dit boek toe met AI: vier prompts voor jouw volgende project

De principes uit How Big Things Get Done worden krachtiger als je ze gebruikt in combinatie met een AI-assistent. Hieronder vier promptsjablonen die je direct in ChatGPT, Claude of Gemini kunt plakken, vul je eigen situatie in.

Prompt 1, Reference class analyse

Je bent een ervaren projectanalist die werkt met reference class
forecasting volgens de methode van Bent Flyvbjerg.

Mijn project:
[beschrijf type, omvang, sector, looptijd, budget in 5-10 zinnen]

Help mij de juiste referentieklasse te identificeren. Geef:
1. Drie kandidaat-referentieklassen waarbij dit project hoort,
   met argumentatie waarom ze relevant zijn
2. De beste keuze en waarom
3. Wat de typische uitkomstenverdeling in die klasse is
   (gebaseerd op publieke onderzoeken, benchmarks, branchedata):
   mediaan kosten- en tijdsoverschrijding, P10, P90
4. Drie sleutelfactoren die het verschil maken tussen
   high performers en average performers in deze klasse
5. Vijf vragen die ik mezelf moet stellen om te toetsen of mijn
   plan realistischer is dan de gemiddelde projectplanning

Prompt 2, Pre-mortem sessie

Ik wil een pre-mortem doen voor een project dat ik ga starten.

Het project:
[beschrijf doel, omvang, context, stakeholders, looptijd]

Stel je voor dat het project drie jaar verder is en compleet is
mislukt. Help mij dit scenario uit te werken:

1. Schrijf een verhalend scenario (één pagina) over hoe het project
   is ontspoord
2. Identificeer de vijf belangrijkste beslissingsmomenten waar
   het mis ging
3. Welke vroege signalen had ik moeten zien?
4. Welke aannames in het oorspronkelijke plan bleken cruciaal
   onjuist?
5. Welke drie maatregelen, als ik ze nu zou nemen, maken dit
   scenario het minst waarschijnlijk?

Prompt 3, Modularisatie

Mijn project moet [doel] realiseren in [tijdshorizon].

Help mij dit project te herontwerpen als een Lego-bouwwerk:

1. Welke gestandaardiseerde, herhaalbare bouwblokken kunnen samen
   het doel realiseren?
2. Welk klein blokje kan ik eerst tot mastery brengen voordat ik
   opschaal?
3. Hoe kan ik vermijden dat ik op grote schaal iets bouw dat ik
   nog niet beheers?
4. Welke onderdelen zijn écht uniek en welke kunnen modulair?
5. Wat is mijn "minimaal levensvatbare modulair" - de kleinste
   herhaalbare eenheid die zin heeft?

Prompt 4, Voortgangsdiagnose

Ik leid een project van [type] dat nu [maanden] loopt. De stand
van zaken:

[beschrijf voortgang, problemen, beslissingsmomenten, scope-wijzigingen]

Help mij eerlijk te beoordelen waar we staan:

1. Zit ik op tijd in de uitvoeringsfase, of had ik nog in de
   planfase moeten zitten?
2. Welke beslissingen heb ik genomen die ik in een goedkoper
   medium had moeten testen?
3. Welke aannames maakte ik die ik nu zou herzien als ik
   opnieuw kon beginnen?
4. Welke tail-risico's zijn nu reëler dan ik vooraf inschatte?
5. Welke twee corrigerende acties leveren waarschijnlijk
   het meeste op?

Geef geen geruststellende antwoorden. Wees confronterend.

Vergelijking met andere boeken over projecten en strategie

How Big Things Get Done is geen klassiek projectmanagement-boek. Het is een strategisch werk over hoe ambitieuze initiatieven slagen of falen. Wie verder wil lezen, of zich afvraagt of dit het juiste boek voor zijn situatie is, vindt hier de belangrijkste alternatieven.

Thinking, Fast and Slow, Daniel Kahneman

Het werk waarop Flyvbjerg deels leunt. Kahneman beschrijft de planningsfout, de optimisme-bias en de strategische misrepresentatie, maar als psychologische verschijnselen, niet als operationele richtlijn. How Big Things Get Done maakt er praktijk van. Lees Kahneman als je het cognitieve fundament wilt; pak Flyvbjerg als je het in de praktijk wilt brengen.

The Lean Startup, Eric Ries

Een belangrijk werk over snel itereren met klanten, vooral relevant voor productontwikkeling en startups. Ries en Flyvbjerg lijken op het eerste gezicht in conflict, fail fast versus think slow, maar de overlap is groter dan de verschillen. Beide pleiten voor goedkope iteratie en het uitstellen van duurzame commitments. Het verschil zit in de schaal en het type project. Lean startup voor producten met onbekende klantvraag; Flyvbjerg voor grote, kapitaalintensieve, moeilijk omkeerbare projecten.

Doing Agile Right, Darrell Rigby

Een nuancering op de agile-mode in moderne organisaties. Rigby en zijn co-auteurs laten zien wanneer agile werkt en wanneer het ontaardt in een excuus om planning over te slaan. Sluit goed aan op Flyvbjergs kritiek op gehaaste agile. Lees beide als je in een organisatie zit die agile heeft "geïmplementeerd" zonder de onderliggende discipline.

Reinventing Project Management, Aaron Shenhar & Dov Dvir

Een academischer werk over verschillende projecttypen en de bijbehorende managementaanpakken. Minder gericht op de planningsfout, meer op contingentie: welk type project vraagt om welk type management. Goed vervolg als je de basis van Flyvbjerg al kent.

The Mythical Man-Month, Frederick Brooks

De klassieker over softwareprojecten uit 1975, en nog steeds verbazingwekkend relevant. Brooks' wet ("adding manpower to a late software project makes it later") en zijn observaties over conceptual integrity sluiten naadloos aan op Flyvbjergs principes. Voor IT-managers verplicht naast How Big Things Get Done.

Welk boek wanneer?

Wat zoek je?	Pak dit boek
Empirisch onderbouwde principes voor grote of kapitaalintensieve projecten	How Big Things Get Done
Cognitieve fundamenten van de planningsfout	Thinking, Fast and Slow
Snelle iteratie met klanten en onzekere productvragen	The Lean Startup
Wanneer agile wel en niet werkt	Doing Agile Right
Verschillende projecttypen en hun managementaanpak	Reinventing Project Management
Klassieker over softwareprojecten en grote teams	The Mythical Man-Month

Sterke punten

De grootste kracht is de combinatie van empirische zwaarte en praktische helderheid. Flyvbjerg praat niet over megaprojecten in abstracte termen; hij heeft de grootste database ter wereld en gebruikt die om elke claim te onderbouwen. Tegelijk is het boek geschreven met de toegankelijkheid van een wetenschapsjournalist; je hoeft geen statistiek te kunnen om de boodschap mee te nemen.

Daarnaast doet het boek iets belangrijks: het verandert het gesprek over projectfalen van moralistisch ("waarom konden we niet beter plannen?") naar systemisch ("waarom plannen organisaties systematisch verkeerd, en wat doe je daaraan?"). Dat is een gezondere uitgangspositie voor verbetering.

Zwakke punten

De data komt overwegend uit fysieke megaprojecten: infrastructuur, bouw, energie, transport. De generalisatie naar pure kenniswerk, agile softwareontwikkeling, of organisatieverandering is op sommige punten een sprong. De principes blijven goed, maar de concrete cijfers en voorbeelden vergen vertaalwerk.

Daarnaast: wie Thinking, Fast and Slow grondig heeft gelezen, vindt in de cognitieve hoofdstukken weinig conceptueel nieuws. De waarde zit dan vooral in de operationalisatie. En de auteurs zijn op een paar plekken streng over agile, terwijl agile in zijn oorspronkelijke vorm juist dichter bij hun principes ligt dan ze suggereren.

Mijn oordeel

How Big Things Get Done is een van de zeldzame managementboeken die empirisch fundament en praktische uitvoerbaarheid combineren zonder aan een van beide in te boeten. Voor wie ooit verantwoordelijk is geweest voor een groot project dat niet liep zoals beloofd, en dat zijn de meeste mensen die ooit een grote rol hebben gehad, is het een ongemakkelijke maar nuttige spiegel.

De grootste verdienste is dat het boek projectfalen demystificeert. Het is geen gevolg van slechte mensen, gebrekkige tools of pech. Het is een gevolg van diep ingesleten denkfouten die op systeemniveau elk groot project in dezelfde valkuilen jaagt. Wie die mechanismen kent, kan ze omkeren. En wie het saaie werk vóór doet, plannen, simuleren, modulariseren, mastery opbouwen, oogst daar in de uitvoering ordes van grootte op terug.

De beperkingen zijn eerlijk te benoemen. De voorbeelden lopen sterk richting fysieke megaprojecten; de vertaalslag naar pure kenniswerk vergt nadenken. En wie Kahneman en Tetlock al kent, ziet de cognitieve onderbouwing eerder als bevestiging dan als openbaring. Maar de operationele scherpte, reference class forecasting, modulariteit, mastery before scale, blijft uniek.

Koop dit boek als…

• Je verantwoordelijk bent voor strategische initiatieven of grote projecten in je organisatie
• Je merkt dat projectvoorstellen consistent te optimistisch worden gepresenteerd en je het gesprek wilt veranderen
• Je bestuurder of stuurgroeplid bent en wilt leren betere vragen te stellen aan projectleiders
• Je in transformatie, IT, infrastructuur of complexe productontwikkeling werkt
• Je een team wilt trainen op een gemeenschappelijke planningsdiscipline

Sla dit boek over als…

• Je projecten klein, snel en goedkoop omkeerbaar zijn, je hoeft de principes dan zelden bewust toe te passen
• Je zoekt naar een klassiek projectmanagement-methodologie boek met sjablonen en fasenmodellen
• Je vooral uitvoerings-, sprint- of operationeel niveau bestuurt zonder invloed op planning of go/no-go-besluiten
• Je Thinking, Fast and Slow en Superforecasting al grondig kent en geen behoefte hebt aan operationele uitwerking

Eindscore

Criterium	Score
Praktische toepasbaarheid	9/10
Leesbaarheid	8/10
Originaliteit	8/10
Geschikt voor beginners	7/10
Algeheel oordeel	8,5/10

Een aanrader voor iedereen die ooit een groot project heeft zien ontsporen en zich heeft afgevraagd wat er fundamenteel mis gaat. Voor een investering van één weekend lezen krijg je een denkraam dat je de rest van je carrière scherpere vragen laat stellen aan elk projectvoorstel dat op je bureau komt.

Transparantie: Deze bespreking is geschreven op basis van publiek beschikbare uitgeversinformatie, het academische werk van Bent Flyvbjerg (Saïd Business School, Oxford) over reference class forecasting en de planningsfout, en de schriftelijke samenvattingen en interviews rond How Big Things Get Done. Concepten als "think slow, act fast", reference class forecasting, modulariteit en mastery before scale zijn aan het boek toe te schrijven; uitgewerkte oefeningen, scenario's en AI-prompts zijn onze eigen vertaling van de principes naar de Nederlandse managementpraktijk.