Case

HEEL bij Waterschap Nederdelta

Het project dijkversterking DoRa (Dok-Raamsweer) is onderdeel van het Hoogwaterbeschermingsprogramma (HWBP), een samenwerking tussen Rijkswaterstaat en de waterschappen. Het HWBP werkt aan de grootste dijkversterkingsoperatie die Nederland ooit heeft gekend. Daarbij zijn de veiligheidsnormen streng, terwijl de technische mogelijkheden groeien. Wat ook toeneemt, zijn de complexiteit van de omgeving en de uitdagingen die bijvoorbeeld de klimaatontwikkelingen met zich meebrengen.

Dijkversterkingsprojecten binnen het HWBP krijgen vorm met een IPM-team. De rollen binnen dit team krijgen in de beschrijving van de dijkversterking aandacht, net als de processen die we bij HEEL inzetten. Daarbij volgen we in de case de MIRT-fasering (Meerjaren programma Infrastructuur, Ruimte en Transport) zoals de HWBP- projecten die gebruiken. De voorbereiding van de dijkversterking bestaat uit de verkenningsfase gevolgd door de planuitwerkingsfase. Hierop volgt de realisatiefase voor verdere uitwerking van het ontwerp en de daadwerkelijke uitvoering van het werk.

In het kader van waterveiligheid toetst het waterschap NederDelta of de dijken die zij beheert aan de veiligheidsnorm, die in de Waterwet gesteld is, voldoen De beheerder van de primaire waterkering voert hiervoor een veiligheidsbeoordeling uit Hieruit blijkt of de kering aan de norm voldoet, en zo niet: wat er nodig is om de kering de komende jaren wel aan de norm te laten voldoen Een recente toetsingsronde laat zien dat een deel van de dijk tussen Dok en Raamsweer (DoRa) niet voldoet aan de wettelijke norm Dit vraagt om een aanpassing, oftewel: een dijkversterking Omdat het een primaire kering betreft, wordt de versterking gefinancierd en begeleid door het HWBP Het waterschap NederDelta blijft verantwoordelijk voor de voorbereiding en het uitvoeren van het project en de kwaliteit ervan.

OPLEVERING EN OVERDRACHT

VOORBEREIDING

Het waterschap gaat van start met de voorbereiding van het project. De projectmanager zet de eerste stappen en begint met het concretiseren van de projectopgave [1.1]. Zodra de projectopgave en de globale omvang van het project duidelijker worden, stelt hij of zij het team verder samen. Nu de contouren duidelijk zijn en het IPM-team is gevormd, vertaalt dit team de projectopgave in de betrokken scope bij deze opgave. De eerste systeemgrenzen krijgen vorm [1.2]. Ook bekijkt het team welke werkzaamheden nodig zijn om de voorbereiding te kunnen doen en wie daarvoor verantwoordelijk is [1.3] en [1.4]. Hiervoor wordt gebruik gemaakt van de HEEL Basis-WBS, die gebruikt kan worden om de werkzaamheden voor het project in beeld te brengen. In deze prille fase van het project brengt het team de basis voor inhoudelijke beheersing van het project op orde [11.2]. Vanaf nu wordt er ook veel informatie in het project gegenereerd, hetgeen vraagt om een goede ontsluiting en beheersing. De informatiemanager stemt in overleg met de beheerder (Asset Manager) af, volgens welke structuren de uitwisseling van areaalinformatie (beheerinformatie) aan de voor- en achterkant van het project plaats gaat vinden.

ITERATIEF (HERHALEND) PROCES

In deze case halen we, omwille van de leesbaarheid, processen één of enkele keren aan. Ten onrechte kan hierdoor het beeld van een lineair proces ontstaan. In de praktijk worden processtappen tijdens elke projectfase meerdere keren en cyclisch doorlopen. Bij elke verfijningsstap van het ontwerp worden de primaire stappen en natuurlijk ook verificatie en validatie doorlopen. Bepaalde risicovolle of maatgevende delen van de scope kennen daarbij soms meer cycli, en daarmee meer diepgang, dan minder risicovolle onderdelen.

VERKENNING

Het project start met de verkenning, waarbij het team tot een ontwerp op hoofdlijnen wil komen. Dit leidt uiteindelijk tot het voorkeurs-alternatief: een ontwerp dat zo goed mogelijk rekening houdt met alle belangen (zoals: beheer, milieu, natuur, meekoppelkansen, wonen, werken en recreatie). Hiervoor dient eerst helder te zijn wat de exacte opdracht is. Wat is de afbakening van het dijktraject? Welke stakeholders zijn er bij betrokken? En welke bestaande objecten (assets) worden geraakt? Samen met de beheerders van de dijk en omliggende objecten van derden, brengt het projectteam de behoeften in kaart. Daarbij wordt bepaald welke aanpassingen nodig zijn, wat het project uiteindelijk moet opleveren en wat belangrijk is voor het beheer en onderhoud van de dijk. Voor DoRa is er, naast de dijkversterking, de kans om bij te dragen aan de recreatiebehoefte op en rond de dijk. De omgeving kent weinig recreatie-mogelijkheden waardoor de parkeerplaats bij het strandje en de provinciale weg bij Raamsweer regelmatig overlast hebben van geparkeerde auto’s. Nieuwe recreatievoorzieningen kunnen de parkeerdruk verminderen. In deze fase worden ook de belangrijkste risico’s van het project in kaart gebracht. Deze zijn van belang om keuzes te maken bij bijvoorbeeld het benaderen van stakeholders, maar ook in de afweging tussen verschillende alternatieven.

Een stakeholderanalyse [2.1] brengt, op basis van de projectopgave en de scope, de diverse betrokkenen in kaart. Langs de dijk liggen bedrijven en wonen diverse gezinnen. Daarnaast zijn de interne stakeholders van het waterschap, zoals de beheerder, van belang; net als andere externe stakeholders als gemeente(n) en provincie. De analyse gaat in op de belangen en hoe elke stakeholder wordt betrokken [2.1]. Met veel van de stakeholders vindt een gesprek plaats om de klantwensen* in kaart te brengen [2.2]. Dit leidt uiteindelijk tot een honoreringsproces, waarbij op basis van verschillende criteria wordt afgewogen welke klantwensen als eisen* meegenomen moeten worden in het project [2.3].

Niet alleen de projectomgeving wordt geanalyseerd, ook het eigenlijke onderwerp van het project, het beschouwde systeem, wordt geanalyseerd [3.1]. De benodigde systeemprestatie wordt in eisen gevangen (gespecificeerd) [3.2]. Ook de gehonoreerde klanteisen worden omgezet tot verifieerbare systeemeisen. Op basis van de vastgestelde scope en de systeemeisen start het ontwerpproces [4.1], om via afweging van mogelijke oplossingen (met behulp van een Tradeoff Matrix, TOM) [4.2], tot een optimaal voorkeursalternatief te komen [4.3]. Met behulp van een verificatieplan en -rapport [5.2], [5.3] wordt aangetoond dat het voorkeursalternatief voldoet aan de gestelde eisen. Zoals toegelicht, is dit een iteratief proces dat vaker plaatsvindt, maar dat hier omwille van de leesbaarheid eenmalig is beschreven. Daarnaast is het van belang om, samen met de stakeholders die een bijdrage leverden aan de klantwensen, vast te stellen dat de vertaling naar het voorkeurs-alternatief aansluit bij de behoefte
[6.2], [6.3]. Nadat dit gezamenlijk is vastgesteld, wordt met dit voorkeurs-alternatief de verkenning afgesloten, voorzien van een ontwerpnota, een Klanteisenspecificatie met validatierapport [6.3], een Systeemeisen-specificatie [3.3] en Verificatierapport [5.3]. Dit dossier is input voor de volgende fase waarin een verdere uitwerking van dit voorkeursalternatief plaatsvindt.

* Binnen HEEL hanteren we de term klantwensen bij het inventariseren van behoeften. Als de wensen na een zorgvuldig afwegingsproces worden gehonoreerd, noemen we ze klant eisen. Deze eisen worden in het ontwerp meegenomen.

PLANUITWERKING

Na een positief besluit over het voorkeursalternatief start de planuitwerkingsfase. Belangrijkste doel hier is het nemen van een publiekrechtelijk besluit (project besluit/ Projectplan Waterwet). In deze fase werkt het team het voorkeursalterna-tief verder uit tot de voorkeursvariant; een plan met het detailniveau dat nodig is voor formele besluitvorming binnen het waterschap en HWBP en het verkrijgen van de planologische hoofdvergunningen.

Tot het Projectplan komen, betekent verdere uitwerking van het voorkeurs -alternatief en vraagt in deze fase om het opnieuw en gedetailleerder doorlopen van de primaire processen: structureren project, klanteisen-proces, specificatieproces en ontwerpproces. De keuzes hierbij geven aanleiding voor nieuwe gesprekken met stakeholders. Dit kan vervolgens leiden tot nieuwe klantwensen- en uiteindelijk eisen, voor het volgende uitwerkingsniveau. Denk bijvoorbeeld aan klanteisen vanuit de vergunningsverlening, over het afsluiten van wegen tijdens de realisatie, doordat nieuwe stakeholders in beeld zijn gekomen bij de keuze van het voorkeursalternatief. Ook kunnen keuzes op meer detailniveau tot aanvullende wensen vanuit de beheerder leiden. Deze klanteisen leiden op hun beurt weer tot een nieuwe specificatieslag, waarna weer wordt ontworpen, geverifieerd en gevalideerd. Voor deze specificaties kan gebruik worden gemaakt van de al eerder genoemde beschikbare basisspecificaties.

In het ontwerpproces zoekt het projectteam naar optimalisaties binnen het voorkeursalternatief. Deze optimalisaties werkt het team in deze fase uit in verschillende varianten [4.2]. Op basis van aan-vullend (grond)onderzoek rekent het vervolgens verder per dijkvak. Dit vraagt om ontwerpkeuzes en het per dijkvak kijken hoe dit deel van de dijk versterkt kan worden. Kiezen we bijvoorbeeld voor een damwand of past een verhoging beter? Zo vinden het specificatie [3.1] en ontwerp-proces hier gedetailleerder plaats. Met input uit het ontwerpproces vindt tijdens de verkenning en de planuitwerking al voorbereiding voor de uitvoering plaats. Dit zijn de zogenoemde conditionerende processen. Deze processen lopen over de faseovergangen heen.

De conditioneringsprocessen kunnen ook weer leiden tot nieuwe klanteisen en tot aanpassingen van de ontwerpkeuzes. Het kan bijvoorbeeld zorgen voor beperkingen in de bereikbaarheid vanwege een gasleiding die niet verlegd kan worden of randvoorwaarden ten aanzien van materieel. Dit alles wordt verder gespecificeerd totdat er een complete set aan eisen ontstaat [3.1].

Net als in voorgaande fasen, is het hier van belang om de risico’s mee te wegen in de te maken keuzes. Het risicodossier loopt daarmee dus ook gelijk op met het detailniveau van de te nemen besluiten. Daarnaast ontstaat steeds meer informatie, waardoor ook het managen van deze informatie een grotere rol speelt. Zodra het ontwerp voldoende is uitgewerkt om een goed beeld te kunnen geven van de effecten, zorgt een publiekrechtelijk besluit voor af-ronding van de planuitwerkingsfase.

REALISATIE

Nadat de wettelijke procedures zijn doorlopen en de weg vrij is om het project ook daadwerkelijk te gaan bouwen, start de realisatie-fase. Hier maken het uitvoeringsontwerp en de uitvoering deel van uit. Zodra het startsein is gegeven, kan het project formeel beginnen.

In deze fase zorgt het team voor detaillering van de Voorkeursvariant tot een ontwerp dat geschikt is om te bouwen. Vaak ondersteunt een ingenieursbureau, vaak de partij die ook in de planuitwerkingsfase al betrokken is, het waterschap met het uitwerken van het ontwerp tot de marktbenadering. Voor bepaalde onderdelen worden varianten ontwikkeld en tegen elkaar afgewogen. Hiervoor gelden dezelfde principes als in de verkenning en planuitwerkingsfase. Daardoor zijn ook de primaire processen weer van toepassing. Verder is het wederom van belang om bij de verdere uitwerking de stakeholders te betrekken en de gemaakte keuzes te valideren. Uiteindelijk is het ontwerp voldoende uitgewerkt om over te gaan tot de marktbenadering. Voor het uitvoeringsontwerp en de uitvoering zoekt NederDelta een aannemer. De systeemeisen die in de verschillende fasen zijn gespecificeerd worden opgenomen in een vraagspecificatie, de gegadigden maken op basis hiervan een aanbieding en een aannemer wordt geselecteerd.
De gecontracteerde aannemer start met het uitwerken van het uitvoeringsontwerp. Daarnaast gaat hij het project voorbereiden, zodat het uitgevoerd kan gaan worden. Denk daarbij aan het inrichten van de bouwterreinen en het aanleggen van de bouwwegen, maar ook aan de fasering van werkzaamheden. Waar nodig vindt conditionering plaats, denk aan het kappen van bomen en het verleggen van kabels en leidingen die nog niet eerder zijn verlegd. Aansluitend kan de schop de grond in, de dijkversterking start nu concreet. Buiten wordt op veel plekken gewerkt, de aannemer voert zijn keuringen en testen uit [5] en samen met de stakeholders worden integrale testen uitgevoerd. De aannemer bouwt in deze fase belangrijke dossiers op; afleverdossiers per gereed werk pakket en een opleverdossier voor bij de oplevering van het werk. Dit is straks nodig om te kunnen aantonen dat de dijk gebouwd is conform de specificaties. Gedurende de bouwfase worden delen van dit dossier al aangeleverd aan NederDelta. Dit dossier is straks van belang voor de beheerder. Ook hier is het relevant de informatievoorziening op orde te hebben.

OPLEVERING EN OVERDRACHT

Na afronding van de uitvoeringswerkzaamheden neemt NederDelta de dijk weer in gebruik. Nu de werk-zaamheden zijn afgerond, vindt de overdracht aan de beheerder plaats. De opdrachtnemer maakt een opleverdossier en toont met verificatie [5.3] aan dat invulling is gegeven aan alle eisen uit de vraagspecificatie en valideert bij de opdrachtgever dat gebouwd is wat bedoeld/gewenst is. Het projectteam levert de laatste informatie [11] die de beheerder nodig heeft om de dijk weer in beheer te nemen. Denk daarbij aan as-built-informatie, DTB, GIS-bestanden en bedienings- en onderhouds-voorschriften.
Het nieuwe areaal wordt verwerkt in het beheer- en onderhoudssysteem van de beheerder. Deze beschikt zo over actuele informatie van het areaal. Een goed configuratieproces zorgt dat deze informatie ook nadat het project is afgerond, actueel blijft. Is alles compleet en akkoord bevonden? Dan neemt de beheerder de dijk weer in beheer. Hierbij starten de zorgplichtactiviteiten die deze heeft bij het beheer en onderhoud van de dijk.

De dijkgraaf komt langs om de dijk samen met het projectteam feestelijk te openen. De dijk is versterkt en het achterliggende gebied is weer goed beschermd. Daarbij nodigt de dijk uit om te recreëren en te genieten van het uitzicht, waarbij recreanten hun eventuele auto kwijt kunnen. Op basis van het vernieuwde beheer- en onderhoudsplan start de beheerder weer met het inspecteren van de vernieuwde objecten in zijn areaal.

[1] STRUCTUREREN PROJECT

Dit proces leidt tot het concreet en herleidbaar vastleggen van de inhoudelijke kaders voor het project. Het definieert een aantal activiteiten, die aan rollen worden toebedeeld. Het structureren van het project zorgt ervoor dat de projectopgave en doelstelling van het project expliciet worden gemaakt en dat het beschouwde systeem is gedefinieerd. Ook zijn de uit te voeren werkzaamheden gedefinieerd en georganiseerd. Deze kaders worden bij elke projectfase geactualiseerd De activiteiten uit dit proces hangen samen met wat in de Handreiking Verkenning en Handreiking Planuitwerking van het HWBP wordt beschreven rondom de projectopdracht en de uit te voeren werkzaamheden.

[2] HET KLANTEISENPROCES

Met het klanteisenproces leg je de klantvraag concreet en herleidbaar vast. Zo kan deze goed gecommuniceerd worden tussen het projectteam en de verschillende stakeholders. Een zorgvuldig klant eisen- proces draagt bij aan draagvlak en klant tevredenheid bij de stakeholders en kan een belangrijke basis geven aan de financiering van onder delen. Het proces beslaat op hoofdlijnen het in beeld brengen van de stakeholders en hun belangen en wensen. Nadat deze in kaart zijn gebracht, worden ze gestructureerd aan de hand van objectieve criteria en wordt gekeken of deze in de projectopdracht kunnen worden meegenomen. De klanteisen komen gedurende het proces in verschillende fases en op verschillende abstractieniveaus terug.

[3] HET SPECIFICATIEPROCES

Dit proces richt zich op het tot stand komen van een Systeem- eisen specificatie (SES). Deze stelt de juiste informatie beschikbaar voor het ontwerpen en verifiëren van het systeem. Hiermee zijn de klanteisen systematisch en traceerbaar in het ontwerpproces opgenomen. Het zorgt ervoor dat projectteamleden tot de kern van de projectopgave komen. Daarbij kan het project de vraag op een gestructureerde manier overdragen aan een volgende fase en heeft het ontwerpteam inzicht in de beschikbare oplossingsruimte. Bij de aanbesteding wordt de SES gebruikt als basis voor de Vraagspecificatie Eisen (VSE).

[4] HET ONTWERPPROCES

Het ontwerpproces vertaalt de eisen uit de SES naar een passend ontwerp. Het ontwerpproces leidt tot verschillende mogelijke oplossingen waarbij de meest kansrijke oplossingen verder worden uit-gewerkt. De uitgewerkte kansrijke oplossingen worden met behulp van een Tradeoff Matrix (TOM) onderling expliciet gescoord en vergeleken. Dit leidt tot een goede afweging, die resulteert in een uitgewerkte voorkeursoplossing en een herleidbare keuze. Deze is geverifieerd aan de eisen en uitgewerkt in een ontwerpnota.

[5] HET VERIFICATIEPROCES

Dit proces richt zich op het – met objectief bewijs – bevestigen dat aan de specificaties is voldaan. Dit leidt ertoe dat stakeholders en opdrachtgever inzichtelijk hebben aan welke eisen is voldaan, waardoor expliciet inzicht ontstaat in de geleverde kwaliteit. Ook zorgt het voor het voorkomen van faalkosten, rework en mogelijke onvrede doordat vroegtijdig wordt aangetoond dat voldaan wordt aan de eisen. Daarnaast verhoogt dit proces de noodzaak om de eisen SMART te formuleren en verkleint het de kans dat eisen over het hoofd worden gezien.

[6] HET VALIDATIEPROCES

Het validatieproces richt zich op een verklaring van stakeholders dat het resultaat voldoet aan het beoogd gebruik of de beoogde toepassing. Het vraagt erom om de vertaling van klantbehoeften op verschillende momenten in het proces bij de klant te valideren. Dit gebeurt bijvoorbeeld bij het formuleren van eisen, uitwerken van het ontwerp en bij het gerealiseerde systeem.

[7] BASIS-WBS

Een Work Breakdown Structure (WBS) is een hiërarchische ordening van werkpakketten. Wat de System Breakdown Structure (SBS of objecten boom) is voor het be-schouwde systeem, is de WBS voor de werkzaamheden die nodig zijn voor de ontwikkeling van dat systeem. De Basis-WBS van HEEL zorgt voor een eenduidig en expliciet startpunt. Deze dient altijd projectspecifiek te worden gemaakt, bij voorkeur met het projectteam. Hoewel de HEEL-WBS is toegespitst op dijkversterkings – projecten, kunnen ook andere projecten er gebruik van maken.

HEEL biedt ter ondersteuning:

DE HEEL BASIS-WBS
Deze kan als uitgangspunt worden gebruikt voor een contextspecifieke WBS.
TOELICHTING BASIS-WBS
Een uitleg van de opzet, keuzes en het proces om de Basis-WBS projectspecifiek in te zetten.

[8] BASISSPECIFICATIES

Een basisspecificatie is een gestructureerd overzicht van eisen aan een bepaald objecttype. Je kunt het zien als een bibliotheek van eisen of een eisenset voor dit object, bijvoorbeeld een dijk, weg of sluis. Een basisspecificatie geeft zo een startpunt voor een object of vraagspecificatie binnen het areaal van een opdrachtgever. Het – waar mogelijk – generaliseren van de voorwaarden voor de uitvraag, werkt efficiënt. Als er meer gelijksoortige uitvragen zijn, zorgt het bovendien voor een meer uniforme uitvraag van objecten, wat weer prettig is voor marktpartijen.

HEEL biedt ter ondersteuning:

Een handreiking basisspecificaties – Do’s en dont’s bij het effectief opstellen van een basisspecificatie.
Een BSD (Basisspecificatie Dijk) – Een basis voor een (eisen)specificatie van een (versterkte) dijk; voorstel voor decompositie, structuur en eisen als start voor een projectspecifieke eisenset.
Een ‘kapstok’ voor basisspecificaties – Een decompositie en taxonomie zodat we in een gemeenschappelijke taal de basisspecificaties kunnen ‘ophangen’. Dit overzicht ontsluiten we via de website en vullen we steeds verder met goede voorbeelden van de verschillende basisspecificaties zodat waterschappen deze producten van elkaar kunnen hergebruiken.

[9] HET RISICOMANAGEMENT

Risicomanagement brengt de gebeurtenissen in beeld die het project of de eindgebruiker in gevaar kunnen brengen. Daarbij zorgt het dat de effecten van deze gebeurtenissen zoveel mogelijk beheerst worden. Zo geeft risicomanagement het project en het management inzicht in de risico’s, waardoor hierop gestuurd kan worden. HEEL gaat in het informatie-blad over dit proces vooral in op de relatie tussen het risicomanagementproces en de andere SE- processen. Per HEEL-proces wordt omschreven welk inzicht risico management geeft aan dit proces en omgekeerd. Meer informatie over de RISMAN- methode, de risicomanagement-methode die HWBP-projecten gebruiken, is te vinden op de kennisbank van het HWBP.

[10] HET CONFIGURATIEMANAGEMENT

Dit proces richt zich erop dat alle teamleden over dezelfde, actuele informatie beschikken. De focus ligt op het voorbereiden, verwerken, controleren en auditeren van wijzigingen. Het zorgt voor het beheren en inzicht geven in de impact van wijzigingen aan configuratieitems op de gebaselinede structuren. Het configuratieproces zorgt er zo voor dat er gedegen besluitvorming plaatsvindt op de wijzigingen. Daarbij worden wijzigingen eenduidig en herleidbaar vastgelegd. Zo is terug te vinden wat de achtergrond was voor wijzigingen. De wijzigingen worden gecommuniceerd, zodat alle team leden steeds werken met een actuele set aan informatie.

[11] INFORMATIEMANAGEMENT EN TOOLING

Dit proces zorgt ervoor dat de informatiebehoefte vanuit de verschillende werk- en bedrijfsprocessen wordt vertaald in de juiste informatie voorziening op het project. Daarbij wordt informatie-management op het project gevoed vanuit de beheerfase en levert het project info terug aan de beheerder(s) als input voor de volgende beheerfase. De beschrijving van dit proces richt zich voor HEEL expliciet op het project (en niet op de complete organisatie-inrichting). Het gaat uit van de internationale norm voor de kwaliteitsmanagement- aanpak, met een continu verbeter-proces.