Van traditioneel ontwerpproces naar Systems Engineering

Transcriptie

1 Van traditioneel ontwerpproces naar Systems Engineering Een onderzoek naar het verminderen van knelpunten in de planstudiefase van infrastructuur projecten doormiddel van verificatiematrices volgens Systems Engineering Dhr. P. Smit Bachelor Scriptie December 2010

2 Colofon Titel Van traditioneel ontwerpproces naar Systems Engineering Een onderzoek naar het verminderen van knelpunten in de planstudiefase van infrastructuur projecten doormiddel van verificatiematrices volgens Systems Engineering Plaats en datum Enschede, 9 december 2010 Stageperiode mei - november 2010 Omvang 33 pagina s (exclusief bijlagen) Bijlagen 5 Status Definitief Auteur P. Smit Studentnummer adres pietersmit333@gmail.com Begeleiders ing. J.M. Kruitwagen Provincie Overijssel ir. A.T.A.P. Adriaansen Tauw Eerste corrector Tweede corrector Organisaties Dr. ir. R.S. de Graaf Universiteit Twente Drs. J.L.M. Schretlen Universiteit Twente Provincie Overijssel Afdeling Wegen en Kanalen Projecten (WKP) Luttenbergstraat 2 Postbus EE Zwolle Tauw Sector Civiel Handelskade 11 Postbus AC Deventer Universiteit Twente Faculteit: Construerende Technische Wetenschappen Opleiding: Civiele Techniek Postbus AE Enschede 2

3 Samenvatting Het doel van dit onderzoek was om te inventariseren wat de belangrijkste knelpunten waren binnen het proces van de traditionele planstudiefase van projecten zoals de N34 en of een verbetervoorstel op basis van Systems Engineering deze knelpunten kon verminderen. De N34 is een provinciale weg tussen Coevorden en Hardenberg die opnieuw zal worden ingericht als een zogenaamde stroomweg. De provincie Overijssel is de opdrachtgever van het project en een combinatie van ingenieursbureaus Tauw en Goudappel Coffeng de opdrachtnemers. Het onderzoek is bij beide organisaties uitgevoerd en bestond uit een inventarisatieonderdeel en een implementatieonderdeel. In het inventarisatieonderdeel werden interviews en enquêtes afgenomen met specialisten en projectleiders van de provincie Overijssel en de combinatie van Tauw/Goudappel Coffeng. Uit dit onderdeel kwamen de volgende vier hoofdknelpunten naar voren: 1. Raakvlakken tussen specialisten: de planstudiefase vergde intensieve samenwerking tussen verschillende disciplines, maar de specialisten werkten geregeld langs elkaar heen. 2. Structurering van informatie: informatie over het project werd onvoldoende gestructureerd, waardoor belangrijke informatie soms maar deels werd meegenomen bij beslissingen. 3. Interpretatie van de vraagspecificatie: door het impliciete karakter van de vraagspecificatie was het moeilijk voor opdrachtgever en opdrachtnemer om af te stemmen wat men werkelijk van elkaar verwachtte, dat leidde ondermeer tot onnodige ontwerpherzieningen. 4. Moeilijke herleidbaarheid van eisen: de eisen die werden gesteld aan een te ontwerpen weg of een te ontwikkelen rapportage waren veelal moeilijk herleidbaar. De methode Systems Engineering was gekozen om de ondervonden knelpunten te verminderen. Systems Engineering is een specificatie- en ontwerpmethode die sinds de jaren negentig haar opmars maakt in de Nederlandse bouw- en infrastructuurwereld. Systems Engineering speelt in op het beheersbaar, gestructureerd en transparant maken van complexe projecten. De ondervonden knelpunten uit het inventarisatieonderzoek hadden voornamelijk betrekking op het structureren en beheren van informatie over het project en tussen de disciplines. Binnen Systems Engineering wordt het structureren en beheren van informatie vormgegeven door verificatiematrices gevuld met eisen die samen de oplossingsruimte bepalen en afspraken vastleggen. Als verbetervoorstel is daarom gekozen voor deze oplossing. Binnen het implementatieonderdeel is er eerst een format voor een verificatiematrix ontwikkeld en onderbouwd op basis van de theorie van Systems Engineering. Daarna is het verbetervoorstel toegepast voor een aspect van het project N34. De uitgangspunten voor het implementatieonderdeel waren het vinden van een goede balans tussen de theorie van Systems Engineering en de functionele toepasbaarheid voor in de praktijk. De resultaten van het implementatieonderzoek waren dat de toepassing van het verbetervoorstel de ondervonden knelpunten in het proces van de planstudiefase van de N34 grotendeels konden verminderen. De projectinformatie was beter gestructureerd en de behoefte van belanghebbenden kon explicieter worden overgebracht. Daarnaast waren de eisen (beter) herleidbaar naar bronnen en bovenliggende en onderliggende eisen én specialisten konden elkaar beter onderling een expliciete deelopdracht meegeven. Door de vermindering van de hoofdknelpunten wordt verwacht dat het proces van de planstudiefase in de toekomst minder te maken zal hebben met o.a. vertragingen en budgetoverschrijdingen. Dat de knelpunten niet in het geheel werden verminderd, werd veroorzaakt door afwegingen die zijn gedaan aan het verbetervoorstel om de balans met de praktische toepasbaarheid te behouden. De afwegingen zijn mogelijk van tijdelijke aard. De aanbevelingen voor de provincie Overijssel en Tauw/Goudappel Coffeng waren vooral gericht op de toekomst. Daarbij was aandacht voor het ontwikkelen van één technische taal voor Systems Engineering, waarbij kennis en ervaring uitwisselbaar en toepasbaar zal zijn voor toekomstige projecten. 3

4 Voorwoord Na een interessant project op de universiteit waarbij gebruik werd gemaakt van de Systems Engineering methodiek, sprak een bachelor opdracht rondom dit onderwerp mij erg aan. Mede door deze interesse ben ik uiteindelijk terecht gekomen bij de provincie Overijssel en Tauw, waar ik een onderzoek heb mogen uitvoeren over de implementatie van Systems Engineering rondom het project van de herinrichting van de N34. Het komt niet vaak voor dat bij twee verschillende organisaties een bachelor opdracht wordt uitgevoerd. Dit maakte de stage voor mij extra interessant, maar soms ook complex. Deze scriptie is de uitkomst van vijf maanden hard werken. Het was een interessante tijd waarin ik veel heb geleerd en veel ervaring heb opgedaan. Er zaten af en toe wat hobbels op de weg, maar uiteindelijk zijn deze overwonnen en presenteer ik met trots mijn scriptie. Graag wil ik enkele mensen bedanken die belangrijk waren tijdens de uitvoer van de opdracht. Allereerst wil ik Joost Kruitwagen van de provincie Overijssel en Rogier Adriaansen van Tauw bedanken voor hun begeleiding en de vele interessante gesprekken die we onderling hebben gehad. Zij hebben mij verder geholpen op momenten dat ik even vastzat en zij hebben mij inzicht gegeven om dingen van verschillende kanten te belichten. Daarnaast hebben zij mij een kijkje gegeven in de wereld van de civiele techniek en hebben mij daardoor ook op een breder terrein kennis bijgebracht. Daarnaast wil ik projectleider Maurice Lunenborg van de N34 bedanken voor tevens de vele interessante gesprekken en zijn hulp bij het onderzoek. Ook wil ik mijn voormalige collega s van de provincie Overijssel en Tauw bedanken voor hun gezelligheid, de koffieronden en de medewerking aan het onderzoek. Vanuit de universiteit wil ik dhr. De Graaf bedanken voor zijn begeleiding, zijn advies en goede terugkoppeling. Tot slot wil ik bepaalde mensen in mijn persoonlijke omgeving bedanken, namelijk mijn ouders en vrienden voor hun interesse en mijn vriendin Roos voor haar steun en geduld. 4

5 Inhoudsopgave 1. Inleiding Aanleiding Doelstelling Vraagstelling Leeswijzer Achtergrond Informatie Planstudiefase Systems Engineering Deelconclusie en relevantie voor onderzoek Inventarisatie traditionele planstudiefase Methode Resultaten inventarisatieronden Typologieën Deelconclusie Theorie verbetervoorstel Methode Omschrijving verbetervoorstel Theoretische onderbouwing Deelconclusie Toepassing verbetervoorstel Methode Kernpunten voor het opstellen van een specificatie Verantwoording werkwijze Deelconclusie Aanbevelingen voor organisaties Standaardisatie van definities en werkwijzen Overnemen van verbetervoorstel Informatiepunten, kennisverspreiding en draagvlak Deelconclusie Conclusies Referenties

6 1. Inleiding 1.1. Aanleiding Overheden zoals Rijkswaterstaat meten zich de laatste tien jaar een andere rol als opdrachtgever aan. Ze nemen meer afstand van het te ontwikkelen product en verwachten een actievere rol van de opdrachtnemer. Daarnaast worden de infrastructuur- en bouwprojecten complexer, doordat steeds meer aspecten bij de projecten worden betrokken en er een toename is van eisen vanuit belanghebbenden. De ontwikkelingen hebben tot gevolg dat grote infrastructuur- en bouwprojecten moeilijker beheersbaar worden voor zowel opdrachtgever als opdrachtnemer. Dit heeft weer invloed op de kwaliteit van het te ontwikkelen product en het proces daarvan. Mede door deze ontwikkelingen lopen projecten vertragingen op, blijven niet binnen het vastgestelde budget of sluiten niet aan op het verwachtingspatroon van de belanghebbenden. Dit vormt een belangrijke problematiek binnen de Nederlandse bouwwereld. De ontwikkelingen van een terugtredende overheid en complexer wordende projecten zijn voornamelijk externe invloeden op het proces van projecten. Het is echter onduidelijk welke knelpunten binnen het proces van de projecten de problemen van vertragingen, kostenoverschrijdingen en kwaliteitseisen veroorzaken. Het project omvorming N34 is een voorbeeld van een complex en multidisciplinair project. De N34 is een provinciale weg tussen Coevorden en Hardenberg en vervult een belangrijke functie voor de ontsluiting van het noordoosten van de provincie Overijssel en het zuidoosten van de provincie Drenthe. De provincie Overijssel wil de N34 inrichten als een stroomweg, waar veilig met 100 km per uur gereden kan worden. Bij een zogenaamde stroomweg kan het autoverkeer goed doorrijden zonder dat er vertragingen optreden door bijvoorbeeld de aanwezigheid van uitritten of rotondes en verkeerslichten. In de huidige situatie zijn er veel gelijkvloerse kruisingen (verkeerslichten) en uitritten van woningen aanwezig. Het project bevindt zich momenteel in de planstudiefase, wat onderdeel is van het MIT-traject voor grote infrastructuurprojecten. Provincie Overijssel is de opdrachtgever van het project en een combinatie van ingenieursbureaus Tauw en Goudappel Coffeng (hierna te benoemen: de combinatie) de opdrachtnemer. Zowel de provincie Overijssel als de combinatie hebben ervaring met vergelijkbare infrastructuurprojecten en ondervinden de genoemde problemen van vertragingen, kostenoverschrijdingen en discussies over kwaliteit. Het project van de N34 is daarmee een duidelijke illustratie van de maatschappelijke ontwikkelingen in Nederland van het laatste decennia. Provincie Overijssel en de combinatie geven aan dat er knelpunten zijn binnen het proces van de planstudiefase waardoor projecten worden geconfronteerd met de genoemde problemen, maar wat deze knelpunten zijn is nog onduidelijk. Om de beheersbaarheid van het project te vergroten en de problemen te verminderen hebben de provincie Overijssel en de combinatie gekozen voor de methode Systems Engineering. Systems Engineering is een gestructureerde specificatie- en ontwerpmethode die sinds de jaren negentig professioneel wordt toegepast in Nederland. Dit onderzoek is er op gericht om te onderzoeken wat de knelpunten zijn waar de planstudiefase van projecten zoals de N34 mee worden geconfronteerd en of de implementatie van Systems Engineering deze knelpunten kan verminderen Doelstelling Het doel van dit onderzoek is om te inventariseren wat de belangrijkste knelpunten zijn binnen het proces van planstudiefase van projecten zoals de N34 en of een verbetervoorstel op basis van Systems Engineering de belangrijkste knelpunten kan verminderen. 6

7 1.3. Vraagstelling Hoofdvraag: Wat zijn de belangrijkste knelpunten binnen het proces van de planstudiefase van projecten vergelijkbaar met de N34 en hoe kan de implementatie van Systems Engineering deze knelpunten verminderen? Deelvragen: 1. Wat zijn de belangrijkste kenmerken van Systems Engineering, hoe werkt de methode en welke rol speelt Systems Engineering binnen Nederland? 2. Wat zijn de belangrijkste knelpunten binnen het proces van de planstudiefase van projecten vergelijkbaar met de N34 en wat zijn de oorzaken en gevolgen hiervan? 3. Hoe zou een verbetervoorstel op basis van de theorie van Systems Engineering kunnen worden vormgegeven om de belangrijkste knelpunten in de planstudiefase te verminderen? 4. Hoe zou het verbetervoorstel kunnen worden toegepast voor het project N34 en welke afwegingen en problemen komen daarbij kijken? 5. Kan de toepassing van het verbetervoorstel de belangrijkste knelpunten in de planstudiefase verminderen? 6. Welke aanpassingen dienen te worden doorgevoerd bij de provincie Overijssel en de combinatie om de implementatie haalbaar te maken? 1.4. Leeswijzer In het hoofdstuk Achtergrond Informatie worden de termen planstudiefase en Systems Engineering uitgebreid toegelicht aan de hand van literatuur en informatie van organisaties zoals Rijkswaterstaat. Het hoofdstuk vormt een theoretische basis voor zowel het inventarisatieonderdeel als het implementatieonderdeel. Het hoofdstuk zal worden afgesloten met een beantwoording van deelvraag 1 en een opsomming van de onderdelen die relevant zijn voor het onderzoek. In het hoofdstuk Inventarisatie traditionele planstudiefase, wordt het inventarisatieonderdeel beschreven. In dit hoofdstuk worden de methoden van onderzoek, de gevonden resultaten en de hoofdknelpunten van de traditionele planstudiefase beschreven. De projecten N34 en N340 zullen als casestudy dienen. In de deelconclusie zal antwoord worden gegeven op deelvraag 2. In het hoofdstuk Theorie verbetervoorstel wordt het verbetervoorstel eerst beschreven en vervolgens vormgeven aan de hand van de theorie van Systems Engineering. Gemaakte afwegingen worden hierin toegelicht. In de deelconclusie zal antwoord worden gegeven op deelvraag 3. In het hoofdstuk Toepassing verbetervoorstel wordt beschreven hoe de toepassing van het verbetervoorstel in de praktijk vorm is gegeven en welke afwegingen daar opnieuw bij kwamen kijken. Tot slot wordt in de deelconclusie antwoord gegeven op de deelvragen 4 en 5. In het hoofdstuk Aanbevelingen wordt toegelicht welke aanpassingen binnen de organisaties van Provincie Overijssel en de combinatie nodig zijn om de implementatie van Systems Engineering mogelijk te laten maken. In de deelconclusie wordt antwoord gegeven op deelvraag 6. In de Conclusie worden de resultaten van het onderzoek bijeen gebracht en een eindoordeel gegeven over de mogelijkheid om de belangrijkste knelpunten in de planstudiefase van projecten zoals de N34 te verminderen doormiddel van de implementatie van Systems Engineering. 7

8 2. Achtergrond Informatie In dit hoofdstuk worden de termen planstudiefase en Systems Engineering toegelicht aan de hand van literatuur en informatie van organisaties zoals Rijkswaterstaat en ProRail. Het doel van dit hoofdstuk is om uiteen te zetten wat de belangrijkste kenmerken van Systems Engineering zijn, hoe de methode werkt en welke rol Systems Engineering speelt binnen Nederland. Daarnaast heeft dit hoofdstuk tot doel een theoretische basis te vormen voor het inventarisatieonderdeel en het implementatieonderdeel van het onderzoek Planstudiefase De planstudiefase maakt onderdeel uit van het Meerjarenprogramma Infrastructuur en Transport, de zogenaamde MIT-procedure van het ministerie van Verkeer en Waterstaat. De MIT-procedure is een standaard voor omvangrijke infrastructuurprojecten boven een bepaald aanbestedingsbedrag. De MIT-procedure onderscheidt een verkenningsfase, planstudiefase en realisatiefase en binnen deze fasen zes beslismomenten. De procedure geeft per fase en beslismoment aan wat de rol en verantwoordelijkheden zijn van de betrokken partijen, welke wettelijke regels van toepassing zijn en welke informatie nodig is om een beslissing te kunnen nemen (Rijksoverheid, 2010). Planstudiefase De planstudiefase van de MIT-procedure bestaat uit twee delen: (1) de planvorming waarbij een oplossing wordt gezocht voor het verkeers- en vervoersprobleem en (2) de voorbereiding voor de uitvoering (Van Netten, 2005). Binnen de planvorming worden haalbare oplossingsvarianten gegenereerd, afgewogen en de gekozen variant verder uitgewerkt. Tijdens dit proces volgen een structuurontwerp, voorlopig ontwerp en definitief ontwerp elkaar op, waarbij de oplossing steeds gedetailleerder wordt uitgewerkt. Het planvormingsproces heeft een sterk multidisciplinair karakter. Binnen het proces wordt nadrukkelijk gekeken naar zaken als inpassing, milieu, ruimtegebruik, verkeersveiligheid en economische effecten (Rijksoverheid, 2010). m.e.r. procedure Een milieueffectrapportage (m.e.r.) kan een onderdeel vormen van de planstudiefase. De m.e.r. is een procedure die tot doel heeft de milieugevolgen van plannen en projecten in kaart brengt en daarmee tracht het milieubelang volwaardig mee te laten wegen bij besluitvorming. De m.e.r. procedure wordt omschreven in de Wet Milieu Beheer. De procedure is verplicht voor plannen met een grote veronderstelde impact op het milieu of de omgeving. Europese wetgeving bepaalt welke projecten daarvoor in aanmerking komen. Het milieueffectrapport (MER) beschrijft de resultaten van de uitgevoerde onderzoeken voor de MER. In de Wet Milieu Beheer staan de eisen vermeld ten aanzien van de inhoudelijke eisen voor de MER en de eisen voor de te volgen procedure (Rijksoverheid, 2010) Systems Engineering In deze paragraaf wordt Systems Engineering beschreven op basis van beschikbare literatuur. Daarbij wordt ingegaan op het ontstaan van de methode, het proces, de belangrijkste kenmerken en de meerwaarde. Vervolgens wordt Systems Engineering beschouwd in de context van organisaties zoals Rijkswaterstaat en ProRail. Rijkswaterstaat en ProRail hebben deels een eigen definitie en interpretatie aan de methode Systems Engineering gegeven, die meer is toegespitst op de werkzaamheden van de organisaties. De paragraaf wordt afgesloten met de beantwoording van de eerste deelvraag. 8

9 Het ontstaan van Systems Engineering De basis voor Systems Engineering ligt in de algemene systeemtheorie die is ontwikkeld halverwege de twintigste eeuw door Von Bertalanffy (Strijbos, 1988). Von Bertalanffy omschreef de algemene systeemtheorie als het wetenschappelijk onderzoek in gehelen en totaliteit. De algemene systeemtheorie was een nieuwe benadering in het streven naar een eenheidswetenschap, waarbij de wetenschap het systeem voorstelt dat als een geheel of totaal moest worden bezien. Vanuit de algemene systeemtheorie is het systeemdenken ontwikkeld. Systeemdenken kan worden omschreven als een doorontwikkeling van de algemene systeemtheorie (Strijbos, 1988). Van Netten (2005) omschrijft systeemdenken als een methode waarbij vanuit een holistische visie naar complexe problemen en mogelijke oplossingen wordt gekeken. Systems Engineering is een van de disciplines waarbinnen het systeemdenken wordt toegepast. Door de jaren heen is Systems Engineering verder ontwikkeld door en voor ingenieurs (Van Netten, 2005). Systems Engineering als methode is voor het eerst toegepast in de telefoniesector en daarna doorontwikkeld en toegepast in de ruimtevaart, vliegtuigbouw en de Amerikaanse defensie-industrie (Department of Defence, 2001). In de jaren negentig is Systems Engineering vanuit de Verenigde Staten overgewaaid naar Nederland. Binnen Nederland zijn Rijkswaterstaat en ProRail de grote opdrachtgevers die werken met de methode (Van Netten, 2005) Omschrijving Systems Engineering Systems Engineering is de discipline van het ontwikkelen van producten en processen, waarbij alles wordt bekeken vanuit het perspectief van het totaalsysteem en het belang van alle aspecten zorgvuldig wordt afgewogen (INCOSE, 2006). Deze definitie voor Systems Engineering is afkomstig van het International Council on Systems Engineering (INCOSE). INCOSE is een toonaangevende organisatie op het gebied van kennisvorming over Systems Engineering (Van Netten, 2005). INCOSE (2006) benadert Systems Engineering als een discipline. Systems Engineering is niet alleen een stappenplan, maar een denkwijze (Van Netten, 2005). Met het totaalsysteem perspectief bedoeld INCOSE dat het te ontwikkelen product of proces wordt bezien als een groot systeem en kan worden onderverdeeld in elementen die onderling interactie ondervinden. Deze omschrijving komt overeen met de gedachte van de algemene systeemtheorie en het systeemdenken. Verder beschrijft INCOSE (2006) dat Systems Engineering zorgvuldig een afweging maakt tussen het belang van diverse aspecten. Deze aspecten kunnen de behoefte van de opdrachtgever of andere belanghebbenden zijn of de beperkingen ten aanzien van wetgeving of techniek (Ter Huerne & Veenvliet, 2007). Systems Engineering concentreert zich op het vroegtijdig specificeren van een behoefte en het helder krijgen van het probleem (Bahill & Dean, 2005). Het proces van Systems Engineering ontwikkelt een pakket aan klantwensen en eisen dat vervolgens op een transparante en navolgbare wijze wordt omgezet in (systeem) producten en procesbeschrijvingen (Van Netten, 2005). Systems Engineering is voornamelijk geschikt voor complexe, unieke en multidisciplinaire projecten zoals grote infrastructuur- en bouwprojecten (Martin, 1997) Het proces van Systems Engineering Bahill & Dean (2005) onderscheiden vijf belangrijke processtappen binnen de methode Systems Engineering: (1) het expliciet specificeren van eisen waaraan een te ontwikkelen product of proces dient te voldoen, (2) het op een gestructureerde wijze ontwerpen van een passende oplossing aan de hand van deze opgestelde specificatie, (3) het realiseren van deze oplossing, (4) het verifiëren en 9

10 valideren en (5) het onderhouden van de gerealiseerde oplossing. De Systems Engineering methode werkt van abstract naar concreet, waarin de genoemde processtappen iteratief worden toegepast in verschillende ontwikkelfasen (Bahill & Dean, 2005). Een andere veelvoorkomende procesbeschrijving van Systems Engineering komt van Martin (1997) en gaat uit van de volgende drie fundamentele processtappen binnen Systems Engineering: (1) eisenanalyse, (2) functionele analyse en allocatie en (3) ontwerp synthese. Bahill & Dean (2005) beschrijven met hun vijf processtappen de gehele levenscyclus van Systems Engineering. Martin (1997) richt zich met zijn drie processtappen voornamelijk op het specificatie- en ontwerpproces en de gelaagdheid daarbinnen, waarbij het te ontwikkelen systeem wordt ontrafeld in subsystemen en elementen. Om een volledig beeld van werking van de methode Systems Engineering te krijgen, zal eerst worden ingegaan op het brengen van gelaagdheid binnen het systeem, waarbij de termen decompositie en integratie worden geïntroduceerd. Vervolgens zal het proces van Bahill & Dean (2005) worden beschreven, waarbij voornamelijk zal worden ingegaan op de processen van specificatie, ontwerp en verificatie en validatie. Decompositie Decompositie is het opdelen van het project in overzichtelijke onderdelen of niveaus, met als doel de complexiteit van het project terug te brengen en het project beheersbaar te houden (Van Netten, 2005). De onderdelen of niveaus worden gezien als subsystemen binnen het hoofdsysteem van het totale project. Deze gedachte sluit aan op het systeemdenken. Decompositie kan ondermeer worden vormgegeven in een niveauopdeling, geografische opdeling, activiteitenopdeling en functionele opdeling (Van Netten, 2005). Het opnieuw verbinden van afzonderlijke onderdelen of elementen tot een nieuw geheel wordt binnen Systems Engineering gedefinieerd als integratie of synthese (Martin, 1997). Systems Engineering hecht veel aandacht aan de inhoudelijke verbindingen tussen de subsystemen of onderdelen van het totaalsysteem, als gevolg van decompositie. Deze verbindingen worden omschreven als interne raakvlakken. Systems Engineering kent ook de term externe raakvlakken en deze worden beschreven als inhoudelijke verbanden tussen het systeem en zijn omgeving (INCOSE, 2006). De raakvlakken worden gedetailleerd omschreven en vormen een belangrijk onderdeel van de specificatie. Raakvlakken tussen subsystemen, of raakvlakken tussen een totaalsysteem en zijn omgeving, zijn vaak de oorzaken van problemen. Het ene systeem dient aan te sluiten op het andere, maar de systemen worden apart van elkaar ontwikkeld en dat vormt een risico wanneer de systemen in elkaar worden gepast (Van Netten, 2005). Specificatie en ontwerp Bahill en Dean (2005) maken onderscheid tussen het eerst specificeren van de eisen waar een te ontwikkelen product of proces aan dient te voldoen (processtap 1) en het vervolgens ontwerpen van een passende oplossing aan de hand van de specificatie (processtap 2). Deze splitsing tussen specificatie en ontwerp is een belangrijk kenmerk van Systems Engineering (Van Netten, 2005). Specificeren wordt gedefinieerd als het formuleren en vervolgens geordend vastleggen van eisen en functies die gezamenlijk bepalen waar een te ontwikkelen product of proces (of onderdeel daarvan) aan dient te voldoen. Ontwerpen wordt beschouwd als het proces om tot een optimale oplossing te komen binnen de kaders van de specificatie (Van Netten, 2007). In de specificatiefase zijn de wensen van de klant en andere belanghebbenden uitgangspunt (Bahill & Dean, 2005). Volgens Van Netten (2005) zijn specificeren en ontwerpen parallel lopende processen waarbij steeds voor een niveau of onderdeel van het te ontwikkelen product of proces wordt gespecificeerd en vervolgens eisen gestuurd wordt ontworpen. Bij een gedetailleerder of onderliggend niveau van het te ontwikkelen product of proces vindt opnieuw specificatie en ontwerp plaats. Zo ontstaat er een proces dat leidt tot decompositie van het systeem en tot een volledige specificatie en ontwerp van het te ontwikkelen product of proces. 10

11 Volgens Van Netten (2005) dwingt het eerst specificeren en vervolgens ontwerpen de ontwerpers om beter na te denken over de eisen waar een te ontwikkelen product of proces aan dient te voldoen. De splitsing schept bovendien een kader waarbinnen ruimte is voor innovatie en het vaak efficiënter en doeltreffender vormgeven van een oplossing (Ter Huerne & Veenvliet, 2005). Verificatie en validatie De splitsing tussen het vooraf specificeren en vervolgens ontwerpen, realiseren of beheren van een product of proces biedt de mogelijkheid tot controle. Systems Engineering kent twee methoden van controle: verificatie en validatie. Verificatie is het proces waarbij wordt vastgesteld of de uitwerkte oplossingsvariant of gerealiseerde product of proces voldoet aan de vooraf gespecificeerde eisen. Validatie is het proces waarbij wordt vastgesteld of de uitwerkte oplossingsvariant of gerealiseerde product of proces voldoet aan de behoefte van de klant (Van Netten, 2005). Validatie gebeurt in navolging van verificatie en is een subjectievere toets. Binnen de verschillende ontwikkelfasen van Systems Engineering vindt continue controle plaats. Met continue controle wordt bedoeld dat veelvuldig en op verschillende momenten binnen het procesverloop van Systems Engineering wordt gecontroleerd of het ontwikkelde product of proces in overeenstemming is met de vooraf opgestelde specificatie. In de toepassing van Systems Engineering kunnen de eisen van de specificatie, de gebruikte verificatiemethode en het resultaat daarvan worden omschreven in zogenaamde verificatiematrices (Van Netten, 2005). Verificatie en validatie worden binnen de literatuur ook in verband gebracht met het decomponeren en integreren (synthese) van een systeem (INCOSE, 2006). Tijdens het decomponeren spelen verificatie en validatie een rol bij het controleren of de specificatie van een bepaald niveau in lijn is met de specificatie van een onderliggend of bovenliggend niveau (INCOSE, 2006). Tijdens de integratiefase spelen verificatie en validatie een rol bij het samenvoegen van componenten en subsystemen. Deze wijze van controle wordt beschreven als verticale controle, omdat de gelaagdheid binnen het ontwikkelproces wordt gecontroleerd. De beschrijvingen van verificatie en validatie in de voorgaande alinea wordt beschreven als horizontale controle. Internationaal is er geen eenduidig standpunt over de termen verificatie en validatie (Van Netten, 2005). Voor dit onderzoek worden de definities van Van Netten (2005) aangenomen omdat deze overeenkomen met de veelgebruikte definitie binnen Nederland van Rijkswaterstaat. De levenscyclus als uitgangspunt De levensloop van projecten als uitgangspunt nemen is een ander belangrijk kenmerk van Systems Engineering (Van Netten, 2005). In de specificatiefase worden daarom eisen en functies meegenomen voor het kunnen onderhouden van het product gedurende de gehele levenscyclus en de sloop. De term levenscyclus wordt ook gebruikt als een aanduiding voor de verschillede fases waarin het te ontwikkelen systeem zich bevindt. De output van elke levenscyclusfase is de input voor een opeenvolgende levenscyclusfase (Martin, 1997) Systems Engineering werkwijze Systems Engineering wordt gekenmerkt door expliciet formuleren en een gestructureerde werkwijze (INCOSE, 2004). Expliciet formuleren wordt omschreven als het zodanig formuleren dat niets kan worden geïmpliceerd of slechts gesuggereerd blijft van wat wordt bedoeld (Van Dale, 2004). Controle in de vorm van verificatie en validatie kan niet goed plaatsvinden wanneer eisen niet expliciet zijn omschreven, omdat een eis dan op meerdere manieren te interpreteren valt (Van Netten, 2005). Daarom speelt de expliciete werkwijze voornamelijk binnen de specificatiefase een belangrijke rol, zodat de vervolgfases van ontwerp en realisatie correct en toetsbaar uitgevoerd kunnen worden. De gestructureerde werkwijze binnen Systems Engineering wordt vorm gegeven door een werkwijze waarbij afwegingen, keuzes, definities, wijzigingen en afspraken worden vastgelegd zodat er zo min 11

12 mogelijk onzekerheden en onduidelijkheden optreden. Het gestructureerd werken is een vorm van informatiebeheersing en vindt gedurende het gehele proces van Systems Engineering plaats (Martin, 1997) Meerwaarde van Systems Engineering Diverse onderdelen van Systems Engineering zijn niet nieuw en draaien al een langere tijd mee in ondermeer de civiele wereld (Van Netten, 2005). Een functionele analyse of decompositie zijn daar voorbeelden van. Het nieuwe van Systems Engineering is dat al deze onderdelen samen worden gebracht onder één procesmodel en dat daarmee een methode ontstaat dat complexe projecten beheersbaar kan houden van begin tot afronding van het project. In de literatuur wordt verder ingegaan op de meerwaarde van Systems Engineering: Honour (2004) geeft aan dat Systems Engineering leidt tot een verzwaring van de eerste fase van het ontwikkelproces van een project, maar dat de methode over de gehele projectcyclus leidt tot een vermindering van: (1) de totaalinspanning, (2) de totale ontwikkelkosten en (3) het aantal ontwerpwijzigingen gedurende het proces. Martin (1997) voegt hieraan toe dat de toepassing van Systems Engineering leidt tot: (4) een betere aansluiting op de eisen van de opdrachtgever en (5) het opleveren van een beter kwalitatief product Systems Engineering in Nederland Rijkswaterstaat en ProRail hebben deels een eigen definitie en interpretatie aan de methode Systems Engineering gegeven, die meer is toegespitst op de werkzaamheden van de eigen organisaties. De organisaties beschrijven Systems Engineering in essentie als een gestructureerde specificatie- en ontwerpmethode. Systems Engineering heeft daarbij tot doel structuur te geven aan en inzicht te verschaffen in de complexiteit van het te realiseren object. Met behulp van Systems Engineering kunnen risico s die ontstaan door verkeerde of niet volledige informatie en uitgangspunten worden beheerst. Belangrijk is dat het systeem als totaal wordt beschouwd, over de gehele levenscyclus, inclusief de samenhang met zijn omgeving. Systems Engineering biedt een geïntegreerde en gestructureerde set methodieken om projecten succesvol te verwezenlijken en te beheren. Voor Rijkswaterstaat en ProRail is Systems Engineering een methode om enerzijds een groot deel van het ontwikkelproces uit te besteden aan de markt en anderzijds toch beheersbaarheid te houden op de gewenste uitkomt. Dit is voornamelijk mogelijk door de top-down benadering van Systems Engineering in combinatie met de expliciete controle bij de processen van decompositie en integratie. De opdrachtgever formuleert een oplossingskader doormiddel van topfuncties en topeisen en de opdrachtnemer specificeert deze gedetailleerder en ontwikkeld een (eisen gestuurde) oplossing. De opdrachtnemer past daarbij continue controle toe, zowel verticaal als horizontaal. Daarmee kan Systems Engineering inspelen op de ontwikkelingen van een terugtredende overheid, steeds maar complexer wordende projecten en de roep om transparantie en beheersbaarheid in het ontwikkelproces (Rijkswaterstaat e.a., 2007). Rijkswaterstaat en ProRail richten zich met Systems Engineering op zowel het product dat dient te worden ontwikkeld als het proces wat daar aan te grondslag ligt. Voor de toepassing van Systems Engineering voor grote infrastructuurprojecten worden daarom ook twee soorten specificaties ontwikkeld (Rijkswaterstaat e.a., 2007). Er worden inhoudelijke eisen opgesteld die gelden voor het uiteindelijk op te leveren (fysieke) product en er worden proceseisen opgesteld. Proceseisen worden binnen Systems Engineering omschreven als eisen aan activiteiten die nodig zijn om het systeem of product tot stand te brengen (Rijkswaterstaat e.a., 2007). 12

13 2.3. Deelconclusie en relevantie voor onderzoek Dit hoofdstuk had tot doel om uiteen te zetten wat de belangrijkste kenmerken van Systems Engineering zijn, hoe de methode werkt en welke rol Systems Engineering speelt binnen Nederland. Daarnaast diende dit hoofdstuk een theoretische basis te vormen voor het inventarisatieonderdeel en het implementatieonderdeel van het onderzoek. Systems Engineering is een specificatie- en ontwerpmethode voor het ontwikkelen van producten en processen, waarbij alles wordt bekeken vanuit het perspectief van het totaalsysteem en het belang van alle aspecten zorgvuldig wordt afgewogen. Systems Engineering heeft tot doel structuur te geven aan en inzicht te verschaffen in de complexiteit van een te realiseren systeem. Systems Engineering is een van de disciplines waarbinnen het systeemdenken wordt toegepast. De belangrijkste kenmerken van Systems Engineering zijn: 1. Het systeemdenken en decompositie: een te ontwikkelen project, product of proces wordt binnen Systems Engineering benaderd als een systeem. Dat systeem kan worden opgedeeld in overzichtelijke onderdelen of niveaus en dat wordt decompositie genoemd. Decompositie van het systeem heeft als doel de complexiteit terug te brengen en het totaalsysteem beheersbaar te houden. Het systeem heeft raakvlakken met de omgeving en tussen de systeemelementen. 2. Het proces van specificatie, ontwerp en (continue) controle: de essentie is dat eerst wordt specificeert waar een te ontwikkelen product of proces aan dient te voldoen, vervolgens wordt het product of proces ontworpen aan de hand van de specificatie en uiteindelijk vindt er een controleslag plaats waarin wordt vastgesteld of het product of proces voldoet aan de vooraf opgestelde specificatie. Continue controle is van toepassing omdat op meerdere momenten in het proces wordt gecontroleerd. Controle vindt plaats met behulp van verificatiematrices. 3. De levenscyclus als uitgangspunt: Systems Engineering kent hier enerzijds een inhoudelijke benadering, waarin de methode aandacht heeft voor het opstellen van voorwaarden en prestaties ten aanzien van de gehele levensloop van het product of proces. Systems Engineering onderscheid anderzijds een procesmatige benadering van de levenscyclus waarin het van toepassing is op alle levensstadia van het project. Van ontwerp tot realisatie en sloop. Systems Engineering wordt gekenmerkt door expliciet formuleren en een gestructureerde werkwijze. Systems Engineering is voornamelijk geschikt voor complexe, unieke en multidisciplinaire projecten zoals grote infrastructuur- en bouwprojecten. Systems Engineering leidt tot een verzwaring van de eerste fase van het ontwikkelproces van een project, maar over de gehele projectcyclus leidt de methode tot een vermindering van de totaalinspanning, de totale ontwikkelkosten en het aantal ontwerpwijzigingen gedurende het proces. Binnen Nederland geven o.a. Rijkswaterstaat en ProRail vorm aan de ontwikkeling en standaardisering van Systems Engineering. Systems Engineering speelt binnen Nederland in op de ontwikkelingen van een terugtredende overheid, steeds maar complexer wordende projecten en de roep om transparantie en beheersbaarheid in het ontwikkelproces. Relevantie voor onderzoek Het onderzoek is opgebouwd in een inventarisatiefase en implementatiefase. In de inventarisatiefase zal onderzoek plaatsvinden naar knelpunten binnen het proces van de traditionele planstudiefase, waarbij wordt gekeken naar planstudiefases van projecten vergelijkbaar met de N34 en waarbij geen gebruik wordt gemaakt van de methode Systems Engineering. In de implementatiefase van het onderzoek zal Systems Engineering worden geïmplementeerd voor het project N34. De planstudiefase van het project N34 is voorbeeld van een complex, uniek en multidisciplinair project. Voor het project N34 dient tevens een MER te worden opgesteld. De processtappen van specificeren, ontwerpen en controleren en decompositie zullen worden geïmplementeerd voor het project N34 en er wordt gekeken of de ondervonden knelpunten uit de inventarisatiefase kunnen worden verminderd door de methode Systems Engineering. 13

14 3. Inventarisatie traditionele planstudiefase In dit inventarisatieonderdeel van het onderzoek is gekeken naar de knelpunten binnen het proces van de planstudiefase van multidisciplinaire infrastructuurprojecten zoals de N34. Tijdens de inventarisatie wordt onderzocht waar in het proces deze knelpunten zich bevinden, wat de oorzaken en gevolgen daarvan zijn en welke knelpunten als belangrijkste worden ondervonden Methode In het onderzoek is gekeken naar planstudiefases van multidisciplinaire infrastructuurprojecten die op de traditionele wijze zijn uitgevoerd, daarmee wordt bedoeld: zonder implementatie van Systems Engineering. Enkele voorbeeldprojecten waren: de omvorming van de N34 en N340. Organisaties Het onderzoek is uitgevoerd bij de provincie Overijssel en de combinatie. Voor deze organisaties is gekozen omdat zij continue planstudiefases van multidisciplinaire infrastructuurprojecten zoals de N34 en N340 doorlopen. Daardoor hebben deze organisaties veel kennis en ervaring opgedaan met deze projecten en de knelpunten die daarbij kwamen kijken. Er is voor een inventarisatie bij beide organisaties gekozen omdat dan een vollediger beeld van de problematiek kon worden verkregen. In bijlage 2 is aanvullende informatie te vinden over de organisaties van de provincie Overijssel en de combinatie. Onderzoeksstrategie Onder een onderzoeksstrategie wordt verstaan het geheel met elkaar samenhangende beslissingen over de wijze waarop het onderzoek wordt uitgevoerd. (Verschuren & Doorewaard, 2007) Er kunnen een vijftal strategieën worden onderscheiden, namelijk: (1) survey, (2) experiment, (3) casestudy, (4) gefundeerde theoriebenadering en (5) bureauonderzoek. Volgens Verschuren en Doorewaard (2005) bepalen drie kernbeslissingen de afweging voor een onderzoeksstrategie: 1. Breedte versus diepgang 2. Kwalitatief versus kwantitatief onderzoek 3. Empirisch versus bureauonderzoek Bij de eerste afweging is gekozen voor diepgang. Er zijn onvoldoende mogelijkheden om een breed scala aan planstudiefases van projecten te onderzoeken. Bovendien geeft een diepgaand onderzoek meer inzicht in de achtergronden en de oorzaken en gevolgen van de knelpunten. Bij de tweede afweging is gekozen voor een kwalitatief onderzoek. Opnieuw is bij deze keuze van belang dat er inzicht wordt verkregen in de achtergronden van het project en de knelpunten. Bij de derde afweging is gekozen voor empirisch onderzoek. In het implementatieonderdeel van het onderzoek wordt namelijk Systems Engineering voor het project N34 toegepast en daarom is het juist van belang om projecten zoals de N34 te onderzoeken. Momenteel is er onvoldoende specifieke informatie over dit soort projecten beschikbaar voor het uitvoeren van een bureauonderzoek om de knelpunten te achterhalen. Voor het inventarisatieonderdeel dient er dus een diepgaand, kwalitatief en empirisch onderzoek plaats te vinden en daarom is gekozen voor een (meervoudige) casestudy als onderzoeksstrategie. Een voordeel van een casestudy is dat het de mogelijkheid biedt om een integraal beeld te vormen van het onderzoeksobject. Hierin wijkt de casestudy af van een survey en experiment. Het integrale beeld kan een voordeel zijn voor een onderzoek dat is gericht op een verandering van een bestaande situatie, zoals bij dit onderzoek. Een ander voordeel van een casestudy is dat het gegevens oplevert die meer herkenbaar zijn en beter geaccepteerd worden dan in een survey. De acceptatie door de mensen in het veld is vaak een voorwaarde om een daadwerkelijke bijdrage aan een 14

15 veranderingsproces te kunnen leveren. Een mogelijk nadeel van de casestudy is dat de externe geldigheid van de resultaten soms onder druk staan. Naarmate minder gevallen worden bestudeerd, is het moeilijker de bevindingen van toepassing te verklaren. (Verschuren & Doorewaard, 2007) Delphi-techniek Om de knelpunten in de planstudiefase te achterhalen is gebruik gemaakt van de Delphi-techniek. Deze ondervragingstechniek verloopt in meerdere interviewronden. In de eerste interviewronde worden vragen voorgelegd aan een aantal deskundigen op het gebied van het onderzoek. De respons wordt daarbij zorgvuldig geanalyseerd en de grote lijnen worden aangegeven. De uitkomsten gaan vervolgens terug naar de ondervraagden in de vorm van een enquête, met het verzoek aan te geven hoe ze tegen hun eigen antwoorden en de antwoorden van andere ondervraagden staan. Vervolgens worden de uitkomsten van deze tweede ronde verwerkt en kunnen conclusies worden getrokken. (Verschuren & Doorewaard, 2007) Het belangrijkste voordeel van de Delphi-techniek is dat de deelnemers tot een weloverwogen oordeel kunnen komen, waarin diverse mogelijke standpunten tegen elkaar worden afgewogen. Dit is belangrijk omdat de uitkomsten van de interviews anders losse analyses blijven waaruit moeilijk een conclusie te vormen is. Als er maar één ronde van interviews zou worden afgenomen, zou het daarnaast arbitrair zijn om te bepalen welke knelpunten als belangrijkste worden aangezien. Daarnaast biedt het alleen afnemen van een enquête onvoldoende de mogelijkheid om open te staan voor nieuwe knelpunten die tijdens de interviews naar boven komen en de interpretaties van knelpunten. Door het afnemen van een enquête kan juist worden bepaald welke knelpunten als belangrijkste worden ondervonden door de ondervraagden. Door het toepassen van de Delphitechniek kunnen beide voordelen van een interview en enquête worden behaald en daarom is voor deze methode gekozen. In bijlage 3.1 wordt dieper ingegaan is de Delphi-techniek en welke afwegingen zijn gemaakt om het onderzoek uit te voeren. 15

16 3.2. Resultaten inventarisatieronden In deze paragraaf worden de resultaten van de inventarisatieronden besproken. Eerst zullen de resultaten van de interviewronden worden uiteengezet, daarna van de enquêteronde Resultaten Interviews Uit de interviewronden met de ondervraagden van provincie Overijssel en de combinatie kwamen acht knelpunten met bijbehorende oorzaken en gevolgen naar voren. De ondervonden knelpunten worden weergegeven in tabel 3.1. De inhoudelijke beschrijving van de knelpunten zijn toegelicht in bijlage 3.3. De knelpunten kunnen worden gezien als stellingen, die zijn gebaseerd op de interviews. Knelpunt Oorzaak Gevolg Onvoldoende vastleggen Vertraging proces, Raakvlakken (expliciet maken) wat input en oplopende kosten I tussen output van specialisten onderling specialisten dient te zijn II III IV Impliciete toetsingscriteria Interpretatie vraagspecialisatie Herleidbaarheid ontwerpkeuzes Toetsingscriteria zijn impliciet en daardoor kan de kwaliteit moeilijk worden gewaarborgd Onvoldoende afstemming (impliciet) wat opdrachtgever en opdrachtnemer van elkaar verwachten Onvoldoende vastgelegd waarom ontwerpkeuzes zijn gemaakt Ontwerpfouten, vertraging proces, kosten Aanpassingen aan producten, vertraging, kosten Opnieuw discussies, vertraging, kosten V Structurering informatie Veel informatie en weinig structurering daarvan Onvolledige ontwerpen en daardoor vertraging en oplopende kosten VI Herleidbaarheid eisen Moeilijk herleidbaar waar eisen vandaan komen Vergrootte kans bezwaarschriften, vertraging VII Herleidbaarheid aanpassingen Moeilijk kunnen aantonen wat met de terugkoppeling van de opdrachtgever is gebeurd Ontwerpfouten, aanpassingen, vertraging en kosten VIII Financieel schrappen in vage aspecten Als aspecten vaag zijn, zoals ecologie kunnen ze gemakkelijker worden geschrapt Tabel 3.1: Oorzaak-gevolg matrix Ambities komen onvoldoende tot uitwerking Tabel 3.1 geeft de oorzaken en gevolgen van de knelpunten beknopt weer. Opvallend is dat veel knelpunten worden veroorzaakt door impliciete formulering van eisen en wensen en daarnaast onvoldoende structurering en herleidbaarheid van informatie. De gevolgen van de knelpunten zijn vertragingen in het planstudieproces, ontwerpfouten en oplopende kosten. 16

17 Generalisten Specialisten Opdrachtgever Opdrachtnemer Resultaten Enquête Tijdens de enquête konden de ondervraagde specialisten en projectleiders 10 punten verdelen over de 8 knelpunten. De tabel met resultaten is opgenomen in bijlage 3.4. De volgende knelpunten werden als belangrijkste aangemerkt: 1. Raakvlakken tussen specialisten 2. Onvoldoende structurering van informatie 3. Verkeerde interpretatie van vraagspecificatie 4. Moeilijke herleidbaarheid van eisen Voornamelijk de bovenste drie belangrijkste knelpunten kwamen duidelijk naar voren door het hoge puntenaantal. De herleidbaarheid van eisen wordt als vierde belangrijkste knelpunt geselecteerd. Het knelpunt financieel schrappen in vage aspecten krijgt alleen punten van de twee ecologen, dat zegt dat het knelpunt lijkt te zijn gerelateerd aan een specialisme. De herleidbaarheid van ontwerpkeuzes en ontwerpaanpassingen worden niet als belangrijke knelpunten gezien. Impliciete toetsingscriteria wordt wel als een redelijk belangrijk knelpunt gezien Typologieën In figuur 3.2 staan de resultaten van het onderzoek ingedeeld naar groepen van generalisten en specialisten en opdrachtgever en opdrachtnemer. De aanleiding voor deze figuur is het aantonen of er grote verschillen zijn tussen de typologieën. Daarmee kunnen de resultaten beter worden geïnterpreteerd. Een generalist wordt gezien als een persoon die voornamelijk met het project als geheel bezig is, zoals een projectleider of een projectmedewerker. Een specialist wordt gezien als een persoon die zich voornamelijk met één aspect bezighoudt. De opdrachtgever is provincie Overijssel en de opdrachtnemer is de combinatie. In bijlage 3.2 is uiteengezet welke ondervraagden als generalist en welke als specialist worden gezien. Knelpunten I Raakvlakken tussen specialisten II Impliciete toetsingscriteria III Interpretatie vraagspecificatie IV Herleidbaarheid ontwerpkeuzes V Structurering informatie VI Herleidbaarheid eisen VII Herleidbaarheid aanpassingen VIII Financieel schrappen in vage aspecten Figuur 3.2: Typologieën [Gebaseerd op figuur in bijlage 3.4] 17

18 Generalisten versus specialisten Tabel 3.2 toont de belangrijkste knelpunten volgens de ondervraagde generalisten enerzijds en de specialisten anderzijds. De generalisten zien voornamelijk de interpretatie van de vraagspecialisatie, raakvlakken tussen specialisten en de structurering van informatie als belangrijkste knelpunten. Specialisten zien voornamelijk financieel schrappen in vage aspecten, structurering van informatie en herleidbaarheid van eisen als belangrijkste knelpunten. Generalisten Specialisten 1 Interpretatie vraagspecificatie (9) 1 Financieel schrappen in vage aspecten (7) 2 Raakvlakken tussen specialisten (8) 2 Structurering van informatie (5) 3 Structurering van informatie (8) 3 Herleidbaarheid eisen (5) Tabel 3.2: Top 3 knelpunten Generalisten/Specialisten De overeenkomt in de top 3 van beide groepen ondervraagden is het knelpunt van structurering van informatie. Het grote verschil tussen is het knelpunt van financieel schrappen in vage aspecten. Dit verschil kan worden verklaard doordat generalisten het project als een geheel aanschouwen en de specialisten het project vaak vanuit hun eigen discipline. Specialisten kunnen snel het gevoel krijgen dat juist op hun aspect wordt bezuinigd. Daarnaast is opvallend dat juist de generalisten de raakvlakken tussen specialisten als een belangrijk knelpunt ervaren, terwijl de specialisten zelf dit niet in belangrijke mate ondervinden Opdrachtgever versus opdrachtnemer Tabel 3.3 toont de belangrijkste knelpunten volgens de ondervraagde deskundigen van de opdrachtgevende partij enerzijds en de opdrachtnemende partij anderzijds. De opdrachtgever ziet voornamelijk de structurering van informatie en de herleidbaarheid van eisen als belangrijkste knelpunten. Een derde belangrijke knelpunt is moeilijk te bepalen, omdat vier knelpunten een derde plaats delen. De scores van de opdrachtgever over de knelpunten zijn redelijk verdeeld over de knelpunten. De opdrachtnemer ziet voornamelijk de interpretatie van de vraagspecificatie, raakvlakken tussen specialisten en de structurering van informatie als belangrijkste knelpunten. Opdrachtgever Opdrachtnemer 1 Structurering van informatie (6) 1 Interpretatie vraagspecificatie (9) 2 Herleidbaarheid eisen (5) 2 Raakvlakken tussen specialisten (8) 3 (Viermaal gelijke score) 3 Structurering van informatie(7) Tabel 3.3: Top 3 knelpunten Opdrachtgever/Opdrachtnemer De overeenkomst in de top 3 van belangrijkste knelpunten tussen beide groepen is de structurering van informatie, net zoals bij het onderscheid tussen generalisten en specialisten. Het grote verschil tussen beide groepen is dat de opdrachtnemer vooral de interpretatie van de vraagspecialisatie als belangrijkste knelpunt ziet. Dit verschil met de opdrachtgever kan worden verklaard doordat de opdrachtnemer vaak degene is die moet aftasten bij de opdrachtgever wat deze nou eigenlijk wil. Daarnaast is het ook de opdrachtnemer die het product dient aan te passen, wanneer blijkt dat de opdrachtgever wat anders voor ogen had. Een ander belangrijk verschil is het knelpunt van raakvlakken tussen specialisten. Dit verschil kan worden verklaard doordat de opdrachtnemer over het algemeen intensiever moet samenwerken met verschillende specialisten, dan de opdrachtgever. De opdrachtnemer moet een product vervaardigen met verschillende specialisten en de output van de ene specialist is de input van de andere. De vele raakvlakken tussen specialisten maakt het proces complex. De opdrachtgever controleert voornamelijk de producten. Daarbij is in mindere mate samenwerking tussen specialisten en zijn er minder raakvlakken waar problemen kunnen ontstaan. 18

19 3.4. Deelconclusie Dit hoofdstuk had tot doel de belangrijkste knelpunten in de planstudiefase van projecten zoals de N34 te achterhalen en de oorzaken en gevolgen daarvan uiteen te zetten. Daarvoor hebben interviews en een enquête met specialisten en projectleiders van de provincie Overijssel en de combinatie plaatsgevonden. Tijdens de interviews zijn acht knelpunten naar voren gekomen, tijdens de enquête zijn de knelpunten teruggekoppeld en de vier belangrijkste geselecteerd. Voor een specifieke beantwoording van deelvraag 2, worden de vier belangrijkste knelpunten die zich voordoen in de planstudiefase van projecten zoals de N34 zijn overzichtelijk uiteen gezet met oorzaken en gevolgen: 1. Raakvlakken tussen specialisten: De planstudiefase vergt een intensieve samenwerking tussen verschillende disciplines, maar de specialisten werken geregeld langs elkaar heen. Hierdoor wordt niet de juiste informatie aan elkaar afgeleverd of te laat afgeleverd. Dit heeft weer tot gevolg dat er vertragingen in het proces ontstaan. Bij projecten zoals de N34 is dit juist een belangrijk knelpunt omdat veel specialisten afhankelijk van elkaar zijn, door het multidisciplinaire karakter van het project. De oorzaak van het knelpunt is dat specialisten elkaar niet goed informeren of te weinig communiceren, het gevolg is dat specialisten worden opgehouden door het wachten op producten van andere specialisten en daardoor het proces wordt vertraagd. 2. Onvoldoende structurering van informatie: Informatie wordt onvoldoende gestructureerd opgeslagen en verwerkt. Bij projecten zoals de N34 is dit juist een probleem omdat het project een langdurig proces is waar veel informatie wordt geproduceerd en veel verschillende belanghebbenden bij betrokken zijn. Als informatie niet goed gestructureerd is, wordt het vaak maar deels meegenomen in het project en dat heeft invloed op de kwaliteit van de producten. Een oorzaak voor het knelpunt kwam niet duidelijk naar voren, mogelijk heeft tijdsdruk een invloed. Het gevolg van het knelpunt is dat producten deels moeten worden aangepast en dat vertraagt het proces en verhoogt de kosten. 3. Verkeerde interpretatie van vraagspecificatie:het is voor opdrachtgever en opdrachtnemer moeilijk om af te stemmen wat men van elkaar verwacht en wat elkaars interpretatie is van een vraagspecificatie. Vaak komt dit pas naar boven op het moment dat de eerste versie wordt aangeleverd. Dit knelpunt geldt in versterkte mate voor projecten zoals de N34, omdat het project zich in de planstudiefase bevindt en opdrachtgever en opdrachtnemer in bepaalde mate nog zoekende zijn naar een product en de eisen waar het aan dient te voldoen. Daardoor zijn eisen vaak minder expliciet geformuleerd waardoor er ruimte in de interpretatie ontstaat. Het gevolg daarvan is dat ontwerpen moeten worden aangepast en opnieuw een afstemming nodig is. Dit heeft uiteindelijk tot gevolg dat het proces wordt vertraagd en dat kosten oplopen. 4. Moeilijke herleidbaarheid van eisen: De eisen die worden gesteld aan een te ontwerpen weg of een te ontwikkelen rapportage zijn soms moeilijk herleidbaar. Het gevolg is dat een opdrachtgever moeilijk kan aantonen wat er met een bepaalde eis is gebeurd en of deze eis is meegenomen in het ontwerp of de rapportage. Voor projecten zoals de N34 is dit een belangrijk knelpunt, omdat de opdrachtgever (vaak politieke instantie) gehoor wil geven aan een steeds grotere roep aan transparantie naar de burger toe. Dit wordt bemoeilijkt door het moeilijk herleidbaar zijn van eisen. Het knelpunt kan leiden tot een slechtere relatie met omwonenden en mogelijk tot meer bezwaarschriften, wat een vertraging van het planvormingproces tot gevolg kan hebben. Opvallend is dat veel knelpunten worden veroorzaakt door impliciete formulering van eisen en wensen en daarnaast onvoldoende structurering en herleidbaarheid van informatie. De gevolgen van de knelpunten zijn over het algemeen vertraging van de planstudiefase en oplopende kosten. De hoofdlijn in de vier benoemde knelpunten is vooral de structurering van informatie. Alle knelpunten hebben daar in meer of mindere mate betrekking op. Bij het ontwikkelen van het verbetervoorstel dient daarom de nadruk te worden gelegd op het structureren van informatie. 19

20 Typologieën Tijdens het onderzoek is tevens gekeken naar typologieën. De ondervraagden zijn ingedeeld in groepen van generalisten en specialisten, en opdrachtgever en opdrachtnemer en daarbij is gekeken naar welke knelpunten zij als belangrijkste aanduiden. Bij de generalisten en specialisten viel het op dat het knelpunt van structurering van informatie bij beiden in de top drie van belangrijkste knelpunten was opgenomen. Verder waren er geen overeenkomsten. Het grote verschil tussen de generalisten en specialisten omvatte het knelpunt van financieel schrappen in vage aspecten. Daarnaast was het opvallend dat juist de generalisten de raakvlakken tussen specialisten als een belangrijk knelpunt aanmerkten, terwijl de specialisten dit knelpunt in mindere mate ondervonden. Bij de generalisten en specialisten was het knelpunt van de structurering van informatie bij beide groepen in de top drie van belangrijkste knelpunten opgenomen, net zoals bij de generalisten en specialisten. Het grote verschil tussen de opdrachtgever en opdrachtnemer was dat de opdrachtnemer de interpretatie van de vraagspecialisatie als belangrijkste knelpunt ondervond en opdrachtgever niet. Rapportage versus ontwerp In het project van de N34 zijn eigenlijk twee op te leveren producten: een planstudie MER en een omgevormde N34. Het ene product is kort gezegd een stapel papieren en het andere een weg van asfalt. De opdrachtgever ziet vooral de weg als eindproduct, de opdrachtnemer de rapportage. De opdrachtnemer is namelijk alleen ingehuurd voor de planstudie MER fase. Het gevolg hiervan is dat de insteek van personen in het project soms verschilt. Een voorbeeld is dat voor het aspect ecologie de opdrachtnemer voornamelijk kijkt naar de wettelijke toetsingskaders, zodat de MER rapportage wordt goedgekeurd. Echter wil de ecoloog van de opdrachtgever meer nieuw beleid vertaald hebben in het ontwerp. 20