Evaluatie Begraafplaats Hellendoorn

Transcriptie

1 Evaluatie Begraafplaats Hellendoorn Een aanpak op basis van Systems Engineering Definitieve versie 2013 Stichting Pioneering Voor vragen over deze evaluatie kunt u contact opnemen met: Robin de Graaf Universiteit Twente Postbus AE Enschede r.s.degraaf@utwente.nl Evelien Klasens Stichting Pioneering M.H. Tromplaan AB Enschede e.klasens@saxion.nl

2 1 Inleiding Kenmerken project Systems Engineering Eisen analyse Het pve structureren Eisen SMART maken Functionele analyse en allocatie Bepaal de functionaliteit Maak een objectenboom Ontwerpen Verificatie Conclusie en aanbevelingen Het maken van een programma van eisen Het denken vanuit functionaliteit Ontwerpen Verificatie Tot slot

3 1 Inleiding Als een van de eerste gemeenten in Nederland heeft de gemeente Hellendoorn een pilot project uitgevoerd met de methode Systems Engineering (SE). Het betrof de bouw van een sanitair voorziening, een dienstgebouw en een afscheiding op de nieuwe begraafplaats aan de Meester Ponsteenlaan in Nijverdal. Het project is uitgevoerd in een bouwteamverband en de Werkplaats SE, een onderdeel van de Stichting Pioneering, heeft in dit project geadviseerd en ondersteund. Dit document presenteert de geleerde lessen van dit project. In hoofdstuk twee staan de kenmerken van het project. In hoofdstuk drie wordt de methodiek beschreven die het uitgangspunt vormt voor de geleerde lessen. Hoofdstuk 4 tot en met 7 behandelen de geleerde lessen. Het document eindigt met conclusies en aanbevelingen. 3

4 2 Kenmerken project Sinds de 19 e eeuw beschikt de Gemeente Hellendoorn, nabij de grens van de dorpskern Hellendoorn met het dorp Nijverdal over een gemeentelijke Begraafplaats. Rond deze begraafplaats zijn geen gronden meer om deze rustplaats verder uit te breiden. Vanwege het ontbreken van de mogelijkheid tot uitbreiding van deze begraafplaats is er na 2012 geen ruimte meer voor het realiseren van nieuwe graven. Om deze reden heeft de Gemeente Hellendoorn een nieuwe Gemeentelijke Begraafplaats ingericht langs de Meester Ponsteenlaan te Nijverdal. De begraafplaats wordt gefaseerd gerealiseerd. Allereerst is het terrein ingericht en is de infrastructuur aangebracht. In de tweede fase zijn drie voorzieningen gebouwd (opgeleverd in 2012). Het betrof de aanleg van een representatieve entree, de bouw van sanitaire voorzieningen voor bezoekers en de bouw van voorzieningen voor het personeel van de begraafplaats. Deze tweede fase is het onderwerp van deze evaluatie. In de laatste fase (rond 2020) zal nog een wachtruimte in het midden van de begraafplaats worden gebouwd. Opdrachtgever: Gemeente Hellendoorn Bouwer: Bouwbedrijf Schothans uit Nijverdal en later Bouwbedrijf Loohuis B.V. te Putten Architect: Nijhoff Architecten uit Wierden Installateur Elektrische installaties: Heinen B.V. uit Nijverdal Installateur Sanitair: Van Dijk B.V. uit Nijverdal Project bestaat uit de aanleg van o een representatieve entree o de bouw van sanitaire voorzieningen voor bezoekers o de bouw van voorzieningen voor het personeel van de begraafplaats Budget: euro Start van het project: oktober 2011 met uitwerking SE plan Start bouw: maart 2012 Oplevering van het project: september 2012 Ontwerp en bouwmethodiek: Systems Engineering 4

5 3 Systems Engineering In het project is gebruik gemaakt van de methodiek Systems Engineering (SE). Niet alle aspecten zijn 100% volgens de SE theorie toegepast. Er is sprake geweest van een lichte SE variant. In dit hoofdstuk wordt de SE methodiek toegelicht en op basis daarvan worden de geleerde lessen gepresenteerd. SE is een gestructureerde en geïntegreerde methodiek om het ontwikkelproces te stroomlijnen over de hele levenscyclus van een gebouw, van het prille idee tot en met beheer en onderhoud en uiteindelijk de sloop. De methodiek stamt uit de Verenigde Staten en wordt daar veel gebruikt. Sinds de jaren negentig is SE overgewaaid naar Nederland en de grote opdrachtgevers in de infrastructuur (Rijkwaterstaat en ProRail) stellen de methodiek al jaren verplicht voor al hun projecten. Hierdoor heeft de kennisontwikkeling over SE een forse impuls gekregen en beginnen opdrachtgevers in de woningbouw en de utiliteitbouw ook de mogelijkheden van deze methodiek te zien. De bedoeling van SE is dat alle stappen in het ontwikkelingsproces transparant worden gemaakt zodat het gehele proces beter bestuurbaar, beheersbaar en controleerbaar wordt. Die transparantie vraagt om een teaminspanning waarbij gebruik gemaakt wordt van elkaars kennis en kunde. Hierdoor worden risico s blootgelegd en wordt de basis van goede samenwerking vertrouwen gecreëerd. De basis van SE is een iteratief model waarbij in een vaste volgorde naar een ontwerp wordt toegewerkt. Dit model staat hieronder toegelicht en heet het SE procesmodel. Dit model vormt de schakel tussen de procesinput en de procesoutput. Met procesinput wordt bedoeld de kenmerken van het project zoals de problemen die het project moet oplossen en kansen, bedreigingen, doelstellingen, visies, stakeholderbehoeften en ruimtelijke ordeningsdocumenten waarmee rekening moet worden gehouden. De procesoutput is telkens een (deel)ontwerp (bijvoorbeeld SO, VO, DO) dat voldoet aan alle eisen die op dat moment bekend zijn. Het SE procesmodel bevindt zich tussen de procesinput en de procesoutput. De componenten uit dit model zijn gehanteerd als evaluatiecriteria. - Figuur 1 Het SE procesmodel 5

6 De stappen binnen het SE procesmodel zijn (zie Figuur 1): - Analyseren eisen: in deze stap wordt de informatie uit de procesinput stap vertaald in concrete eisen en wordt het programma van eisen gemaakt. Dus uit de grote hoeveelheid informatie volgt een gestructureerd programma van eisen. - Functionele analyse & allocatie: in deze stap wordt op een hoger abstractieniveau naar het project gekeken en staat vooral de functionaliteit centraal. Er wordt bepaald wat het systeem moet doen (functionaliteit) en hoe goed het dat moet doen (prestaties). Belangrijk in deze stap is dat oplossingsvrij wordt gedacht om de ontwerpruimte zo groot mogelijk te houden. - Maken ontwerp: in deze stap worden verschillende ontwerpvarianten bedacht, afgewogen en wordt er een keuze gemaakt voor een ontwerpvariant. Deze ontwerpvariant wordt in vervolgfasen verder uitgewerkt. - Verificatie/validatie: de gekozen ontwerpvariant wordt gecontroleerd of deze daadwerkelijk voldoet aan alle eisen (verificatie). Tevens wordt gecontroleerd of de gekozen variant nog aansluit op de verwachtingen van de stakeholders (validatie). Het SE procesmodel is een iteratief model. Hiermee wordt bedoeld dat er terugkoppelingen tussen stappen plaatsvinden. In het model wordt dat weergegeven met de eisen loop en de ontwerp loop. Bijvoorbeeld, het nadenken over functies leidt tot meer inzicht in eisen (eisenloop) of het maken van het ontwerp roept weer vragen op over functies (ontwerploop). Er is dus een continue wisselwerking tussen de stappen in het model. Het is geen rechtlijnig model van A naar B. De onderdelen van dit model zijn als aandachtspunten gebruikt om van te leren. De onderdelen komen aan de orde in de volgende hoofdstukken. 6

7 4 Eisen analyse 4.1 Het pve structureren Het programma van eisen (pve) is een document waarin omschreven staat aan welke eisen een gebouw moet voldoen. In veel projecten is het pve niet gestructureerd opgezet. Problematisch is: Het abstractieniveau loopt vaak te ver uit elkaar. Sommige eisen zijn heel specifiek, zoals exacte afmetingen van een meterkast of van een aanrecht, terwijl in hetzelfde pve ook abstracte eisen worden genoemd zoals: het gebouw moet mooi zijn, of veilig, of duurzaam. Deze abstracte eisen zijn vervolgens niet uitgewerkt. Herkomst van een eis is niet vastgelegd. In de meeste programma s van eisen is niet te achterhalen waar een eis vandaan komt. Daarmee is onduidelijk waarom een bepaalde eis in het pve genoemd is. De prioriteit van eisen is vaak niet vastgelegd. Soms is een eis een harde eis, maar soms is een eis ook een wens. Dat is in veel pve s niet te achterhalen. Met SE worden de eisen wel op een gestructureerde manier vastgelegd. Bijvoorbeeld in tabelvorm zoals in Tabel 1 is aangegeven, of zelfs met ondersteunende software (BIM). Een SE pve legt een aantal zaken gestructureerd vast: Eisnummer (eis ID): een uniek nummer waarmee de eis wordt aangegeven. Door dit unieke nummer is de eis altijd gemakkelijk terug te vinden. Het eisnummer geeft tevens het abstractieniveau van de eis weer. Dit werkt net zoals een inhoudsopgave in een tekstverwerkingsprogramma. Hoe langer het nummer, hoe gedetailleerder de eis. Door deze werkwijze is de structuur tussen de eisen duidelijk te zien. Er zijn abstracte eisen (bijvoorbeeld eis 1.1.) en daaronder hangen meer gedetailleerde eisen (bijvoorbeeld ). Eisomschrijving: een omschrijving van de eis in woorden zodat iedereen weet waar de eis over gaat. Prioriteit: hierin wordt aangegeven of het een eis, wens of randvoorwaarde betreft. Bron: hier staat waar de eis vandaan komt. Bijvoorbeeld wie de eis naar voren heeft gebracht, of uit welk document de eis komt. 7

8 EIS ID Omschrijving Priorite it Bron 1. Het systeem dient het personeel de mogelijkheid te bieden voor ontspannen en uitrusten 1.1 Het systeem dient zitgelegenheid te bieden voor 6 personen E E Startnotitie Startnotitie Tenminste 6 m2 ruimte E Personeel De zitgelegenheid dient robuust te zijn W Personeel De zitgelegenheid dient makkelijk verplaatsbaar te zijn W Afd. beheer De zitgelegenheid dient comfortabel te zijn W Personeel De zitgelegenheid mag niet duurder zijn dan 600 euro 1.5 De voorziening dient het reinigen van handen te faciliteren E E Projectteam Personeel Tenminste 1 waspunt met warm en koud water W Personeel Waspunt voor warm water W Personeel Waspunt voor koud water W Personeel Tabel 1 Een pve volgens de SE methodiek 8

9 In het project is de SE systematiek aangehouden om eisen te structureren en te ordenen. Een voordeel van deze werkwijze was dat heel goed is nagedacht over de eisen. Hierdoor zijn eisen naar voren gekomen waaraan met een traditionele werkwijze niet gedacht zou zijn. Bijvoorbeeld over de eisen die niet direct met het fysieke bouwwerk te maken hebben maar wel degelijk van belang zijn. Te denken valt aan eisen m.b.t. het verzamelen en afvoeren van afval. Ook kwamen eisen naar voren met betrekking tot onderhoud. Tot slot zijn ook proceseisen vastgelegd. Hierbij valt te denken aan eisen m.b.t. geluidshinder tijdens de bouw. Erg relevant op een begraafplaats. Dus door eisen systematisch op te schrijven worden zaken minder snel vergeten en worden zaken goed vastgelegd. Aanbeveling: blijf eisen gestructureerd opschrijven en vergeet niet de eisen die niet direct met het fysieke bouwwerk te maken hebben zoals gebruikseisen en proceseisen. Het gestructureerd opschrijven van eisen leverde veel papierwerk op. Dit werd door de projectdeelnemers als een nadeel ervaren. Er waren bijvoorbeeld verschillende versies van het pve in omloop bij verschillende partijen. Dit leidde soms tot verwarring. Om dit te voorkomen worden de volgende aanbevelingen gedaan: Maak één persoon verantwoordelijk voor het bijhouden van het pve (een chef-pve). Deze persoon beheert de versies, zorgt ervoor dat eisen SMART worden geformuleerd en zorgt ervoor dat het pve altijd up-to-date is. Maak een duidelijk template/formulier om de eisen in op te schrijven. Maak eventueel gebruik van software (BIM) om het eisen management proces te ondersteunen 9

10 4.2 Eisen SMART maken Met SE worden gedurende de looptijd van het project de eisen continu bijgehouden en steeds verder verfijnd. Dit wordt gedaan in overleg met opdrachtgever, gebruikers, en andere relevante betrokkenen. Dit proces gaat zover door dat alle eisen SMART zijn. SMART staat voor: Specifiek: het is voor iedereen duidelijk wat er bedoeld wordt met een eis; Meetbaar: het is te meten of aan een eis is voldaan of niet; Acceptabel: er is draagvlak voor een eis; Realistisch: de eis is haalbaar; Tijdgebonden: het moet duidelijk zijn wanneer aan de eis moet worden voldaan. Het SMART formuleren voorkomt misinterpretaties. Door een eis SMART te formuleren wordt de eis duidelijk. Stel dat het personeel de volgende eis heeft geformuleerd het personeel wenst een handige berging. Deze eis is nog niet SMART, daarom moet het projectteam doorvragen wat het personeel precies bedoelt met een handige berging. Hieruit kan blijken dat het gaat om het kunnen opslaan van een grasmaaier. De eis een handige berging is dan al meer SMART gemaakt. Bijvoorbeeld: Specifiek: het gaat om een duidelijk object namelijk een grasmaaier Meetbaar: er is een aantal genoemd, namelijk 1 grasmaaier Acceptabel: er is draagvlak voor deze eis onder het personeel en opdrachtgever Realistisch: het betreft hier geen onrealistische of onhaalbare eis Tijdgebonden: er is geen tijd genoemd, dus hier kan nog wat toegevoegd worden. Bijvoorbeeld dat de grasmaaier 24 uur per dag toegankelijk moeten zijn en opgeslagen moeten kunnen worden. In dit project zijn eisen zoveel mogelijk SMART gemaakt. Dit heeft als voordeel gehad dat er meer duidelijkheid is over wat met een eis bedoeld wordt, projectdeelnemers secuurder gaan werken en meer alert zijn op elkaars fouten. Of zoals John Bruggink van installatiebedrijf Heinen B.V. aangeeft: Belangrijke meerwaarde van SE is dat je elkaar scherp houdt. Bijvoorbeeld de eis dat er voldoende licht moet zijn. Wat is dan voldoende licht? Met SE maak je dat met elkaar concreet. Aanbeveling is om eisen zo goed mogelijk SMART te maken. 10

11 5 Functionele analyse en allocatie 5.1 Bepaal de functionaliteit Met SE wordt op een hoger abstractieniveau naar het project gekeken en staat vooral de functionaliteit centraal. Er wordt bepaald wat het systeem moet doen (functionaliteit) en hoe goed het dat moet doen (prestaties). Deze stap heet de functionele analyse en allocatie. Centraal staat niet de vraag hoe het gebouw eruit moet zien, maar wat het moet kunnen. De oplossing wordt dus niet voorgeschreven. Dit wordt ook wel oplossingsvrij denken genoemd. Dit betekent dat er meer mogelijkheden open blijven voor de ontwerper en er dus meer ruimte is om slimme en kosteneffectieve oplossingen te bedenken. Voorbeeld De opdrachtgever formuleert een eis dat er een CV in het gebouw moet. Deze eis is een oplossing (een CV) en laat geen ruimte meer voor alternatieven. De eerste vertaalslag die we gaan maken is om deze oplossing om te zetten in een oplossingsvrije specificatie. Dit doen we door de vraag te stellen wat een CV DOET of moet KUNNEN. Dit proces gaat als volgt: Eis: er moet een CV in het gebouw Vraag: wat DOET een CV? Antwoord: verwarmen van de ruimte Herschrijf de eis er moet een CV in het gebouw naar de ruimte dient verwarmd te kunnen worden Controle: hebben we nu meer oplossingsmogelijkheden? Ja, want verwarmen van de ruimte kan ook met een houtkachel, vloerverwarming, convectorputten of andere manieren. In dit project is ook naar de functionaliteit gekeken. Dit heeft geleid tot een aantal ontwerpverbeteringen. Projectleider John Brand van de gemeente Hellendoorn illustreert: Met SE denk je veel minder vanuit tekeningen, maar meer vanuit de functionaliteit. Bijvoorbeeld wat moet een meterkast doen en wat zou je er nog meer in kwijt kunnen? Door die vraag te stellen ga je goed nadenken over het ontwerp van de meterkast. Probeer vooral vanuit de functionaliteit te denken. Dit kan tot verrassend creatieve, slimme en goedkopere oplossingen leiden. 11

12 5.2 Maak een objectenboom Als de functies bekend zijn wordt iedere functie gekoppeld aan een object. Zo kan bijvoorbeeld de functie verwarmen van de ruimte gekoppeld worden aan het object klimaatinstallatie. Op deze manier worden alle functies aan objecten gekoppeld. Er ontstaat dan een boomstructuur met objecten (objectenboom) waarbij het totale systeem wordt opgedeeld in kleinere en concrete onderdelen. Ieder onderdeel is als het ware een mini-projectje binnen het grotere geheel. Tevens kunnen dan ook de eisen aan de objecten worden gekoppeld. Bijvoorbeeld alle eisen m.b.t. toilet koppelen aan het object toiletruimte. Dit levert structuur en daardoor wordt het makkelijker om voor een onderdeel van het bouwwerk te controleren of er geen eisen vergeten zijn. In het begraafplaatsproject zijn de afzonderlijke bouwwerken niet opgedeeld in objecten zoals toiletruimte, douche, keuken, etc. Gezien de kleinschaligheid werd dat niet nodig geacht. Toch wordt aanbevolen om toch een objectenboom op te stellen omdat daarmee de kans kleiner wordt dat eisen worden vergeten. Aanbeveling is dan ook om het bouwwerk altijd op te delen in concrete objecten (de objectenboom in SE termen) en eisen te koppelen aan deze objecten. 12

13 Op enkele punten was het in dit project niet meer mogelijk om goed vanuit de functionaliteit te kijken omdat bepaalde keuzes al vastlagen. Er was bijvoorbeeld al gekozen voor een hekwerk als toegang voor de begraafplaats. Dit had als gevolg dat er geen andere oplossingen meer mogelijk waren. Echter, als vanuit de functionaliteit geredeneerd zou worden, zouden we wellicht andere afwegingen hebben gemaakt. Het hek heeft onder andere de functie dat het voorkomt dat ongewenste auto s de begraafplaats oprijden. Maar die functie had ook gehonoreerd kunnen worden door een paaltje in de grond te slaan. Deze optie was echter niet meer te overwegen want het was al voorgeschreven dat er een hekwerk moest komen. Aanbeveling is om voorzichtig te zijn met het vastleggen en naar de buitenwereld communiceren van oplossingen. Dit beperkt het denken in functionaliteit en sluit bij voorbaat andere, wellicht betere of goedkopere oplossingen uit. 13

14 6 Ontwerpen In de vorige SE stap is het pve gemaakt en is nagedacht over de functionaliteit van het bouwwerk. Dit geeft echter nog geen oplossingsrichting aan. Omdat het ontwikkelteam dus nog geen idee heeft welke kant het project opgaat, is het nog niet mogelijk om iets te ontwerpen. Eerst moeten belangrijke strategische keuzes gemaakt worden wat er nu precies ontwikkeld moet gaan worden voordat de ontwerper echt aan de slag kan om ontwerpen te maken. Het is dus noodzakelijk om eerst op een hoog abstractieniveau in ieder geval een soort van basisoplossing te bedenken. Als deze basisoplossing duidelijk is, dan pas kan het ontwikkelteam verder gaan met het echte ontwerpen. De mogelijke basisoplossingen worden in SE concepten genoemd. Met een concept wordt bedoeld: - een globale beschrijving van het project in woorden - een zodanige omschrijving van het project zodat alle stakeholders het kunnen begrijpen - een omschrijving van het project waarbij vooral het gebruik van het object centraal staat en niet de uiterlijke verschijningsvorm - een omschrijving van het project vanuit verschillende perspectieven, bijvoorbeeld vanuit het perspectief van de bewoner, of vanuit het perspectief van de beheerder De conceptontwikkelingstap is een cruciale stap in de ontwikkeling van een systeem aangezien de beslissingen die in deze stap worden genomen doorwerken in alle volgende stappen. Het is het eerste moment in de ontwikkeling dat een oplossing richting wordt vastgesteld en daardoor is het ook het eerste moment dat andere oplossingen worden uitgesloten. Het concept is daarmee sterk sturend voor de vervolgfases. Een voordeel van het werken met concepten is dat de concepten een middel zijn om het project uit te leggen en te kunnen bespreken met verschillende stakeholders die niet technisch onderlegd zijn. Het concept biedt dat communicatiemiddel omdat het concept wordt geformuleerd in de woorden van de stakeholders zodat iedere stakeholder begrijpt waar het over gaat. Daarom is het ook cruciaal dat het concept niet in technische termen of tekeningen wordt weergegeven want veel partijen begrijpen die termen niet of kunnen geen tekeningen lezen. Het concept vormt de schakel tussen de eisen en wensen van partijen en de mogelijke technische oplossingen. Een goed concept is daarmee de eerste vertaalslag van stakeholdertaal naar technische taal. 14

15 In dit project is het structuurontwerp vanaf het begin leidend geweest. Dit ontwerp was vanaf het begin het uitgangspunt en werd telkens in het projectteam besproken en aangepast. Gezien de kleinschaligheid van het project en het beperkte budget was dit een logische manier van werken. Het had als voordeel dat er snel en effectief gewerkt kon worden. Nadeel was dat het structuurontwerp niet meer ter discussie is gesteld. Andere oplossingen zijn daardoor bij voorbaat uitgesloten. Op basis van bovenstaande is de aanbeveling om goed stil te staan bij het gekozen concept. Is dit de enige oplossing die mogelijk is, of zijn er alternatieven? Het projectteam moet daarbij vooraf bepalen of het relevant en wenselijk is om alternatieven te bedenken. Soms wegen de kosten van het bedenken en uitwerken van alternatieven niet op tegen de baten. 15

16 7 Verificatie Voor de gekozen ontwerpvariant wordt gecontroleerd of deze daadwerkelijk voldoet aan alle eisen (verificatie). Verificatie komt voor in drie categorieën. De eerste is ontwerpverificatie. Dit is het aantonen met bewijs dat het ontwerp exact in lijn is met het pve. Bewijs daarvoor kan zijn: - Berekening: de ontwerper toont bijvoorbeeld met berekeningen aan dat het gebouw voldoet aan energielabel A. - Expert controle: een expert geeft aan dat bepaalde onderdelen van het ontwerp in lijn zijn met de eisen. Bijvoorbeeld de brandweer kan aangeven dat het ontwerp brandveilig is. - Simulatie: door middel van een computer simulatie kan aangetoond worden dat het ontwerp aan de eisen voldoet. Bijvoorbeeld een zonnestand simulatie. - Expliciete markering op tekening: de ontwerper toont aan met markeringen dat er bijvoorbeeld een douche in het gebouw aanwezig is. De tweede categorie verificaties betreft de uitvoeringsverificatie. Hiermee wordt bedoeld dat tijdens de uitvoering aangetoond wordt dat voldaan wordt aan de eisen. Bewijs hiervoor kan zijn: - Foto van een gereed onderdeel van het bouwwerk. Bijvoorbeeld een foto van het toilet kan gezien worden als bewijs dat er een toilet in het bouwwerk is. - Visuele inspectie: iemand kan visueel inspecteren of voldaan wordt aan de eisen. - Nameten in het werk: hiermee kan worden aangetoond of aan bepaalde afmetingen is voldaan. Bijvoorbeeld of de draaicirkel van het minder validen toilet inderdaad 150 cm is. - Materiaallijsten om aan te tonen dat van bepaald materiaal gebruik is gemaakt. Tot slot kan bij oplevering nog aangetoond worden dat aan alle eisen is voldaan. Bewijs hiervoor kan zijn: - Testen: bijvoorbeeld een test van de verwarming; - Visuele inspectie; - Nameten; - Foto s om een eis mee aan te tonen. Een belangrijk voordeel van het werken met verificatie is dat continu aangetoond wordt dat ook daadwerkelijk conform de eisen wordt gebouwd. Daarmee is het ontwerp en bouwproces beter onder controle. Er zijn geen verrassingen meer achteraf dat aan bepaalde eisen niet is voldaan. 16

17 In het project is de verificatie uitgevoerd met behulp van een verificatieplan. Deze had de vorm van een tabel. Dit verificatieplan is direct gekoppeld aan de eisen. Een voorbeeld van een dergelijk verificatieplan is beschreven in Tabel 2. Het werken met dit plan heeft er toe geleid dat het ontwerp en de uitvoering aansluiten op de eisen. Daarnaast is het verificatieplan van de uitvoering (6 e kolom in de tabel) meteen het keurplan op en levert de 7 e kolom uit het verificatieplan meteen het opleverdocument op. Aanbevolen wordt om deze methode te handhaven. Veranker verificatie in het ontwikkelproces. Dit levert dan automatisch een keurplan en een opleverplan. 17

18 EIS ID Omschrijving Prior iteit Bron Hoe is de eis te bewijzen in het ontwerp? Hoe is de eis te bewijzen tijdens de uitvoering? Hoe is de eis te bewijzen voor de oplevering? Minimaal één goed functionerende douche met warm en koud water E Personeel Doucheruimte markeren op tekening Foto van douche + inspectie van de aansluitingen Douche testen 6.2 Er dient een zitgelegenheid te zijn voor zes personen van minimaal 6 m2 E Personeel Oppervlakteberek ening en markeren op tekening Nameten in het werk Nameten en testen met zes mensen Er dient een koelkast te zijn om kaas en vlees te kunnen koelen tussen 3 en 6 graden Celsius E Personeel Ruimte markeren voor een standaard koelkast Nameten in het werk Visuele inspectie Nameten en testen of er een koelkast kan staan Tabel 2 een voorbeeld van een verificatiematrix 18

19 8 Conclusie en aanbevelingen Het project is niet voor 100% volgens de basisprincipes van SE uitgevoerd. Er was sprake van een lichte SE variant waarbij sommige SE principes meer en andere wat minder zijn toegepast. De volgende punten worden aanbevolen bij nieuwe ontwikkelingen: 8.1 Het maken van een programma van eisen Schrijf eisen gestructureerd op en vergeet niet de eisen die niet direct met het fysieke bouwwerk te maken hebben zoals gebruikseisen en proceseisen. Maak één persoon verantwoordelijk voor het bijhouden van het pve (een chef-pve). Deze persoon beheert de versies, zorgt ervoor dat eisen SMART worden geformuleerd en zorgt ervoor dat het pve altijd up-to-date is. Maak een duidelijk template/formulier om de eisen in op te schrijven. Maak eventueel gebruik van software (BIM) om het eisen management proces te ondersteunen Deel het bouwwerk op in concrete objecten (de objectenboom in SE termen). Maak eisen zo SMART mogelijk. 8.2 Het denken vanuit functionaliteit Probeer vooral vanuit de functionaliteit te denken. Dit kan tot verrassend creatieve, slimme en goedkopere oplossingen leiden. Aanbeveling is dan ook om voorzichtig te zijn met het vastleggen en naar de buitenwereld communiceren van oplossingen in een pril beginstadium van het project. Dit beperkt het denken in functionaliteit en sluit bij voorbaat andere, wellicht betere, oplossingen uit. 8.3 Ontwerpen Er moet goed nagedacht worden over het gekozen concept. Is dit de enige oplossing die mogelijk is, of zijn er alternatieven? Het projectteam moet daarbij vooraf bepalen of het relevant en wenselijk is om alternatieven te bedenken. Soms wegen de kosten van het bedenken en uitwerken van alternatieven niet op tegen de baten. 8.4 Verificatie Veranker verificatie in het ontwikkelproces. Op die manier wordt altijd conform de eisen gebouwd en worden ongewenste verrassingen achteraf voorkomen. Het maken van een verificatieplan levert dan automatisch een keurplan en een opleverplan. 19

20 8.5 Tot slot De deelnemers aan dit project zijn van mening dat het toepassen van SE voor een project van deze kleine omvang wellicht teveel is. Het vergt behoorlijk wat voorbereiding en administratie. De deelnemers zien de meerwaarde van SE dan ook meer voor complexe en grotere projecten. Geert Nijhoff van Nijhoff Architecten: In dit project levert een uur extra denkwerk in de ontwerpfase misschien ook maar een uur winst op in de uitvoering omdat het project zo klein is. Maar als het project groter wordt, kan een uur extra denkwerk misschien wel veel meer opleveren en dan wordt SE pas echt interessant. 20