Validatiemanagement

De vraagspecificatie beschrijft de wens van de opdrachtgever. Of tenminste, dat hopen we. Want de werkelijkheid is vaak weerbarstiger. In veel gevallen komt dat omdat  de opdrachtgever een ontwerp terugvertaalt naar functionele eisen. Het door de opdrachtnemer gemaakte ontwerp voldoet dan wel aan de vraagspecificatie, maar niet aan al die specifieke wensen van de opdrachtgever die niet of slecht beschreven zijn.

Samen ontwerpen

Het gevaar ontstaat dat opdrachtgever en opdrachtnemer een technisch overleg gaan initiëren. De opdrachtgever benoemt een technisch manager die als vraagbaak dient voor de ontwerpers van de opdrachtnemer. De technisch manager koppelt deze vragen dan terug naar de ontwerpers van de opdrachtgever. Deze geven dan aan hoe het ontwerp er uit moet zien. De verantwoordelijkheid voor het ontwerp verschuift op die manier langzaamaan weer naar de opdrachtgever. En de wijzigingen gaan de andere kant op.

Durft de opdrachtnemer geen verantwoordelijkheid te nemen? Of andersom, durft de opdrachtgever de ontwerpverantwoordelijkheid uit handen te geven? Zolang de opdrachtgever blijft controleren of het ontwerp voldoet aan hun wens, zal de opdrachtnemer bij haar goedkeuring vragen op het ontwerp. 

Stel dat we als opdrachtgever onze handen volledig aftrekken van het ontwerpen en de controle daarop, hoe slecht zou het eindresultaat dan zijn? Zou het gevaarlijk zijn voor de gebruiker of zouden de beheerskosten dramatisch omhoog gaan? Ik betwijfel het.

Het beste ontwerp

Wie ontwerpt er beter, de opdrachtgever of de opdrachtnemer? Beiden, maar op een ander vlak. De opdrachtgever kijkt vanuit de gebruiker en de beheerder. Een ontwerp dat voldoet aan de normen kan nog steeds beter gemaakt worden wanneer ervaringen uit de gebruiksfase worden toegevoegd. Een Opdrachtnemer zal bij een ontwerpopdracht ook uitvoeringsaspecten meenemen, en uiteraard kosten. De opdrachtgever heeft op dit punt het nakijken. Hoe krijgen we the best of both worlds?

De wens en de eisen

De opdrachtgever heeft een wens in zijn hoofd en die is vertaal als eisen in de vraagspecificatie. Soms zijn eisen onvoldoende in de vraagspecificatie opgenomen en is de wens van de opdrachtgever niet duidelijk. Soms ook zijn de eisen op meerdere manieren in te vullen. De opdrachtnemer haalt dit vaak aan door te zeggen dat ze twee oplossingrichtingen hebben en dit willen overleggen met de opdrachtgever. Deze geeft dan niet thuis omdat de opdrachtnemer toch ontwerpverantwoordelijkheid heeft en moet nemen. Tegelijkertijd zijn ze niet tevreden over het ontwerp. Een onbevredigende situatie.

Validatiemanagement

Een onderdeel van het werk van de aannemer is het valideren van het systeem. Met een validatie wordt gecontroleertd of het juiste systeem is gemaakt (doet het wat de klant wil). Ofwel voldoet het ontwerp aan de wens van de klant. En daarover overleggen is absoluut niet samen ontwerpen. Immers zal de opdrachtnemer zelf een oplossing moeten bedenken om de wens van de opdrachtgever te realiseren.  

Ontwerpoverleggen zullen vervangen moeten worden door validatieoverleg. Zowel de klant als de opdrachtnemer hebben hierin een verantwoordelijkheid, anders dan bij het ontwerpen.

IPM model

Het  IPM model van Rijkswaterstaat, dat steeds meer door andere overheden wordt geadopteerd, kent tijdens de uitvoerngsperiode een technisch manager. Dit suggereert dat deze persoon technische kennis heeft die ingezet wordt op het project. Beter zou zijn om een validatiemanager te hebben. Iemand die zich buigt over de wensen van de opdrachtgever, en daarmee de stem is van de gebruikers en de beheerders. Als deze persoon aanspreekbaar is voor de opdrachtnemer over de wens van de klant, dan zal de opdrachtnemer zijn ontwerpverantwoordelijkheid moeten nemen.