De Projectstudio / Aflevering

Aflevering 2 · Juli 2026 · 22 minuten

De rekbare driehoek

"Kan het niet twee maanden sneller?" Het kan, maar niet zonder gevolgen. Elisa en Brunhilde leggen de spanningsdriehoek uit: scope, timing en budget. Waarom die driehoek helemaal niet rekbaar is, welke hoek het gevaarlijkst is en hoe je omgaat met de verrassingen die elk project onderweg tegenkomt.

Wat is de spanningsdriehoek?

Drie dingen bepalen elk project:

  • Scope: wat je gaat doen.
  • Timing: tegen wanneer het klaar moet zijn.
  • Budget: wat het kost, in geld en in mensen. Doe je iets voor jezelf, dan kost het misschien geen geld, maar dan is je eigen tijd de resource.

Samen vormen ze een driehoek die vastligt. Je kent hem ook als de ijzeren driehoek of de triple constraint. Er bestaan uitgebreidere varianten, zoals de diamant met kwaliteit in het midden of een model met zes constraints. Maar wie de drie basishoeken onder controle heeft, is al goed bezig.

Download: Spanningsdriehoek in één beeld (PDF)

Waarom heet hij de rekbare driehoek?

Dat is de grap: hij is niet rekbaar. Trek je aan één hoek, dan bewegen de andere twee mee. Moet een project twee maanden vroeger klaar zijn, dan doe je minder of betaal je meer. Bij een verbouwing voelt iedereen dat intuïtief aan: dan laten we de badkamer voorlopig zoals ze is. Maar in een bedrijf wordt er toch onderhandeld alsof je op de markt staat.

Bij een software-implementatie kan sneller wel, met gevolgen: een kleinere go-live voor één departement, minder modules tegelijk, of de handleidingen later. Meer mensen inzetten is ook niet altijd een oplossing. Negen vrouwen maken geen baby in één maand.

Welke hoek is het gevaarlijkst?

Scope. Een kortere deadline doet bij iedereen een alarmbel afgaan, een scope die uitbreidt niet. Bij een verbouwing breek je de vloer open en blijkt die vol zand te zitten: alles moet eruit en er moet nieuwe chape in. "Het kan niet anders, we nemen het mee." Klopt, maar het kost tijd en geld. Een projectteam in tunnelvisie lost zo'n probleem niet magisch op. Er gaan uren in, dus middelen.

Niet elke wijziging raakt je driehoek. Groen in plaats van blauw maakt meestal niet uit. Bespreek daarom met je projectteam aan welke knoppen je kan draaien, en welke impact hebben op scope, timing of budget.

Wanneer ligt je timing vast?

Bij regelgeving. Als de overheid een deadline oplegt, zoals bij NIS2, moet je tegen die datum conform zijn. Daar onderhandel je niet over. Daarom houd je, zeker op portfolioniveau, buffer achter de hand als je weet dat regelgeving snel verandert.

Ook binnen een project bouw je best buffer in, bijvoorbeeld 10% voor het onverwachte. Veel planningen gaan uit van een happy flow: niemand wordt ziek, niets gaat mis. En bij een renovatie (brownfield) weet je minder zeker wat je tegenkomt dan bij nieuwbouw (greenfield). Dat geldt net zo goed voor software.

Hoe ga je om met veranderingen onderweg?

Geen enkel project loopt exact zoals afgesproken in de definitiefase. Dat is niet erg, zolang je bewust kiest. Werk met een wijzigingsproces: leg aan de persoon die het geld geeft voor wat je tegengekomen bent en wat het betekent voor scope, budget en timing. Die neemt een geïnformeerde beslissing, en vanaf dan is dat de nieuwe driehoek.

Communiceer die keuzes transparant, ook naar iedereen die er impact van ondervindt. Mensen onderschatten vaak het effect op anderen. Hoe groter de verandering, hoe uitgebreider je communicatieplan. En maak er een reflex van: bij elke verrassing, ook als er iemand uitvalt, kijk je eerst naar je driehoek.

Hoe ziet het eruit als het goed loopt?

Bij de start zijn scope, timing en budget goed doordacht. Er is afgesproken wie geïnformeerd wordt, wie de gevolgen inschat en wie uiteindelijk beslist. En er zit buffer in budget en timing, omdat je weet dat de scope nog kan bewegen.

Weet je nog niet precies waar je wil landen, maar ligt je budget wel vast? Dan kan agile passen: je werkt in sprints en bepaalt per pakket wat je met dat deel van het geld en de tijd doet. Ook dan spreek je vooraf af wie wanneer beslist. En vooral: denk na over je probleem, voor je een oplossing kiest.

Om te onthouden: er is een driehoek, en verander je één hoek, dan bewegen de andere mee. Komt er iets onverwachts op je pad, kijk dan eerst naar je driehoek.

Herken je dit in je eigen organisatie? Wordt er over deadlines onderhandeld alsof scope en budget niet meetellen? Elevora helpt je een wijzigingsproces op te zetten waarin iedereen weet wie beslist.

Lees het volledige transcript

Dit transcript is gemaakt op basis van een automatische transcriptie van de aflevering en licht opgekuist. Er kunnen nog kleine fouten in staan.

Hey, ik ben Elisa. En ik ben Brunhilde. En in deze podcast leggen wij uit waarom projectbeheer helemaal niet zo moeilijk is als het lijkt. Ben je bezig met een project en zie je door de bomen het bos niet meer? Dan zijn wij hier om jou te helpen. Wij zijn De Projectstudio.

Wat is de spanningsdriehoek?

Dames, waarover gaan we het vandaag hebben? De rekbare driehoek. Yes, de driehoek waar projectmanagement helemaal om draait. Oké, ik ben benieuwd. Wat moet ik me voorstellen bij een rekbare driehoek?

Die driehoek is eigenlijk niet rekbaar. Dat is de mop. Jawel, maar dan zijn er gevolgen. Voilà.

Als je een project managet, zijn er drie aspecten die alles bepalen. Scope: dat is wat je gaat doen. Timing: op welke termijn je dat gaat doen. En budget: hoeveel het gaat kosten. Budget is eigenlijk resources: hoeveel kost het in centjes, maar ook in mensen die ermee bezig zijn. Als je bijvoorbeeld bekijkt wat je voor jezelf allemaal moet doen, kost dat misschien geen geld, maar dan is je tijd je resource.

Die drie dingen vormen samen een driehoek, en die driehoek ligt vast. Als je aan een van de hoeken begint te morrelen, trek je de driehoek uit evenwicht, en dat heeft gevolgen voor de andere twee.

Waarom heet hij de rekbare driehoek?

Je kan niet zeggen: het project moest over zes maanden klaar zijn, maar we zijn van gedacht veranderd, of er is iets veranderd in ons bedrijf, en nu willen we dat het twee maanden vroeger klaar is. Dat kan, maar het heeft altijd gevolgen op de twee andere hoeken. Als het veel sneller klaar moet zijn, gaan we ofwel minder doen, ofwel er veel meer geld in steken. Die dingen hangen altijd aan elkaar.

Dat lijkt simpel als je het met een eenvoudig voorbeeld uitlegt. Ik verbouw mijn huis en ik wil twee maanden vroeger klaar zijn. Dan denkt iedereen: dat zal niet gaan, dan nemen we de badkamer niet mee. Dat lijkt logisch. Maar in een bedrijf, in een project, worden die vragen toch gesteld. We zien heel vaak dat er onderhandeld wordt alsof je op de markt staat: hoe lang mag het duren, wat mag het kosten. Zo werkt het niet. Het komt met gevolgen.

Zoals ik vorige keer in de intro al zei: ik ben de madame van de methodologie. Daar bestaan heel veel varianten van, maar de eenvoudigste is echt de triple constraint, de ijzeren driehoek. En wij maken er een mopje van: de rekbare driehoek, want als je eraan trekt, beweegt de rest mee.

Je hebt ook andere modellen, zoals de diamant. Die heeft vier hoeken, met kwaliteit in het midden. En je hebt de six constraints, echt een zeshoek. Je kan het zo complex maken als je wil. Maar wij gaan graag naar de basics. Als je die drie al onder controle krijgt, ben je al niet slecht bezig. Elke hoek is dus een hoekje scope, een hoekje timing en een hoekje budget, of resources, of kost, hoe je het ook noemt.

En wat belangrijk is: je kan er dingen aan veranderen, maar dat heeft altijd gevolgen. En daar wordt niet altijd rekening mee gehouden. We implementeren een tool en de software moet er sneller zijn: kunnen jullie niet zorgen dat het twee maanden sneller opgeleverd wordt? Hoe zou dat kunnen, zonder gevolg voor de andere dingen? Je kan niet met dezelfde mensen hetzelfde blijven doen en denken dat je twee maanden sneller klaar bent. Dat kan niet.

Bij een tool kan je dan zeggen: oké, dat kan, maar dan gaan we niet iedereen kunnen opleiden binnen het tijdsframe dat je gegeven hebt. Dan doen we misschien een kleinere go-live met een klein groepje voor één departement. Of we schuiven in de modules die we live zetten. Of in de documentatie en handleidingen die nog gemaakt moeten worden.

En wat ik supertof zou vinden: dat mensen dit horen en zich er meer bewust van worden. Als je je huis verbouwt en plots een maand vroeger klaar moet zijn, maak je snel die reflex: laat die badkamer maar zoals ze is. Intuïtief doe je dat. Maar in een professionele context krijg je meer druk. Management duwt, collega's trekken, of er wordt gevraagd dat je er nog een extra project bij neemt. Dat is je eigen driehoek: je eigen resources zijn ook constraints. Je kan maar doen wat je kan doen.

In een professionele omgeving verliezen mensen dat uit het oog. Zelfs management, dat zich daar goed van bewust zou moeten zijn, probeert toch te duwen. Als dat concept meer gekend zou zijn, zou ik dat al heel tof vinden.

Welke hoek is het gevaarlijkst?

Ik denk ook: wat je ook doet, wees je bewust aan welke knoppen je kan draaien en wat er dan meebeweegt. Sommige knoppen hebben geen impact. Als je bij dezelfde software zegt: ik wil dat het groen is in plaats van blauw, dan is dat ook een knop, maar die raakt je triple constraint niet.

Soms mist de reflectie om daarbij stil te staan: aan welke knoppen kan ik draaien die impact hebben, en welke niet? En bespreek dat, want je doet zelden of nooit een project alleen. Bespreek het met je projectteam: als we dat doen, heeft dat impact op de timing, of op de scope.

Ik denk ook dat timing het gemakkelijkst lijkt. Als iemand zegt dat het een maand vroeger klaar moet zijn, gaan bij iedereen de alarmbellen af. Maar scope is de gevaarlijkste: wat gaat het precies doen, en hoe goed is dat afgebakend?

En in het voorbeeld van een verbouwing? Een verbouwing is supertof. Ik kom uit de bouw, dus daar kan ik wel op doorgaan. Bij een verbouwing breek je altijd iets weg, en daarachter zit iets wat niet voorzien was. Dan is dat ook een scope die uitbreidt: je gaat iets meer doen. Je had niet voorzien dat je vloer vol zavel zat als je hem opende, dat die er volledig uit moest en dat er nieuwe chape in moest. Dat is ook een scope-uitbreiding, en dat is vaak de moeilijkste, omdat mensen niet goed doorhebben dat er echt iets gebeurt. Het gebeurt en cours de route: het kan niet anders, dus we nemen het mee. Klopt, maar het heeft ook gevolgen op de andere twee.

En in een project krijg je echt zo'n tunnelvisie, zeker in je projectteam. Dat is nodig en belangrijk, je blijft gaan, gaan, gaan. Maar het kost tijd. Het is niet omdat je een probleem opmerkt dat je niet voorzien had, dat het magisch opgelost geraakt. Daar gaan mensen tijd in moeten steken, dus weer middelen.

Misschien een stom voorbeeld, maar kan je het vergelijken met Blind Gekocht? Mensen hebben verwachtingen, ze willen dat en dat en dat, maar ze hebben maar zoveel geld.

Nee, eigenlijk is dat spot on. Die driehoek wordt op een bepaald moment gezet. Zij zeggen: dit is onze lat, daar willen we naartoe, dat willen we hebben. Dat is je scope.

Dat is misschien ook een idee voor een aflevering: wat is eigenlijk het proces van een project, wat zijn de verschillende fases? Je noemt het een definitiefase of een conceptfase, dat maakt niet zoveel uit. Het is je denkstuk, waarin je beslist: wat doen we wel, wat doen we niet, hoeveel kost het? Dat onderzoek gebeurt in de definitiefase. Daar klop je de piketten op scope, timing en budget.

En dat is net als bij Blind Gekocht: zij komen af met "dit is onze scope, dit is ons budget", en aan de andere kant van de tafel zitten een paar mensen die zeggen: dat gaat niet gaan. Je moet eerst door die onderhandelingsfase: wat is hier een realistische driehoek? En dan ligt hij vast.

Vroeger ging er in software-projectmanagement een meme rond waarin de projectmanager aan het management moest uitleggen dat je geen baby kan maken in één maand door er negen vrouwen op te zetten. Je moet face the music: je hebt bepaalde constraints. Door er vrouwen aan toe te voegen, ga je een zwangerschap niet acht maanden sneller laten gaan. Dat is het principe. Je moet kijken: wat wil je, wat is het budget, wat is de timing, wat is realistisch?

Wanneer ligt je timing vast?

Sommige dingen kan je ook niet omzeilen. Neem regelgeving. Er is regelgeving waar momenteel heel veel mensen in ICT-land en bij heel veel bedrijven wakker van liggen, zoals NIS2. Daar hangen deadlines aan. Als de overheid je een deadline oplegt, kan je daar niet rond. We werken ook vaak met bedrijven die aan bepaalde regelgeving vastzitten, en dan is de timing een van de belangrijkste dingen om te halen: tegen die datum moet je conform zijn.

En zie je dat bij bedrijven terugkomen in hun driehoek, dat ze iets nieuws niet konden voorzien? Ja en nee. Heel vaak ontstaan projecten net omdat er iets aangepast moet worden: nieuwe regelgeving leidt tot een project. Dan zitten we meer op het niveau van het grote broertje, projectportfoliomanagement, het volledige beheer. Daar is het altijd goed om buffer te houden als je in een context werkt waar je weet dat de regelgeving snel verandert en dat snel doorkomt in wetgeving.

Maar ook in je project kan je buffer inbouwen. Als je in de definitiefase bekijkt wat je gaat doen, kan je zeggen: wij voorzien 10% voor onverwachte zaken. Dat kan je ook bij je bouw doen. Dat is altijd een slim idee: wat marge voor het onbekende.

Wij coachen ook veel projectmanagers in hoe ze hun job doen. Als we dan naar hun timings en planningen kijken, zeggen we vaak: dat is een happy flow. Alles gaat perfect. Ze hebben workshops gedaan, het budget staat, de mensen zijn ingepland. En dan vraag ik: wat als er iemand ziek wordt? Wat kan er allemaal misgaan? Daar is niet over nagedacht.

En er is ook een verschil tussen brownfield en greenfield: iets renoveren versus iets helemaal nieuw bouwen. Bij een volledige nieuwbouw heb je veel meer controle dan bij een renovatie. Bij een renovatie weet je nooit wat je gaat tegenkomen. Dat heb je ook bij software-implementaties, eigenlijk bij heel veel dingen. Bouw je verder op iets wat er al is, of bouw je iets volledig nieuw? Dat maakt een groot verschil in hoeveel controle je hebt over welke beren er nog op de weg liggen.

Hoe ga je om met veranderingen onderweg?

We willen eigenlijk gewoon dat mensen daar meer over nadenken. Het komt altijd met een gevolg. En dat is op zich niet erg, want in projectmanagement heb je vaak een procesje om veranderingen toe te voegen. Dan maak je een bewuste keuze. "Beste persoon die het geld geeft: we zijn dit tegengekomen. Is het oké dat we het meenemen?" Of: "We kunnen niet anders, we moeten het meenemen, anders geraken we niet tot ons eindpunt. Dit is het gevolg op het budget, de kosten en de timing." Dan is dat een geïnformeerde beslissing, en vanaf dan is dat de nieuwe driehoek.

Dat is weer Blind Gekocht: je moet kiezen. Ja, je moet kiezen.

En dat kiezen is het belangrijke punt. Of je nu op project-, programma- of portfolioniveau kijkt, zoals in projectportfoliomanagement: die keuzes maken en daar heel transparant over zijn, is voor mij altijd een sleutel tot succes. We zijn dit tegengekomen, heb je iedereen geïnformeerd die er impact van gaat ondervinden? Top, goed bezig. En ik denk dat we dat te vaak vergeten: echt goed communiceren over veranderingen.

Ik doe dit al meer dan vijftien jaar, en ik heb nog geen enkel project meegemaakt waar je na de definitiefase zei "zo gaan we het doen" en het daarna perfect zo verlopen is. Dat gebeurt nooit. Dat kan niet. Maar de vraag is: hoe ga je ermee om? Maak je inzichtelijk dat dingen veranderen, en ben je je bewust van alle gevolgen?

Elke keer dat je iets tegenkomt dat je niet voorzien had, moet dat een reflex zijn: wat doet dit met mijn timing en mijn budget? En omgekeerd: als er resources uitvallen, verandert er dan niets aan je scope, je budget of je tijd? Jawel, dat voel je direct. Als er iets onverwachts gebeurt, moet de eerste reflex altijd zijn: kijk naar je driehoek.

Hoe ziet het eruit als het goed loopt?

Heb je een voorbeeld van hoe het wel moet? Een ideale situatie, waarin jullie niet nodig zijn omdat het proces zo goed loopt?

In een ideale wereld heb je bij de start van je project goed nagedacht over de drie piketjes die je gezet hebt. Je weet heel goed wat je scope, timing en budget is. Je komt onderweg iets onverwachts tegen, en er is een duidelijke flow afgesproken in je bedrijf, of met de mensen met wie je het doet: als er iets verandert, weten we wie we moeten informeren, wat de gevolgen zijn en wie uiteindelijk beslist. Als projectteam kan je van alles tegenkomen, maar wie beslist op het einde of we het meenemen of niet? Als dat duidelijk is, zijn wij helemaal niet nodig.

En er is een buffer. Je neemt buffer in je budget en in je timing, omdat je weet dat er in je scope altijd nog iets kan gebeuren. Daardoor kan je het meteen opvangen.

Je hebt ook methodologieën waarin je op voorhand beslist hoe je daarmee omgaat. Dat is misschien ook iets voor een andere aflevering. Als je zegt: we weten nog niet helemaal waar we willen landen met de scope, maar we weten wel dat we maar zoveel geld hebben, dan is agile misschien iets voor jou. Dan werk je met sprints. Je beslist eigenlijk dat je van alles gaat doen met een zak geld, maar je weet nog niet wat precies. En dan definieer je pakketjes: dit kunnen we met dat stukje van de zak geld doen, binnen die tijd. Dat is een afspraak die je maakt om verder te gaan.

Maar ook dan is de vraag: wanneer ga je dat beslissen, en wie beslist? Als je echt wil dat wij niet moeten komen, dan moet dat op voorhand afgesproken zijn. Want dat zien we vaak in bedrijven: dan komt de miserie. "Dat hadden we toch afgesproken?" En wie moet het nu beslissen? Dat weet niemand zeker.

Wat ook heel vaak onderschat wordt: mensen denken dat er geen impact is op andere mensen. Assume makes an ass out of you and me. Ze denken: dat gaat geen impact hebben op die personen, en ze communiceren het niet. En dan kennen ze de job van die mensen blijkbaar toch niet zo goed als ze dachten. Het is niet uit slechte wil, maar dan blijkt er toch impact te zijn, en dan moet het geëscaleerd worden. Hoe groter de verandering, hoe meer mensen je moet betrekken, hoe meer lijntjes er zijn, en hoe meer je moet nadenken over je communicatieplan.

Denk gewoon goed na voor je begint. We zijn het minst nodig in bedrijven die heel goed nadenken over wat hun probleem is, in plaats van meteen te zeggen: dit is de oplossing. Wat willen we hiermee bereiken? Zodat je scope heel duidelijk ligt. Maar dat is misschien voor een volgende keer.

Wat wil je de luisteraar meegeven?

We kunnen bijna afronden, maar ik heb termen gehoord zoals agile. Tijdens mijn studies, al even geleden, ging het ook over agile en lean. Dat zijn termen die jullie ook vaak gebruiken. Ja, daar gaan we zeker eens een aflevering over maken.

Het belangrijkste dat mensen die nu luisteren moeten meenemen: er is een driehoek. En als je iets verandert aan die driehoek, heeft dat effect op de andere hoeken.

En wat we nu besproken hebben, vind je dat ook terug op jullie website? We maken shownotes, met de links erin. Dat is een goed idee. Jij gaat ons wel uitleggen wat we nog moeten doen. Dat komt helemaal goed.

Merci voor deze masterclass, of crashcourse. Nu lijkt het alsof de driehoek rekbaar is, maar dat is dus een grap. Inderdaad, rekbaar is hij helemaal niet. Goed onthouden dus, iedereen die luistert. Dan zien we jullie de volgende keer terug. Bedankt voor jullie tijd en jullie advies. Dank je wel. Doei.