How Big Things Get Done

Think from Right to Left

Met deze uitdrukking doelt Flyvbjerg op: denk eerst goed na over de gewenste eindsituatie, voordat je aan de slag gaat. Een project is geen doel op zich; een project is een middel om een doel te bereiken. Dit lijkt een no-brainer, maar te vaak worden de middelen verward met het doel. Door de vraag te stellen: waarom doen we dit project, kun je de hyperfocus op oplossingen voor zijn.

Dit heeft alles te maken met de taak van Opdrachtgevers om projectdoelstellingen te formuleren en deze af te pellen naar de functies die we verwachten van het Werk. Deze worden vervolgens omgezet in functionele eisen die bij Opdrachtnemers gelegd kunnen worden, in plaats van oplossingen voor te schrijven. Hiermee wordt de expertise van de markt optimaal benut en ontstaat ruimte om passende oplossingen in te zetten.

Flyvbjerg illustreert dit met een overheidsinstantie die een eiland met het vasteland wil verbinden. Al snel volgen vragen als: hoeveel kost een brug, waar moet deze komen en hoe lang duurt de bouw? Logische vragen, maar ze gaan uit van een oplossing die al vaststaat: de brug. Veel waardevoller is het eerst te onderzoeken waarom die verbinding nodig is. Gaat het om kortere reistijden, economische ontwikkeling of betere toegang tot spoedeisende zorg? Pas als het doel helder is, kun je bepalen welke oplossing daarbij past. Misschien is dat een brug, maar het kan net zo goed een tunnel, veerdienst of een andere oplossing zijn. Wie begint met de oplossing, mist mogelijk betere alternatieven.

Ik moet bij “Think from Right to Left” daarnaast ook denken aan het opleverproces. Te vaak zien we dat de oplevering pas aan het einde van het project aandacht krijgt en vervolgens een bottleneck vormt. Het oplevermoment als vertrekpunt nemen dwingt ons om terug te redeneren: welke werkzaamheden moeten worden uitgevoerd, welke middelen zijn daarvoor nodig en hoe tonen we straks aan dat aan de klantvraag is voldaan?

Voor opdrachtgevers begint dit met de vraag aan welke interne en externe stakeholders uiteindelijk moet worden opgeleverd en welke eisen zij stellen aan overdracht, ingebruikname en beheer van het object. Dit betekent dat we bijvoorbeeld met assetmanagement om tafel gaan en hun input een plek geven in de vraagspecificaties, bijvoorbeeld middels eisen en verificatievoorschriften.

Voor opdrachtnemers betekent dit dat zij vanaf de start moeten nadenken over een soepele oplevering aan de opdrachtgever. Dat begint met een analyse van de contractstukken en de daarin opgenomen eisen aan het opleverdossier. Daarnaast is het verstandig vroegtijdig de voorgestelde invulling van het opleverdossier te valideren met Opdrachtgever om vast te stellen of dit daadwerkelijk aansluit bij de verwachtingen en behoeftes van Opdrachtgever. Zo kunnen eventuele verschillen in interpretatie worden opgelost voordat zij aan het einde van het project een bottleneck vormen.

Interessant is dat dit gedachtegoed sterk doet denken aan het V-model; aan de linkerkant ligt de focus op begrijpen, specificeren en decomponeren van wat bereikt moet worden, altijd denkend vanuit het oplevermoment (rechtsboven) en daarna pas aan de slag gaan met de daadwerkelijke realisatie.

Black Swan Management (risicomanagement)

Een “Black Swan” is een metafoor voor een zeldzame, volslagen onverwachte gebeurtenis die een enorme impact heeft. Omdat dergelijke gebeurtenissen zich per moeilijk laten voorspellen, is het onmogelijk alle risico’s vooraf in beeld te brengen. Hoe uitgebreid een risico-inventarisatie ook is, er zullen altijd onbenoemde risico’s zijn: de zogenaamde “unknown unknowns”. Gelukkig betekent dit niet dat effectief risicomanagement onmogelijk is. Volgens Flyvbjerg vraag het om een andere benadering van projecten en maakt daarbij onderscheid tussen twee perspectieven:

• The Inside view: Je project zien als uniek project
• The Outside view: Ons project behoort tot een categorie vergelijkbare projecten

Beide perspectieven zijn relevant. Zo stelt de inside view je in staat te focussen op details en project specifieke omstandigheden en vereisten. Projectteams kiezen van nature voor dit perspectief. We zien vooral wat ons project bijzonder maakt en onderschatten hoe vergelijkbaar het project is met eerdere projecten.

The outside view helpt je echter om je project te zien als  “one of those” en te leren van en voort te borduren op gedane inzichten uit die categorie. Door data over kosten, doorlooptijden, risico’s en resultaten van deze projecten te analyseren, ontstaat een realistischer beeld van waar je in je eigen project rekening mee moet houden. Daarnaast kun je denken aan peer reviews van je risicodossier door projectteams die ervaring hebben met vergelijkbare projecten. Zij herkennen vaak risico’s, afhankelijkheden en valkuilen die binnen het projectteam zelf over het hoofd worden gezien. Zelden is één enkele gebeurtenis de oorzaak van grote vertragingen of kostenoverschrijdingen; meestal is het de combinatie van meerdere risico’s die elkaar versterken. Het is daarom waardevol risico’s binnen een bepaalde projectcategorie expliciet te analyseren en mee te nemen in de projectbeheersing.

One huge thing

Voortbordurend op het feit dat veel projecten vanuit de inside view worden bekeken; Veel projecten worden als “one huge thing” gezien. Bij definitie een project dat one of a kind is. Hoe unieker een project wordt gemaakt, hoe minder gebruik kan worden gemaakt van bestaande kennis, standaardontwerpen, bewezen oplossingen en ervaring uit eerder projecten. Dat resulteert in een langzaam en complex project. Het wiel opnieuw willen uitvinden, altijd maatwerk willen leveren is een van de oorzaken dat projecten buiten budget en buiten tijd eindigen.

Door het werk echter op te knippen (Flyvbjerg: in legoblokjes), ontstaan elementen die wel hetzelfde zijn als andere projecten. En daar waar bepaalde delen al eens zijn gedaan, kan een efficiëntie slag gemaakt worden, door kennis die al op de markt is, oplossingen die al zijn ontwikkeld, lessons learned, etc.

Dit principe herkennen we ook binnen Systems Engineering. Door systemen op te delen functies (FBS), objecten (OBS), activiteiten (ABS) en werkpakketten (WBS) ontstaan bouwstenen die projectoverstijgend kunnen worden bekeken. Een voorbeeld hiervan is het gebruik van Object Type Libraries (OTL). Een objecttype is de generieke definitie of ‘klasse’ waaraan een specifiek object voldoet. Denk bijvoorbeeld aan het objecttype “Weg” met onderliggend de specifieke objecten “Weg X”, Weg Y”, etc. Weg X en Y moeten voldoen aan de generieke eisen zoals gekoppeld aan het objecttype “Weg”, met aanvullend project specifieke eisen zoals gekoppeld aan Weg X en Weg Y. Juist de objecttypes met zijn eisen hoeven niet voor ieder project opnieuw uitgevonden te worden maar kunnen verzameld worden in een OTL die als database fungeert voor alle objecttypes en daaraan gestelde eisen. Op basis van deze OTL’s worden vervolgens basisspecificaties gemaakt die vervolgens gebruikt kunnen worden om de vraagspecificaties op te stellen voor de projecten.

Door slim te standaardiseren ontstaat ruimte voor innovatie op onderdelen waar die daadwerkelijk waarde toevoegt.

Conclusie

Al met al vond ik het een alarmerend boek waarbij de moed me soms wat in de schoenen zonk. De statistieken laten weinig ruimte voor optimisme en maken duidelijk hoe structureel de problemen binnen grote projecten zijn. Wat echter overheerst is het enthousiasme en de drive om vanuit de ideologie van ProcessMinded het verschil te maken op de projecten en de IJzeren wet van Megaprojecten het tegendeel te bewijzen. Investeer tijd in de voorkant door je processenhuis in te richten, maak keuzes expliciet en organiseer herleidbaarheid. Onderwerpen waar we je bij ProcessMinded graag bij helpen. Heb jij het boek ook gelezen of wil je het van ons lenen? Welkom voor een kop koffie om er verder over te sparren!