Van Aannames naar Aantoonbaar

Hey jij! Leuk dat je luistert naar onze podcast. Dynamiek in techniek staat voor voortdurende verandering, ontwikkelingen en vooruitgang. In deze podcast duiken we in de bewegingen die de infrabouw, energie en industriesector vooruit stuwen.

En laten we zien hoe die dynamiek de sleutel is tot succes. En vanuit DP, wat we ook van klanten vaak wel terugkrijgen, is dat we er gewoon op een hele pragmatische manier mee om kunnen gaan. En dat vind ik wel heel erg waardevol.

Verificatie en validatie zonder papieren tijger
Dus we zetten V&V in op een doelmatige manier dat we uiteindelijk wel alles goed hebben aangetoond, zoals ook van ons verlangd wordt in de contracten om betaald te krijgen, maar we draaien daar niet in door. Vandaag bespreken we, dit zijn wij, Dutch Process Innovators. Wie wij zijn, wat drijft ons en waarom doen we wat we doen.

In deze rubriek nemen we je mee achter de scherm bij onze projecten, visie en aanpak. Geen geheimen, gewoon eerlijk over wie we zijn. De vorige podcast ging over het belang van elkaar willen begrijpen om samen succesvolle tenders en projecten te doen in ons mooie sector.

Hierin zie ik de brug naar verificatie en validatie. Wat meer de harde kant is van eisen en de aantoonbaarheid van deze eisen. Maar wellicht hebben we ook een zachte kant nodig om dit te bereiken.

Kennismaken met Ruben, Jasper en John
Vandaag zitten we aan tafel met Ruben van Wezep en Jasper Zonneveld. Zelf leidt de podcast John Fizee als adviseurs vanuit Dutch Process Innovators. Ruben, misschien een korte introductie en even kijken wat drijft jou nou? Ik ben Ruben van Wezep.

Ik ben nu vier en een half jaar actief binnen Dutch Process Innovators als adviseur project en proces management en eigenlijk ben ik in deze vier en een half jaar tijd altijd betrokken geweest bij de beheersing van projecten en met name integrale projecten. En ook dat vind ik een hele leuke uitdaging. Alle projecten die zijn eigenlijk voor bedoeld om wat te realiseren, maar ik vind het juist de uitdaging in die integrale projecten, hoe kom je nou voorspelbaar en betrouwbaar tot zo'n resultaat.

En ook om daar dan een gedeeld beeld bij te creëren. Verificatie en validatie speelt daar natuurlijk een grote rol in. Dus dat is wat ik eigenlijk ook altijd zo leuk vind in mijn werk.

Bedankt Ruben. Jasper, wie ben je en wat drijft jou? Ik ben Jasper Sonnenveld. Nu drie jaar werkzaam, ook net als Ruben adviseur project en proces management binnen Dutch Process Innovators.

Daarvoor ook al enkele jaren in de projectbeheersing in de infra en bouw gezeten. Ik kom uit Rotterdam, woon daar gelukkig samen. En ik wil in deze podcast vooral vertellen wat ons werk nou interessant maakt in de projectbeheersing.

En voornamelijk op het gebied van verificatie en validatie. En daarin word ik vooral gedreven door het samenwerken in de grote complexe teams, waarmee we eigenlijk gigantische bouwwerken proberen te realiseren. En het is heel vet om dan daarop terug te kijken aan het einde van een project.

En te zeggen nou we hebben echt wat vets gepresteerd met z'n allen. En daar ben je dan een onderdeel van in het uitdenken van die strategie. Hoe gaan we daar komen? En dat vind ik heel mooi om uiteindelijk te laten zien.

Oké, nou top. Zelf ben ik John Vizee, senior adviseur S-management. In dat bezicht vooral betrokken bij de exploitatiefase van projecten.

In dat bezicht stuk minder betrokken met verificatie, validatie aan de voorkant. Maar vooral bij het gebruik. En is het nou zo dat die gebruikers ook krijgen wat ze eigenlijk aan de voorkant hadden gehoopt? Dus in dat bezicht ga ik jullie vandaag ook een beetje bevragen op dit onderwerp.

En misschien kunnen we de luisteraars even meenemen. Want verificatie en validatie, we hebben het al een paar keer gezegd. Maar het klinkt niet echt als lichte stof.

Doen we het juiste en doen we het juist?
Misschien eerst de toetsvraag. Wat is nou eigenlijk verificatie en validatie? Dat klopt. Het is inderdaad geen lichte stof.

En we hadden het er zelf ook al over. Het is af en toe wel wat saai. Maar het zit juist in de uitwerking ervan.

Waarin het leuk wordt. Dus we gaan eerst even toelichten wat het nou is. En daarna komen we hopelijk op het leuke gedeelte ervan.

Validatie, verificatie, verificatie, validatie. Welke volgorde is het nou? Op de projecten zie je meestal dat het altijd begint met validatie. Wat wil de klant dat wij gaan bouwen? En dat ga je toetsen bij elkaar.

Hebben we dat nou goed begrepen? En willen ze daar nou echt een brug over het water of willen ze een tunnel onder het water door? Dus die toetsvragen zitten heel erg in de validatie. Doen we het juiste? Met de E achter juist. En de verificatie zit daarna heel erg intern op de controleslagen.

Hebben we ook gedaan wat we beloofd hebben dat we gingen doen? Dus doen we het juist? We hebben een heel plan geschreven voor onze opdrachtgevers. Voeren we dat ook op de juiste manier uit? Ja, en misschien is het ook nog wel even goed om te benoemen dat het verificatie en validatie is eigenlijk een soort van tool als onderdeel van systems engineering. En eigenlijk, het systems engineering is bedoeld om complexe projecten behapbaar te maken en in kleine delen op te knippen.

Van contractstukken naar klantbehoefte
En vervolgens is verificatie en validatie daar dan een onderdeel van om handvatten te bieden om uiteindelijk te voldoen aan die klantbehoeften. Waarom doen wij als adviseurs wat we eigenlijk doen dan op projecten? Want wat doen we dan met verificatie en validatie? Nou, vanuit DPI zijn we vaak betrokken bij opdrachtnemers. En daar passen we dan ook vaak systems engineering toe, maar ook verificatie en validatie.

En daar kennen we eigenlijk een soort van standaard proces voor. Dus als we heel erg kijken naar dat proces, dan begint het dat we aan het begin van een project, dat kan beginnen met het ontwerp of met de realisatie, maar veelal eerst het ontwerp, krijgen we de contractstukken binnen, dan gaan we kijken naar welke eisen zitten er allemaal in de contractstukken en dan beginnen we met een zogenaamde documentenanalyse. En in die documentenanalyse gaan we naast dat we kijken naar de vraagspecificatie van de proceseisen of van de technische eisen, ook kijken naar de contractbijlagers.

En eigenlijk willen we daaruit destilleren wat wil die klant nou precies krijgen, wat heeft die ons uitgevraagd. Dat is voor mij al een stap in validatie, om gewoon duidelijk beeld te vormen van wat vraagt de klant precies. En doen wij dat nou vanuit een specifiale rol, of worden wij expliciet gevraagd om verificatie en validatie toe te passen? Je ziet vaak op de projecten zijn opgesplitst in verschillende teams.

Je hebt een ontwerpteam, je hebt een realisatieteam, je hebt vaak ook een procesteam, en naast omgevingsteams, assetmanagementteams. In het procesteam wordt er vooral gekeken naar de strategie van hoe gaan we aantonen dat we het juiste bouwen, dus het verificatie en validatiestuk. En uiteindelijk de verificatie zelf, die zal door ontwerpers gedaan worden.

Die moeten aantonen dat wat zij ontworpen hebben, dat dat inderdaad daarbij aansluit. Misschien kunnen jullie ons een beetje meenemen vanuit jullie ervaring. Ik merk gewoon dat het nog lekker theorie is, terwijl wij zijn natuurlijk mensen op projecten en we werken met andere mensen.

Iedere discipline draagt een deel van het bewijs
Wie betrekken jullie nou op zo'n project? Met wat voor andere mensen werken we nu samen? Je gaf al ontwerpers aan, zijn er er nog meer? Ja, het is best wel breed. Misschien moet ik het nog heel eventjes terugpakken naar het proces van systems engineering, en dan specifiek even de raakvlakken met verificatie en validatie. Dus dat begint met die documentanalyse.

En tijdens die documentanalyse hebben we eigenlijk alle expertise nodig vanuit het IPM team, of vanuit de verschillende disciplines, om dan die contractstukken te beoordelen, of ze relevante informatie bevatten, die we later in het traject of later in het project moeten gaan aantonen, middels de verificatie. Daarin merk je dus al dat er gewoon heel veel verschillende mensen betrokken zijn. En dat brengt dan ook uitdagingen met zich mee.

Vanuit DPI proberen we dat dan zo goed mogelijk in banen te begeleiden, dat mensen en juist geïnformeerd zijn, maar ook het juiste daarin doen. En dan vervolgens kunnen we met die informatie verder om de eisen analyse te doen. Oké, interessant dat we nu weten wie we allemaal betrekken.

Aannames toetsen voordat ze ontwerpbesluiten worden
Maar hoe ga je om met al die verschillende rollen? Hoe betrek je die dan bij het vraagstuk van verificatie en validatie? Je start in ieder geval met heel veel met elkaar het gesprek aangaan, over de aannames die ze ook doen op het project. Je merkt dat elke specialist heel veel kennis heeft. Het komt wel uit een bepaalde hoek.

En op basis van die informatie doet een specialist vaak aannames op het project. Het is belangrijk om die aannames te toetsen, te herkennen, en ook te zorgen dat die besproken worden met de opdrachtgever. En daar merk je heel erg dat wij met DPI een faciliterende rol hebben om dat te herkennen.

Dat we zaken op een andere manier interpreteren dan de opdrachtgever mogelijk bedoeld heeft. Dan zeg ik expres mogelijk, want misschien hebben we het wel goed, maar het kan zeker geen kwaad om het even te toetsen. De specialist bedoel je dan de ontwerper of is de specialist in elke fase iemand anders? De specialist is vaak in elke fase iemand anders.

Je ziet het VNV komt voornamelijk terug. Het grootste zwaartepunt ligt wel in de ontwerpfase. Want daar probeer je van alle informatie die de opdrachtgever heeft aangeleverd een ontwerp te maken.

En van daaruit ga je verder met je ontwerp de uitvoering in. En dan is er veel minder aan te passen aan het ontwerp. Dus je moet het wel aantonen.

Maar de gesprekken met de opdrachtgever over hoe ze het precies hadden gewild. Het is belangrijk dat je die daarvoor al grotendeels gevoerd hebt. Hoe vaak zit je dan bij elkaar of hoe vaak moet je die thermometer er even in prikken? Hoe vaak herkennen wij aannames? Dat zal per project heel erg verschillen.

Afhankelijk van de grootte van het project, de doorlooptijd. Maar heb je het over bijvoorbeeld een grote brug of tunnel die we moeten bouwen. Dan heb je het over doorlooptijd van jaren.

En dan zie je vaak dat we aan de slag gaan met ontwerpen. We hebben het volledige set aan eisen en documenten waar we wat mee kunnen. We duiken in ons ontwerphok en over vijf maanden komen we terug met een ontwerp.

Het is heel belangrijk om bijna op wekelijkse basis, vaak gebeurt het maandelijks, even te toetsen. Zijn we de juiste weg ingeslagen? Ja, en dat zit dan voornamelijk op een stukje verificatie ook. Wil je even terugkoppelen naar de eisen? Zijn we bezig de juiste dingen aan het ontwerpen? Oké, volgens mij hebben we het ook al over verschillende rollen.

Want eigenlijk tijdens het project ben je ook een stukje vertegenwoordiger dan van de opdrachtgever. Om eigenlijk te checken van is iedereen nu aan het maken wat de opdrachtgever eigenlijk graag wil. Maar aan de andere kant ben je als proces-innovator, als vizier, ook weer vertegenwoordiger van project.

Op het moment dat je met de uiteindelijke opdrachtgever aan tafel zit. Om eigenlijk te toetsen van hebben wij nou eigenlijk jouw vraag scherp. Klopt dat? Dus eigenlijk heb je twee brillen op, twee petten.

Ja, nou goed. Ik denk we acteren wel vaak in het team van de opdrachtnemer. Maar binnen dat team van de opdrachtnemer is het wel van belang dat we het belang en de behoeften van de opdrachtgever, van de aanbesteden in de dienst, wel scherp houden.

En dat doen we dan wel vanuit de rol van de opdrachtnemer. Maar goed, je moet daar wel oog voor blijven houden. En dat kan soms ook leiden tot een nieuw inzicht.

Dat de opdrachtgever de aanbesteden in de dienst toch in één keer een andere wens heeft. Dan dat ze heeft opgeschreven in haar contract. En dat leidt dan tot een wijziging.

Daar spelen we hier en daar wel het geweten van het van het team. Om dan maar eigenlijk de lastige vraag te blijven stellen. Of de opdrachtgever het wel zo bedoeld had.

Meestal is de reactie vanuit het team, ja natuurlijk hebben ze het zo bedoeld. Maar het kan geen kwaad om dat even te checken bij de opdrachtgever. Ja precies, want hoor je dan vaak zo hebben ze het opgeschreven.

Een badkamer, een brug en honderd interpretaties
Dat berust weer op aannames en interpretaties van de mensen uit het projectteam. En waarom is verificatie en validatie nou echt nodig op projecten? We kunnen toch ook gewoon bouwen wat er wordt gevraagd? Ja, dat zou heel makkelijk zijn als dat zo werkt. Misschien een goede vergelijking met je eigen huis verbouwen.

Stel je laat je aannemer de badkamer verbouwen. Dan is het al vaak lastig om aan de aannemer uit te leggen. Hoe moet die badkamer er precies uit komen te zien? En dan heb je het over contact van 1 op 1. Je geeft direct aan aan een aannemer wat hij gaat bouwen.

Dan zie je vaak dat het wel misgaat. Het raam zit op de verkeerde plek. Er zit toch geen douche in.

En als je dat nou groter maakt, dan heb je het over een opdrachtgeversorganisatie. Bijvoorbeeld Rijkswaterstaat, een tenet. Voordat dat project op de markt komt, zijn er 100 mensen mee bezig geweest.

Iedereen heeft een deel van de kennis op dat project. Dan gaat de aannemer er straks mee aan de slag. Dan zijn er weer 100 mensen, misschien wel 200, 300 mee bezig.

Zorg dan maar eens dat iedereen exact weet wat zij moeten doen op dat project. En als die informatie niet juist doorgegeven wordt van de initiële vraag, van we hebben een brug nodig, dan krijg je straks een tunnel. En daar gaat verificatie en validatie vooral over.

Het zit heel erg op die controleslagen. Elk stapje in je project, van doen we inderdaad nog wat we hebben afgesproken. Voorkomen dat we in die tunnelvisie terechtkomen.

Pragmatisch aantonen zonder bureaucratie
Scherp, scherp. Wat maakt dit proces innovators nou, als we die nou binnenhalen op ons project? Wat zorgt er nou voor dat we succesvol zijn op dit vraagstuk? Ik denk dat het tweeledig is. Ten eerste denk ik dat we vanuit DPI best wel meerwaarde kunnen bieden op het coördineren.

En dan ook de aannemer of de opdagnemer meenemen in het traject. Dus we zorgen er gewoon voor dat het allemaal goed geborgd wordt. Maar tegelijkertijd denk ik waar onze kracht ook in zit, is het pragmatisch ermee omgaan.

Want de geluiden die we ook steeds wel meer horen in de sector is, het wordt steeds meer een papieren tijger, we moeten toch ook gewoon bouwen. En ik ben het daar helemaal mee eens. We moeten, uiteindelijk het doel is de techniek buiten en dat we iets moois gaan realiseren.

En we kunnen het op papier ook allemaal wel mooi verzinnen en heel erg aantoonbaar willen maken. Maar het moet uiteindelijk wel het hogere doel dienen en dat is gewoon iets realiseren. En vanuit DPI en wat we ook van klanten vaak wel terugkrijgen, is dat we er gewoon op een hele pragmatische manier mee om kunnen gaan.

En dat vind ik wel heel erg waardevol. Dus we zetten V&V in op een doelmatige manier dat we uiteindelijk wel alles goed hebben aangetoond, zoals ook van ons verlangd wordt in de contracten om betaald te krijgen. Maar we draaien daar niet in door.

We voorkomen een stukje bureaucratie. Ja, zo kun je het wel benoemen. Zeker.

Proces teams zijn daar puur faciliterend in, richting het ontwerpteam en het uitvoeringsteam om uiteindelijk het mooie te bouwen. Ja. En hoe zorgen dan, aan de achterkant zei je net al een mooie woord aan toonbaarheid.

Het juiste niveau van aantoonbaarheid
Dat lijkt me een essentieel onderdeel van verificatie en validatie. Hoe vind je het evenwicht tussen bouwt je moertje niveau en gewoon precies doen om aan te tonen wat je aan de klantvraag voldoet? Ja, daar heb je hem precies te pakken. Want aantoonbaarheid is gewoon het keyword in verificatie en validatie.

De eisen zijn vaak opgeschreven, maar die zijn niet altijd helemaal duidelijk. Wat wordt daar dan mee bedoeld? Nou goed, dan kan je zeggen van we gaan in gesprek met de opdrachtgever over wat betekent die eis. Nou dat zien we ook wel als een stukje validatie eigenlijk.

En vervolgens als we dan een gedeeld beeld hebben van die eis, dan kunnen we doorgaan met verificatie en daarin het goede gesprek voeren en elkaar echt begrijpen wat ook in de vorige podcast eigenlijk aan bod is gekomen, is daarin gewoon heel erg belangrijk. Hebben jullie een concreet voorbeeld van hoe zo'n goed gesprek eruitziet? Het belangrijkste van die gesprekken is dat je ze zo vroeg mogelijk in het project voert. Dat je heel snel doorgrond wat de opdrachtgever nou vraagt.

En daarvoor ga je aan het begin van het project heel veel lezen, heel veel vragen opstellen en daarna direct naar de opdrachtgever om gewoon te kijken wat is nou dat niveau waarop je het allemaal aangetoond wil hebben. Wil je achteraf weten welk boutje of moertje ergens in een onderdeel van het project zit, of vind je het prima om te weten dat daar een elektriciteitskast zit en de tekeningen die heb je erbij en dat is ook voldoende. En dat niveau opzoeken dat is heel belangrijk aan het begin van het project, want dan weet de rest van het team wat ze allemaal op moeten schrijven gedurende het project.

Dat is ook wel waar de discussies in de praktijk vaak over gaan. Is het inderdaad prima om het hoogover aan te tonen of moet het echt op boutjes-moertjes niveau? En wat Jasper zegt, vooraf het gesprek aangaan met name met de opdrachtgever is daarin heel belangrijk. Dus eigenlijk als ik jullie goed begrijp moet je aan de voorkant het gesprek voeren, hoe je aan de achterkant een project wat buiten gemaakt wordt kan aantonen bij een opdrachtgever dat dat is wat ze hebben gevraagd.

Het verificatieplan groeit mee met het project
Wat hij nou eigenlijk overgedragen wil hebben in op- en afleverdossiers, zodat je daarop kan voorstellen. Ja klopt en een belangrijk onderdeel wat ons daarin helpt is het verificatieplan. Dat is eigenlijk ook altijd een stap die we uitvoeren in projecten waar we systems engineering en verificatievalidatie in toepassen.

Dus het opstellen zodra we alle eisen helder hebben van een verificatieplan. En dat verificatieplan daar staat precies in wie, wanneer en op welke manier die eis dan wordt aangetoond. Misschien de luisteraar die hoort nu verificatieplan.

Is dit iets wat je doet voor het ontwerp, tijdens het ontwerp, tijdens de realisatie? Wanneer vindt dit plan plaats? Het liefste stel je hem zo vroeg mogelijk op. Maar soms heb je nog niet alle informatie en weet je nog niet wat je aan het einde van het project exact gaat bouwen. En daarom zie je dat dat verificatieplan vaak bepaalde iteraties doormaakt.

Je stelt hem zo vroeg mogelijk op, dat je exact weet wat je gaat ontwerpen en hoe je dat ook gaat aantonen. Dus je maakt een verificatieplan en daar komt uiteindelijk in je ontwerpfase een verificatierapport voor het ontwerp uit. Wanneer staat hoe je dat dan hebt uitgewerkt.

En daarna vervolgt het stap in de realisatie, waarin je in principe weer hetzelfde doet. Je hebt ook daar weer je verificatieplan. Hoe ga ik buiten aantonen dat ik volgens tekening heb gebouwd.

Dus eigenlijk loopt het verificatieplan mee met de ontwerptekeningen. Hoe meer gedetailleerd je ontwerp wordt, hoe meer gedetailleerd je plan kan worden. Hoe concreter het wordt met wie nou wat moet doen.

En in bepaalde mate zie je dat er onderliggende plannen bij komen. Dus we weten dat we bepaalde eisen gaan aantonen in de uitvoering met keuringen. Dus dat staat in je verificatieplan.

Maar hoe die keuring er precies uit komt te zien. Ga je een foto maken, ga je alles nameten. Dat volgt later richting de uitvoering.

Wil je er nog wat op zeggen Ruben? Ja, wat Jasper zegt over dat zo'n verificatieplan kan evalueren door het project heen. Dat klopt inderdaad wel heel goed. En dat maakt het ook wel interessant.

Met name zie je dat op grotere projecten waarbij je bijvoorbeeld van een VO nog naar een DO moet en naar een UO en vervolgens naar de realisatie. Dan krijgen we vaak in het begin wat meer de hoogovereisen die we eerst alleen gaan aantonen. Dus die nemen we dan in eerste instantie ook alleen op in het verificatieplan.

En vervolgens als we in een meer gedetailleerd ontwerp gaan opstellen, ga je ook steeds meer van die eisen eigenlijk, zoals we het ook wel eens noemen, afvinken en verifiëren. En gedurende het project kan het ook best wel zo zijn dat omdat bepaalde eisen hoogover zijn opgesteld, dat we zelf afgeleide eisen gaan toevoegen om het maar zo concreet mogelijk te krijgen. En dat draagt dan ook wel weer bij aan het gedeelde beeld ontwikkelen samen met de opdrachtgever en uiteindelijk het voorkomen van verrassingen in het eindproduct.

Dus eigenlijk krijg je buiten wat je hebt gevraagd, denk aan die badkamer, je krijgt de badkamer die je wil en je krijgt ook nog de juiste papieren erbij die bewijzen dat dat eigenlijk is wat je hebt uitgevraagd en dat het voldoet aan… Dat er inderdaad een douche in zit. Ja, bijvoorbeeld. Mooi dat zo'n metafoor dan toch gelijk door zijn hele podcast heen meegenomen kan worden.

De verbindende rol van de adviseur
We zijn ook alweer bijna door de tijd, dus zo snel kan het gaan. Misschien wel handig om nog even terug te blikken op deze podcast om even samen te vatten wat we nou eigenlijk hebben besproken. Verificatie, validatie.

Het is eigenlijk een voorgeschreven methode, maar vanuit ons als adviseur is het een handvat, een middel dat wij eigenlijk toepassen op onze projecten om eigenlijk te begrijpen of we de klant goed begrijpen en of wij eigenlijk wel onze opdrachtgevers kunnen realiseren wat er uiteindelijk gemaakt moet worden. Mooi verwoord. Je ziet inderdaad dat alle kennis die zal uiteindelijk vanuit de engineers en vanuit de uitvoering moeten komen, die hebben echt de kennis van het vak en wat wij daar als DPI in doen is dat begeleiden en die gesprekken ook met de klant faciliteren, zorgen dat we de juiste dingen doen.

Mooi, wij vormen een brug tussen de verschillende partijen. Zeker, ja. Het is zeker een verbindende rol.

Klinkt bijna als topsport en misschien moeten we daar de volgende keer weer verder induiken wat dat dan weer met ons meebrengt. Bedankt mannen, dan houden we het hierbij. Leuk, dankjewel John.

Yes, bedankt John. Heb jij een onderwerp waar je meer over wilt weten of een vraag waar je al langer een antwoord op zoekt? Laat het ons weten en mail naar podcast.dpi.nu.