In het vorige artikel bekeken we de linkerkant van het V-model: de wereld van behoeften, functies, eisen en ontwerp. Uiteindelijk komt echter het moment waarop het ontwerpen stopt en het realiseren begint. Hoe goed een ontwerp er ook uitziet op papier, uiteindelijk telt maar één ding: werkt het ook in de praktijk? Daarmee komen we aan bij de rechterkant van het V-model: de fase waarin plannen werkelijkheid worden!
Gedurende (en na afloop van) realisatie moet echter ook aantoonbaar worden gemaakt dat het werk voldoet aan de behoeften, functies en eisen die aan de linkerkant zijn vastgesteld. Daarbij komen begrippen als verifiëren, testen en keuren al snel om de hoek kijken. Over de verschillen daartussen bestaat regelmatig verwarring. In een eerder artikel zijn we hier uitgebreid op ingegaan. Kort samengevat: verificatie is het aantonen dat aan een eis is voldaan; testen en keuren zijn mogelijke methoden om dat te doen. Dit stopt niet na het ontwerp; door tijdens de uitvoering ook verificaties uit te voeren, voorkomen we dat een papieren werkelijkheid ontstaat waarin een ontwerp wel klopt, maar het gerealiseerde werk niet.
Van component terug naar klantvraag
Verificatie aan de rechterkant van het V-model vindt plaats op verschillende systeemniveaus. Waar aan de linkerkant stap voor stap wordt ingezoomd van klantbehoefte naar componenten, wordt aan de rechterkant juist weer uitgezoomd van componenten naar een integraal systeem dat voldoet aan de oorspronkelijke klantvraag.
Naarmate onderdelen verder worden geïntegreerd, verschuift de focus van individuele componenten naar het functioneren van het systeem als geheel. Op componentniveau wordt vastgesteld of afzonderlijke onderdelen correct functioneren. Vervolgens wordt tijdens integratietesten beoordeeld of deze onderdelen ook daadwerkelijk samenwerken zoals bedoeld. Daarna komt het systeemniveau in beeld: functioneert het volledige systeem conform de eisen? Uiteindelijk volgt de acceptatie door de gebruiker. Daarbij staat niet alleen de vraag centraal of het systeem technisch werkt, maar of de oorspronkelijke behoefte daadwerkelijk is ingevuld.
Het V-model suggereert hierbij soms een strak chronologisch verloop. In de praktijk lopen deze niveaus echter door elkaar heen. Voor sommige delen van het werk kan al een integratietest zijn uitgevoerd, terwijl andere delen nog op component niveau worden getest. Belangrijk is dat uiteindelijk terug wordt gekomen bij de vraag: voldoen niet alleen de afzonderlijke onderdelen, maar ook het geïntegreerde systeem (het uiteindelijke Werk) als geheel aan de oorspronkelijke klantvraag?
Waarom aantoonbaarheid vaak lastig blijkt
Daartoe worden op veel projecten keuringen, testen, inspecties e.d. uitgevoerd. Toch hebben verassend veel projecten moeite om bij oplevering aantoonbaar te maken dat aan het geëiste is voldaan. De oorzaak zit meestal niet in het ontbreken van de controles, maar in het ontbreken van de verbinding tussen de linker- en rechterkant van het V-model.
Aan de linkerkant worden behoeften, functies, eisen en ontwerpkeuzes vastgelegd. Aan de rechterkant moet vervolgens worden aangetoond dat aan deze specificaties is voldaan. Wanneer die koppeling onvoldoende expliciet wordt gemaakt, ontstaan problemen. Verificaties zijn uitgevoerd, maar niet geordend per fase en gekoppeld aan keuringsregistraties. Keuringsregistraties bestaan wel, maar zijn niet herleidbaar naar contracteisen. Bewijsstukken zijn verspreid opgeslagen over verschillende systemen en projectmappen.
Op het moment van oplevering ontstaat vervolgens een zoektocht naar bewijs dat al maanden eerder beschikbaar had moeten zijn. Wat tijdens de uitvoering relatief eenvoudig had kunnen worden vastgelegd door de uitvoerder, kost aan het einde van het project alsnog veel tijd en geld. Herleidbaarheid is daarom een belangrijk principe binnen het V-model, zichtbaar door de vele verificatie en validatiepijlen tussen de linker- en rechterkant van het model. Al het gerealiseerde werk moet terug te leiden zijn naar een behoefte, functie, eis of ontwerpkeuze aan de linkerkant; alleen dan ontstaat een sluitende lijn van klantvraag naar aantoonbaar resultaat.
De oplossing ligt bij het vooraf nadenken over de manier waarop kwaliteit wordt aangetoond. Welke eisen vragen om een verificatie tijdens de realisatie? Welke verificatiemethode hoort daarbij? Welke registraties moeten worden vastgelegd en hoe is dit herleidbaar naar de betreffende (contract)eisen?
Ook de kwaliteit van keuringsregistraties verdient daarbij aandacht. Een afgevinkt “ja” of “nee” zegt immers weinig over de daadwerkelijk geleverde kwaliteit. Goede keuringsregistraties leggen vast wat is gecontroleerd, hoe dit is gecontroleerd, wat de meetresultaten waren en op basis waarvan de conclusie is getrokken. Alleen dan ontstaat bewijs dat ook maanden later nog uitlegbaar en herleidbaar is.
Vertrouwen of aantonen?
Een veelgehoorde klacht is dat de focus op aantoonbaarheid is doorgeslagen. Hoeveel aantoonbaarheid is nodig? Opdrachtgevers willen graag zekerheid, en vragen om uitgebreide keurings- en verificatiedossiers. Opdrachtnemers ervaren dit als een administratieve last en als een gebrek aan vertrouwen op hun vakmanschap.
Het V-model geeft hier geen pasklaar antwoord op. Het laat wel zien wáár verificatie- en validatieactiviteiten ten minste moeten plaatsvinden, maar niet in welke omvang of met welke diepgang. De manier waarop dit wordt ingericht hangt o.a. af van de aard van het project en de risico’s die spelen. Vanuit ProcessMinded zoeken we daarbij, zowel aan Opdrachtgevers- als Opdrachtnemerszijde, naar een pragmatische balans. Kwaliteitsborging mag nooit als doel hebben zoveel mogelijk formulieren te produceren. Het doel is aantoonbaar te maken dat risico’s worden beheerst en dat het opgeleverde werk voldoet aan de eisen die eraan zijn gesteld. Niet ieder Werk vraagt om dezelfde mate van aantoonbaarheid. Goede afspraken hierover tussen Opdrachtgever en Opdrachtnemer zijn daarom essentieel. Drie handreikingen waar OG en ON het tijdig over moeten hebben:
- Verificatieplannen realisatiefase: Bepaal al tijdens de ontwerpfase welke eisen in de realisatiefase moeten worden aangetoond en welke verificatiemethode daarbij hoort. Valideer deze aanpak met Opdrachtgever voordat de uitvoering start.
- Keuringsplannen: Stem af wat, hoe en op welk moment er gekeurd gaat worden. Niet ieder onderdeel van het werk kent immers hetzelfde risicoprofiel. Stem de keuringsplannen af op de risico’s van het project en de informatiebehoefte van beheer- en onderhoudspartijen.
- Opleverdossier en as-built info: Een goed opleverdossier ontstaat niet aan het einde van een project. Het wordt gedurende het hele project opgebouwd. Bespreek daarom al bij de start van een project welke informatie, registraties en as-built gegevens nodig zijn voor overdracht naar de beheer en onderhoud partijen.
De rechterkant bewijst het succes van de linkerkant
Als de linkerkant van het V-model zorgvuldig is doorlopen, vormt dit een vliegende start voor de realisatie. Eisen zijn expliciet gemaakt, keuzes zijn onderbouwd en ontwerpbesluiten zijn herleidbaar vastgelegd. De rechterkant van het V-model maakt vervolgens zichtbaar of deze voorbereiding daadwerkelijk heeft geleid tot het gewenste resultaat.
Dit is de kracht van het V-model: een integraal raamwerk dat de volledige levenscyclus van een project verbindt. Van klantvraag tot ontwerp. Van ontwerp tot realisatie. En van realisatie tot aantoonbaar resultaat. ProcessMinded ondersteunt opdrachtgevers én opdrachtnemers dagelijks bij vraagstukken aan beide kanten van de V. Van beleidsvertaling en eisenmanagement tot werkpakketmanagement, verificatie, kwaliteitsborging en opleverdossiers.
Daarmee sluiten we dit drieluik af. Hopelijk kijk je vanaf nu anders naar het V-model: niet als een bekende praatplaat uit een SE presentatie, maar als een praktische leidraad om projecten beheerst van behoefte naar aantoonbaar resultaat te brengen.
Auteur van dit artikel
