Projectmatig werken: terug naar de basis van Mueller

Wat we zijn vergeten over versnellen — en waarom de woningbouwopgave ons dwingt om het weer te leren

Nederland staat voor een opgave die we in omvang alleen kunnen vergelijken met de wederopbouw. 900.000 woningen bouwen. 7 miljoen huizen verduurzamen. De energietransitie vormgeven. Stikstof oplossen. En dat allemaal tegelijk, met dezelfde schaarse mensen, in hetzelfde overvolle land.

Dit is ons Apollo-moment.

Maar waar NASA in acht jaar een mens op de maan zette, doen wij gemiddeld negen tot tien jaar over het realiseren van één woningbouwproject. Zeven jaar daarvan gaat op aan de voorfase — aan vergaderen, onderzoeken, afstemmen en wachten.

Ergens gaat er iets fundamenteel mis.

De grote misvatting

Vraag een willekeurige projectleider wat projectmatig werken is, en je krijgt een zucht. GROTICK. Faseringen. Stuurgroepen. Voortgangsrapportages die niemand leest. Risicologboeken die worden ingevuld omdat het moet. Gate reviews die ceremonieel worden afgehandeld.

We zijn collectief gaan geloven dat projectmanagement de ballast is die we meeslepen. Een administratieve last. Een vinkje voor de auditor. Iets wat je erbij doet terwijl het échte werk ergens anders gebeurt.

Maar dit is precies het tegenovergestelde van waarvoor het ooit is bedacht.

De methodes die wij nu ervaren als vertraging, werden ooit ontworpen als de ultieme versnelling. En de man die ze bedacht, deed dat onder een druk die wij ons nauwelijks kunnen voorstellen.

George Mueller en het onmogelijke

1. NASA heeft een probleem.

President Kennedy heeft de wereld beloofd dat Amerika voor het eind van het decennium een mens op de maan zet. Maar interne schattingen voorspellen een landing in 1971 — op z'n vroegst. Er werken 400.000 mensen aan het project, verspreid over 20.000 bedrijven en universiteiten. Maar ze werken langs elkaar heen. Elke afdeling is een eiland. Er is geen overzicht van kosten, geen grip op planning, geen manier om te weten of de onderdelen straks op elkaar aansluiten.

Dan wordt George Mueller aangesteld als hoofd bemande ruimtevaart. Wat hij aantreft schokt hem.

"Er bestond geen managementsysteem," concludeert hij. "Geen manier om hardware-configuraties te controleren. Geen inzicht in kosten of planning."

Mueller introduceert vervolgens een reeks principes die zo effectief zijn dat ze de basis vormen voor alles wat wij nu "projectmanagement" noemen. En — cruciaal — de maanlanding vindt plaats in 1969. Twee jaar eerder dan de oorspronkelijke schattingen.

Niet ondanks Mueller's systemen. Dankzij.

Wat Mueller bedoelde versus wat wij ervan hebben gemaakt

Het probleem is niet dat we Mueller's methodes niet kennen. Het probleem is dat we ze hebben gereduceerd tot hun vorm, zonder de functie te begrijpen.

De les van "all-up testing"

Mueller's meest controversiële beslissing verdient extra aandacht, omdat hij precies laat zien waar wij vastlopen.

De traditionele aanpak bij NASA was om elke component apart te testen. Eerst de motor. Dan de brandstoftank. Dan de besturing. Pas als alles apart werkte, ging je combineren. Veilig. Methodisch. Traag.

Mueller draaide dit om. Test de complete raket in één keer. Alle onderdelen tegelijk.

Raketpionier Wernher von Braun vond het roekeloos. Maar Mueller's redenering was onweerlegbaar: de échte problemen zitten nooit in de onderdelen zelf. Ze zitten in de interfaces — de plekken waar systemen elkaar raken. En die ontdek je alleen door het geheel te testen.

Von Braun gaf later toe dat Mueller gelijk had.

Kijk nu naar een gemiddelde gebiedsontwikkeling. We doen jarenlang deelonderzoeken. Verkeer apart. Milieu apart. Financiën apart. Participatie apart. Elk onderzoek is grondig en methodisch. En dan, na twee jaar, blijkt bij de integrale toets dat niets op elkaar aansluit. De verkeersoplossing conflicteert met de milieuambities. De financiële aannames kloppen niet met de participatie-uitkomsten.

We ontdekken de interface-problemen pas als het te laat is.

Mueller zou zeggen: doe één integrale sessie met alle disciplines en stakeholders tegelijk. Vroeg. Als er nog ruimte is om bij te sturen. Ja, dat is spannend. Ja, dan komen de conflicten meteen op tafel. Maar je ontdekt in één dag wat je anders pas na twee jaar ontdekt.

Projectmanagement als exoskelet

Hier komt de metafoor die voor mij alles veranderde.

In het verkeer maakt het niet uit of je in een Porsche rijdt of in een Fiat Panda. Rood is rood. Rechts heeft voorrang. De verkeersregels maken dat iedereen — ongeacht status — gelijkwaardig kan deelnemen.

Mueller's systeem werkt hetzelfde. Het zijn verkeersregels die 400.000 mensen in staat stelden om samen te werken zonder elkaar te verlammen.

Als je de regels kent, kun je zeggen: "Nee, wethouder, rechts heeft voorrang. U bent de bestuurlijk opdrachtgever, niet de projectleider. " Dat is geen insubordinatie. Dat is de spelregels toepassen.

Dit is wat projectmanagement zou moeten zijn: een exoskelet. Een externe structuur die je in staat stelt om verder te springen dan je alleen zou kunnen. Die je beschermt tegen de chaos. Die je de woorden geeft om grenzen te stellen.

Maar ergens zijn we dat vergeten. We zijn de vormen blijven uitvoeren — de rapportages, de reviews, de faseringen — zonder te begrijpen dat ze bedoeld waren als bevrijding, niet als belasting.

Vijf vragen voor je volgende project

Als de woningbouwopgave ons Apollo-moment is, dan moeten we terug naar Mueller's basis. Niet naar meer bureaucratie, maar naar de oorspronkelijke functie van zijn principes.

1. Wanneer testen we het geheel? Niet aan het eind, maar aan het begin. Plan binnen de eerste drie maanden een integrale sessie met alle disciplines en stakeholders. Ontdek de interface-problemen als je er nog iets aan kunt doen.

2. Waar zijn onze korte lijnen? Wie mag rechtstreeks met wie communiceren als er iets urgent is? Als alles via de hiërarchie moet — ook informatie — dan ben je te traag. Bouw GEM-boxes: directe lijnen voor signaleren, formele lijnen voor besluiten.

3. Wat is onze ene bron van waarheid? Als er twintig versies van het projectplan circuleren, heb je geen projectplan. Investeer in één plek waar de actuele stand staat — en maak iedereen verantwoordelijk om die te gebruiken.

4. Welke problemen absorberen we die niet van ons zijn? Mueller's systeem was bedoeld om problemen op de juiste plek te leggen, niet om ze te verbergen. Als jij als projectleider alles zelf oplost wat eigenlijk van de opdrachtgever is, dan werkt het systeem niet. Escaleren is geen falen — het is het systeem gebruiken waarvoor het bedoeld is.

5. Wat weet de volgende projectleider van onze fouten? Mueller's "lessons learned" waren geen rapport achteraf. Ze waren de bijbel voor elke volgende missie. Als jouw opvolger weer vanaf nul begint, heb je die kans gemist.

Ons Apollo-moment

NASA bracht een mens op de maan in acht jaar. Wij doen tien jaar over één woningbouwproject.

Het verschil zit niet in de complexiteit. De Apollo-missie was ongekend complex — 400.000 mensen, 20.000 organisaties, technologie die nog niet bestond.

Het verschil zit in hoe we projectmanagement gebruiken.

Mueller gebruikte structuur om te versnellen. Wij gebruiken structuur om ons in te dekken. Mueller gebruikte reviews om problemen vroeg te vinden. Wij gebruiken reviews om te rapporteren dat alles op schema ligt. Mueller gebruikte rollen om werk te verdelen. Wij gebruiken rollen om verantwoordelijkheid af te schuiven.

De woningbouwopgave en de energietransitie vragen om een terugkeer naar de basis. Niet meer bureaucratie, maar betere toepassing van principes die zestig jaar geleden al werkten.

Herken je dit? Projectmanagement als last in plaats van als versnelling? Ik ben benieuwd: wat zou er veranderen als je Mueller's principes weer zou toepassen zoals hij ze bedoelde?