Verslag DACE-contactbijeenkomst 27 november 2025 - Think slow, act fast: innovatieve aanpak voor cost en value engineers

DACE-voorzitter Alex Rood opende de bijeenkomst en heette iedereen welkom. Voordat hij het woord gaf aan de drie sprekers, stond hij stil bij de opkomende cursussen, die zorgen voor verbreiding en verspreiding van kennis in het vakgebied. Het is mooi om terug te kijken op een jaar waarin deze cursussen enorm hebben bijgedragen aan de DACE doelstelling, maar vooral omdat de cursussen door de deelnemers ook dit jaar weer erorm hoog werden gewaardeerd. Daarom roept Alex het publiek op om dit verder te delen binnen de eigen organisatie en daarbuiten. Tenslotte gaf Alex de data aan waarop de contactbijeenkomsten in 2026 worden gehouden.

How big things get done
In de eerste presentatie, gegeven door Hein de Jong, value manager bij Value FM, werden de bevindingen uit het onderzoek van de Deense econoom Bent Flyvberg doorgenomen. In dit onderzoek zijn maar liefst 16.000 projecten wereldwijd, van groot tot klein en uit diverse sectoren doorgelicht. Dit onderzoek is samengevat in het boek ‘How big things get done’ uit 2023.

Voordat Hein hierop terecht kwam gaf hij eerst aan dat hij het publiek deze bijeenkomst wilde activeren door deze prikkelende stellingen voor te leggen, waarop alleen met ja of nee geantwoord kon worden. De eerste was meteen al raak en was de vraag of men wel eens aan een project heeft gewerkt dat uiteindelijk tweemaal meer kostte dan de oorspronkelijke raming. Hier reageerde het publiek nog bescheiden maar er gingen toch wat duimen omhoog.

Vervolgens werden een aantal Linked-in berichten doorgenomen over de kostenoverschrijdingen van de renovatie van het Binnenhof. Dat begon met de hoofdredacteur van Cobouw die nog eens de ontwikkeling van kosten doornam van 475 miljoen euro in 2015 en dan de opzienbarende sprong van 844 miljoen in 2023 naar 2 miljard euro in 2024, met de constatering dat een cynicus wel wist dat die 475 miljoen euro wensdenken was. Hieruit kon Hein alweer twee stellingen aan het publiek voorleggen en zo kon hij vaststellen of er cynici in de zaal zaten. In een ander Linked-in bericht kon een cost engineer al berekenen dat met benchmarking met de renovatie van het Rijksmuseum al een betere kostenraming zou zijn gemaakt in 2015. Bij een vraag aan het publiek kon Hein vaststellen dat benchmarking ofwel ‘reference class forecasting’ verfrissend goed kan werken.

Vervolgens was er het Linked-in bericht van een anoniem persoon die aangaf dat het Binnenhof gesloopt moet worden en dat de twee miljard euro besteed moet worden aan de bouw van woningen voor daklozen en woningzoekenden. Ook werd een bericht getoond van Douwe Jan Elzinga die 75 grote overheidsprojecten had onderzocht en had geconstateerd dat 30% daarvan succesvol waren en dat bij 70% problemen zijn opgetreden zoals vertragingen en budgetoverschrijdingen. Hij verwees naar de samenwerkingsvorm ‘Projekt Allianz’ zoals die in Zwitserland wordt toegepast en waarbij veel aandacht wordt geschonken aan de voorbereiding en aan de risico-inschatting. Hein sloot deze Linked-in sessie af met een bericht van iemand die aangaf dat het schortte aan kennis van bouwkosten; reden voor Hein om aan de zaal te vragen of zij ook vonden dat het de schuld van de cost engineer was. Wat het antwoord hierop was, valt wel te raden.

Hierop ging Hein weer terug naar het boek van Flyvberg en liet een interessante grafiek zien. Daaruit was te zien dat van de 16.000 wereldwijd onderzochte projecten circa 48% goed presteerden qua budget. Verder was te zien dat 8,5% zowel goed presteerde qua budget als qua planning. Slecht 0,5% presteerde goed qua budget, planning en technische performance. Een grafiek met een vreselijk resultaat, zo vond Hein en hij kon vaststellen dat het merendeel van het publiek het gevoel had dit wel eens juist kon zijn. Iemand uit de zaal riep daarbij lachend dat in zijn sector de kosten niet uitmaakten.

Een andere grafiek liet zien wat de mate van budgetoverschrijding in verschillende branches was. Zo was te zien dat IT-projecten met meest risicovol zijn en verscheidene projecten kende die 100 maal of meer boven budget waren. De bouw van hydro-elektrische dammen kent bijvoorbeeld hoge risico’s en hier waren dan ook projecten te zien 10 maal of meer boven budget waren. Aflopend naar risico werden ook de resultaten voor luchtvaart, olie en gas en voor zonne-energie getoond. Het deed Hein pijn zoveel projecten te zien die boven de oorspronkelijke raming zitten en dan ook nog eens zoveel daarboven, terwijl men als deelnemer in een project zo vaak bezig is om een overschrijding van bijvoorbeeld 30% te voorkomen. Hij wees nog eens op het feit dat met een nauwkeurigheid van 40% in de kostenraming een bedrijf uiteindelijk failliet kan gaan of belastinggeld wordt verkwist. Daarnaar gevraagd gaf het publiek aan dat probabilistische kostenramingen ook een gerede kans hebben om er ordegroottes naast te zitten.

Lego als aanbeveling
Na deze slechte tijdingen vond Hein het tijd voor wat betere berichten en nam de elf aanbevelingen uit het boek van Flyvberg door. De eerste aanbeveling is om een ‘master builder’ in te huren, zoals in de Middeleeuwen een meesterbouwer van kathedralen werd ingehuurd. Blijf dus weg van de inkoop op basis van laagste prijs maar zoek juist de meesters op die kunnen ondersteunen in het project. De tweede aanbeveling is om een goed team te bouwen; een onervaren team heeft impliciete noch expliciete kennis. De derde is om steeds maar om het ‘Waarom?’ te vragen, tot op het bot zo gaf Hein aan. De vierde aanbeveling was om te bouwen met bewezen modules. Of anders geformuleerd, hoe kun je het ook anders verwachten van een Deense professor, bouwen met Lego. De vijfde raadgeving was ‘Think slow, act fast’ ofwel een goed begin is het halve werk. Neem derhalve goed de tijd om het project te doordenken in het begin, de kosten zijn dan nog zoveel lager om veranderingen door te voeren.

De zesde aanbeveling is benchmarking ofwel reference class forcasting toe te passen. Kijk met een blik van buiten naar binnen naar het project en vertrouw niet alleen op die bill of material. Hierbij gaf Hein ter overweging dat als het je eigen geld betrof, zou je dan naast de klassieke ramingsmethodes niet ook een benchmark willen zien van wat vergelijkbare projecten hebben gekost? Het publiek kon hier voor een groot deel mee instemmen. Een zevende aanbeveling is het besef dat risico’s de gewenste resultaten teniet kunnen doen. Hier haalde Hein het voorbeeld van het Nationaal Historisch Museum in herinnering, dat uiteindelijk veel meer bezoekers kreeg dan bij de bouw verwacht. Daardoor werden de onderhoudskosten hoger dan verwacht voor de oorspronkelijke bouwer die het bouwen en het onderhoud in een contract had verkregen.

De achtste aanbeveling kon maar door weinig mensen in het publiek direct onderschreven worden, maar Hein beval aan om dit toch te doen als de business case niet meer positief is. Dat is namelijk: stop gewoon met het project. De negende aanbeveling is om vriendelijk te blijven en vrienden te maken. Iedereen in het publiek kon dit onderschrijven. De tiende aanbeveling is om klimaatmitigatie in het project in te bouwen. Hierbij toonde Hein een plaatje van Jakarta, waar een muur is gebouwd om de zee tegen te houden. Niet een heel duurzame en zelfs gevaarlijke oplossing, zo leek dat. De laatste aanbeveling is het besef dat jijzelf het grootste risico bent voor het project, je eigen vooroordelen en je inwaartse blik op het project, zonder goed naar buiten te kijken. De stemming onder het publiek was hierop fifty fifty.

Tot slot nam Hein nog een paar stellingen door met het publiek die tot enige discussie leidden, bijvoorbeeld dat cost engineers met reference class forecasting moeten gaan werken en dat DACE naast een prijzenboekje ook een boekje met reference class forecasting moet uitbrengen.

>> Bekijk de stellingen





INCOSE
De tweede spreker was Marcel van de Ven, adviseur Systems Engineering bij Heijmans. In zijn presentatie wilde hij niet zozeer ingaan op wat Systems Engineering is, maar de op de samenhang tussen Systems Engineering, Value Engineering en Cost Engineering. En op een mogelijke samenwerking tussen DACE en INCOSE, de International Council on Systems Engineering. De aanleiding om op deze DACE-bijeenkomst een presentatie te houden was dat Hein de Jong eerder bij INCOSE een presentatie over Value Engineering had gehouden; deze bijeenkomst wilde Marcel dat graag doen bij DACE. Daarna gaf Marcel een korte beschrijving van INCOSE.

Vervolgens toonde Marcel de definitie van Systems Engineering volgens INCOSE met een woorden als integraal en transdisciplinair voor techniek, management, informatica en sociale wetenschappen. Ook de gerichtheid op systematische benadering en de levensclus komen daarin voor. Wat dat laatste betreft zet het woord engineering in Systems Engineering de goede luisteraar misschien op het verkeerde been: het bestrijkt alle fasen van idee naar studie, ontwerp en engineering, bouw, gebruik en sloop of hergebruik. Er is ook een Nederlandse definitie die wat praktischer is. Overigens houdt het woord systems in Systems Engineering in dat het door mensen gemaakte objecten of diensten zijn, dus geen natuurlijke zaken als een boom of een bos of iets dergelijks.

Hierna werden enkele processen uit Systems Engineering in hoofdlijnen doorgelopen. Dat begon met de processen ter verkrijging van het systeem zoals het inkoop- en leveringsproces. Verder de organisatiebrede processen zoals voor HRM, kwaliteit- en kennismanagement en life cycle inrichting. Ook de technische management processen zoals voor planning en control werden kort aangestipt evenals de technische processen zoals requirements engineering, systeem architectuur, implementatie, gebruik, beheer en onderhoud. Om zicht te krijgen op het detailniveau toonde Marcel een plaatje met een overview van Systems Engineering met de relaties tussen de verschillende stappen. Daarbij werd duidelijk gemaakt dat Systems Engineering niet alleen de techniek betreft maar ook de inrichting van het proces en organisatie eromheen, inclusief de interactie met de omgeving.

Ook werd het bekende V-model getoond voor ontwikkeling van een ontwerp van Schetsontwerp, naar Voorlopig Ontwerp, Definitief Ontwerp, Technisch Ontwerp, Uitvoeringsgereed ontwerp, met hun respectieve connectie wat betreft keuren/testen met de gerealiseerde (sub)systemen. Ook het Z-model was hierin vervlochten, waarbij is te zien hoe binnen iedere ontwerpfase van specificatie naar ontwerp wordt gekomen. Hierbij maakte Marcel nog eens inzichtelijk wat het verschil is tussen verifiëren en valideren. Als de afzonderlijke eisen wat betreft gewicht, materiaal, kleur, hoogte en temperatuurbestendigheid zijn geverifieerd betekent dat nog niet dat het gewenste koffiebekertje is verkregen; een simpele ronde klomp plastic voldoet hier ook aan. De achterliggende wens van het bekertje komt uit het validatieproces met de klant.

Overigens wordt Systems Engineering in Nederland vooral toegepast voor Eisenmanagement, Ontwerpen en Verificatie en Validatie. Voor andere processen zoals HRM, Projectmanagement, Kwaliteitsmanagement en beheer en onderhoud worden andere processen toegepast; hierbij kan gedacht worden aan bijvoorbeeld Prince voor Projectmanagement en ISO9000 voor Kwaliteitsmanagement.

>> Bekijk hier de presentatie van INCOSE

European Medicines Agency
Een case waar Systems Engineering met succes is toegepast door Heijmans is de bouw van het European Medicines Agency in Amsterdam, nadat besloten werd dat deze vanwege de Brexit uit Londen moest verhuizen. Hiervoor waren slechts 12 maanden beschikbaar en dat hield in dat afgeweken moest worden van de traditionele Systems Engineering aanpak. Er is gekozen voor een scrum-aanpak, met risicogestuurd werken waarbij de opdrachtgever mee moet doen en ook besluiten moet durven nemen. Daarbij wordt duidelijk wat nu moet gebeuren en wat nu mag en wat later moet gebeuren en wat dan mag, met de Moscow techniek. Voor ieder bouwblok wordt in eenmaal SO, VO, DO etcetera uitgevoerd, waarbij overdimensionering en latere reparaties geaccepteerd worden.

De processen uit Systems Engineering werden als ondersteuning gebruikt, niet als wet van Meden en Perzen. Voer het gesprek als een proces uit Systems Engineering lastig is uit te voeren en pas indien nodig processen aan, en blijf altijd communiceren. Alleen wat betreft veiligheid werden geen compromissen toegelaten. Al met al heeft dat ertoe geleid dat het gebouw op tijd klaar was en in gebruik kon worden genomen.

Tenslotte liet Marcel zien hoe Systems Engineering en Value Engineering elkaar kunnen completeren. Hij lichtte daarbij de tweede stap uit de Value Engineering, de functie-analyse, eruit, waarbij met Hoe? en Waarom? vragen een decompositie wordt gemaakt. Dit kan goed worden toegepast in het validatieproces dat in Systems Engineering wordt gebruikt. Marcel liet dat aan de hand van een plaatje zien. Daarbij gaf hij aan dat Systems Engineering en Value Engineering gebruik maken van dezelfde principes, alleen met een andere invalshoek. Met andere woorden, de twee methodieken zijn twee zijden van dezelfde munt. Een goede reden voor het bestuur van INCOSE en DACE om met elkaar in gesprek te gaan en die afspraak staat gepland.

Marcel sloot af met de woorden, dat alles wat wordt ge-engineerd kosten veroorzaakt, maar niet alles wat wordt ge-engineerd levert waarde.

Sturen op waarde
De derde spreker was Timme Hendriksen, coördinator Value Management bij Prorail. Hij begon met de opmerking dat waarde creëren niet eenvoudig is. Natuurlijk met Systems Engineering valt een degelijk ontwerp te maken, maar de vraag blijft wat waardevol is. Uiteindelijk hebben we er ook niet alles voor over om het uiteindelijk te maken. Daarnaast geldt dat men er bewust van moet zijn dat de vraag kostenveroorzaker nummer één is. Ofwel ‘All cost is for function’ zoals Lawrence Miles formuleerde.

Om dat toe te lichten haalde Timme de bekende formule uit Value Engineering tevoorschijn: Waarde = (Functie x Prestatie)/Middelen. Er kan heel technisch naar deze formule worden gekeken en om de waarde te verhogen kan de prestatie worden verhoogd of de functie worden verbeterd; ook de in te zetten middelen zoals geld, energie of CO2 verbruik kunnen worden verlaagd. Maar los van deze sommetjes is waarde uiteindelijk mensenwerk, het moet met elkaar worden besproken en bepaald. Dit is de zachte kant van Value Engineering: samen eens worden in het gesprek over de waarde, over wie wat nodig heeft. Er kan ook pas goed over de waarde worden gesproken als er al een idee of ontwerp ligt, dus de timing is ook belangrijk wanneer value management wordt gestart.

Verder is het zo dat een project vaak begint met een behoefte die compleet anders kan zijn als 5 of 10 jaar later het project wordt opgeleverd. Een project kan besluiten de ogen te sluiten voor de veranderende behoeften en gewoon door te gaan alsof niets verandert of het project beweegt met alle veranderingen mee, met het risico van alle changes op het project.

Timme liet een plaatje zien van de waardeketen, van gebruiker/klant naar techneut met alle lagen die daartussen zitten. Zo is te zien dat de techneut ver af staat van de mensen die een behoefte hebben.

Aan de hand van een tabel met 5 alternatieven met ieder hun eigen prestatie en kosten, vroeg Timme aan het publiek welk alternatief vanuit de klant het beste was. Dat was niet alleen alternatief 3 met een totale prestatie van 110 en kosten van 11 miljoen euro zoals het publiek dacht, maar ook alternatief 5, met een totale prestatie 80 en kosten van 8 miljoen euro. Die laatste geeft de klant de mogelijkheid 3 miljoen euro aan andere zaken te besteden. De klant zit met andere woorden soms in een andere film dan de techneut.

Als case werd vervolgens de Intelligent Platform Bar opgepakt. Dit is de informatiebalk die in Schiphol boven de perrons hangt en die de reizigers aangeeft waar de instappunten voor de volgende trein zijn. Deze is ingezet om de platformveiligheid te verhogen; de stijgpunten liggen op Schiphol dicht bij elkaar en om die reden bleven reizigers op een kluitje wachten op het perron. De balk zorgt ervoor dat reizigers zich beter verspreiden over het perron, wat de veiligheid verbetert en daarbij de capaciteit van in/uitstappen verhoogt. Andere duurdere en ingewikkelder ingreep zou zijn het aantal stijgpunten te verhogen. Goed is om te beseffen dat de gebruiker uiteindelijk geen behoefte heeft aan het project, met alle functies voor treinidentificatie, configuratie, informatie-voorziening en wat daarbij hoort, maar alleen aan het effect van het project, een veilige instapplek zonder al te veel gedrang.

>> Bekijk hier de presentatie Sturen op waarde

Zaklamp
Waarom de context altijd belangrijk is werd aangetoond met een zaklamp. De beveiliger wil deze behalve als flexibele lichtbron misschien ook gebruiken om eventueel mee te kunnen slaan. De bergbeklimmer heeft daarnaast als eis dat deze handsfree kan worden ingezet. De context zorgt voor meer kosten; de essentie van de lamp, het geven van licht, is maar een kleine fractie van de kosten. Kortom de essentie is essentieel maar eigenlijk bijzaak qua kosten. Dit kan in Value Engineering worden vertaald in een tabel voor het bepalen van het waardeprofiel, dat aangeeft wanneer een project/product succesvol is. Daarin worden essenties, zonder welke er geen project is, met meerwaarde, waarvoor men bereid is extra in de buidel te tasten, tegen elkaar afgezet.

Terugkomend op de Intelligent Platform Bar, deze was zeker 17 maal duurder dan een oorspronkelijke test die op een ander station was uitgevoerd. Dat komt dan met name door de meerwaarden die aan het project worden meegegeven. Een voorbeeld daarvan is toekomstvastheid om bijvoorbeeld later ook reclameboodschappen toe te kunnen voegen aan de balk.

Vervolgens toonde Timme een zwarte pagina. Het bleek dat we in een doos zaten en niets kunnen zien. De boodschap is om out of the box te denken om te zien hoe goed de box is.

Daarna werd een aantal waardestrategieën doorgenomen. Allereerst de strategie waarbij de functie en prestatie vast staan. De focus is daarbij op het zich ontwikkelende ontwerp, waarbij de kosten kunnen variëren. Als tweede de strategie waarbij de kosten vast staan, de design to cost strategie. De functie en de prestatie kunnen daarbij variëren. Als derde de strategie waarbij de functie en prestatie op minimaal niveau worden vastgesteld, de zero based design. Hierbij variëren de kosten. De uiteindelijke waarde is dan heel basic. Als laatste de Value Engineering strategie, waarbij functie, prestatie, kosten en waarde kunnen variëren. Naar verwachting geeft die de beste waarde van een project of product.

Vervolgens werd een plaatje getoond van wat Value Engineering doet in de projectdynamiek. Op geregelde punten in het project wordt gereflecteerd op wat zojuist is opgeleverd, om te bepalen of het geld nog steeds naar de juiste zaken gaat. De ervaring is dat met deze reflectie een project uiteindelijk sneller en beter verloop dan traditioneel als dat niet wordt gedaan. Op een tegeltje had Timme geschreven: Teruggaan is vooruitgaan. Op welke punten in het project Value Engineering exact wordt ingezet is afhankelijk van zaken als grootte, complexiteit en duur van het project. Timme liet hier een plaatje zien met vijf mogelijke punten, echter alle vijf zullen zelden altijd nodig zijn; gemiddeld zal dit op twee of drie punten zijn; soms is één genoeg

Timme liep nog in hoofdlijnen de zes stappen uit een Value Engineering studie langs, van informatiefase waar stakeholders sterk betrokken worden, naar functieanalyse waar afstand wordt gecreëerd en denkruimte wordt gemaakt, naar creatieve fase en vervolgens evaluatiefase waar de zin van de onzin wordt gescheiden. En tenslotte de ontwikkel- en presentatiefase.

Er werd geëindigd met de termen Value Thinking, Value Management en Value Engineering in hiërarchie te plaatsen. Value Engineering wordt daarbij gezien als de eenmalige uitvoering van een waarde studie conform het eerder getoonde stappenplan. Value Management is meer de bepaling op welke punten in het project de inzet van Value Engineering van toepassing moet zijn, als onderdeel van een geïntegreerde projectaanpak. Project Thinking betreft meer de organisatie zelf en de bijhorende mensen, in hoeverre het waarde denken onderdeel is van het DNA.

Als laatste activeerde Hein de Jong nogmaals het publiek door de vraag voor te leggen hoe Systems Engineering, Value Engineering en Cost Engineering beter zijn te integreren. Hiertoe toonde hij een QR code waardoor iedereen in het publiek in staat was zijn of haar ideeën op te geven. Dit ging van rijp naar groen en leverde een aardige discussie op. Daarna was iedereen eraan toe om de dorst te lessen en werd overgegaan naar de afsluitende borrel.