Bijlage A Probleemkluwen in oorzaak-gevolg diagram
Informatie mag niet risico-overdracht veroorzaken OG heeft info nodig over
de voortgang en het product
OG wil geen aansprakelijk/
risico voor het product OG mag geen productin- houdelijke informatie krijgen OG koppelt financiële
aspecten aan informatie OG heeft informatie nodig om financiële aspecten aan te koppelen
OG weet niet alles van het product
Kwaliteit product niet goed te garanderen
Overheid heeft moeite met de veiligheidsgarantie tegenover burgers
Beheersing van proces en product moet veranderen
Beheersing op basis van functionele eisen OG krijgt andere taak mbt
informatievoorziening OG moet andere
kwaliteiten hebben
Overheid heeft te maken met rechtmatigheid
van betalingen Rechtmatigheid van betalingen moet worden aangetoond
OG wil optimaal gebruik maken van product
ON moet gemotiveerd worden om onderhouds- arm product te leveren
Betalingen worden gedaan op basis van functionaliteit van product
OG wil info hebben over functionaliteit van het product in gebruiksfase
OG moet objectief verschillende
aanbiedingen beoordelen OG heeft handvat nodig om objectieve keuze te maken
OG wil goedkoper product door integratie van ontwerp t/m onderhoud en af te rekenen op basis van prestatie in gebruiksfase OG wil goedkoper
totaalproduct
OG wil ON motiveren om goed product tegen lage kosten te leveren OG heeft passend motivatiemiddel nodig
Overheid/OG wil kwaliteit product garanderen Overheid/ OG heeft info nodig over product en proces OG heeft info nodig
over de eigenschappen van ontworpen product
Informatiebehoefte verandert
Beloning op basis van prestaties in gebruiksfase Informatieaanbod moet
veranderen naar OG
ON moet gemotiveerd worden om goedkopere oplossing te bedenken
ON krijgt andere taak mbt informatievoorziening
ON moet product voorfinancieren
OG kan vaak goed- koper geld lenen dan ON OG wil voor-
schotten geven
OG zal niet alles laten voorfinancieren ON bedenkt oplossing
voor het probleem en doet een aanbieding
Bijlage B D,C&M contracten vs. PPS
PPS staat voor Publiek-Private Samenwerking. PPS is echter niet gelijk aan geïntegreerde contracten. Daarom wordt eerst ingegaan op het begrip PPS, waarna verschillen en overeenkomsten gegeven worden tussen PPS en de al eerder omschreven geïntegreerde contracten. Hierna zal aangegeven worden waarop gericht zal worden in dit onderzoek.
PPS
PPS is een samenwerkingsverband waarbij overheid en bedrijfsleven, met behoud van eigen identiteit en verantwoordelijkheid, gezamenlijk een project realiseren. Dit samenwerkingsverband is op basis van een duidelijke taak- en risicoverdeling. Het doel van een PPS is het realiseren van meerwaarde en efficiëntiewinst.
Dit zal bereikt kunnen worden wanneer zowel overheid als bedrijfsleven datgene doen waar ze het best in zijn. Er zal een win-win situatie moeten ontstaan. (KC PPS, 08-2001)
PPS-projecten hebben bepaalde kenmerken. Bij een PPS-project werken overheden en bedrijfsleven samen op basis van duidelijke contractueel vastgelegde afspraken, waarin is vastgelegd wie waarvoor verantwoordelijk is en wie welke kosten en risico’s draagt. Het gaat bij een PPS-project om het realiseren van zowel maatschappelijke als commerciële doelen, waarbij beide partijen verwachten een beter resultaat tegen dezelfde kosten te realiseren (of hetzelfde resultaat tegen geringere kosten), dankzij de samenwerking en de inbreng van ieders specifieke deskundigheid.
Er zijn een drietal basisvoorwaarden voor een succesvolle PPS-aanpak, te weten (KC PPS, 08-2001):
1. Output-gericht werken: Hierbij wordt benadrukt dat de overheid niet alle details van het project vooraf moet vastleggen, waardoor de markt wordt gereduceerd tot uitvoerder. Om de kennis, ervaring en creativiteit van het bedrijfsleven optimaal te benutten, moet de overheid de productspecificaties niet vooraf vastleggen, maar wat het product moet kunnen. Daarbinnen moet ruimte blijven voor inbreng van het bedrijfsleven. Er moeten controleerbare prestatienormen worden geformuleerd om de private partijen te kunnen afrekenen op de gemaakte afspraken. De overheid is tenslotte verplicht de publieke middelen zodanig te besteden dat democratische controle mogelijk is.
2. Optimale scope: Naast het bieden van ruimte voor eigen inbreng van de markt bij het vaststellen van de productspecificaties, moeten de grenzen van het project – de ‘scope’ – niet te strak worden vastgesteld.
Hierdoor ontstaat de mogelijkheid voor integratie van verschillende (onderdelen van) projecten, waardoor soms een betere afstemming mogelijk is. Hierdoor kan een meerwaarde ontstaan. De verbreding van de scope van een project kan er tevens toe leiden dat ook andere partijen financiële middelen inbrengen, omdat zij eigen belangen kunnen realiseren door deelname. Hierdoor komt meer geld beschikbaar, wat de kwaliteit van de projecten ten goede kan komen.
3. Juiste samenwerkingsvorm: In elke fase van een PPS-project moet volstrekte duidelijkheid bestaan over de inbreng, taken en verantwoordelijkheden van alle betrokken partijen. Het Kenniscentrum PPS hanteert hierbij een aantal beleidsinstrumenten. Deze zullen hier echter niet worden besproken.
Binnen PPS kan onderscheid gemaakt worden tussen faciliterende publiek-private samenwerkings-verbanden
en participatie gerichte publiek-private samenwerkingsverbanden. Bij faciliterende PPS-verbanden heeft de
overheid niet meer dan een faciliterende taak. De samenwerking tussen publieke en private partijen is dan
lange duur) exploitatierecht op de markt tegen een zekere vergoeding. De vergoeding kan dan vast zijn of geheel of gedeeltelijk afhankelijk van het exploitatieresultaat. (KC PPS, 08-2001)
PPS vs. D,C&M contracten
Er zijn verschillende overeenkomsten en verschillen tussen PPS en D,C&M contracten waar te nemen.
Hieronder zullen de grootste verschillen en de duidelijkste overeenkomsten omschreven worden. (Andersson et al., 2001)
Het eerste verschil is dat er bij PPS sprake moet zijn van een project die niet gerealiseerd zou kunnen worden wanneer de partijen gescheiden zouden opereren. Het gaat er hierbij om dat samen keuzes worden gemaakt over de inhoud en de organisatie van een project. Bij een geïntegreerd contract is er ‘slechts’ sprake van een verschuiving van verantwoordelijkheid tussen opdrachtgever en opdrachtnemer, waarbij het gaat om een juridische opdrachtgever-opdrachtnemer relatie. Hierbij kan er echter wel meerwaarde ontstaan, waardoor er weer gesproken kan worden van een PPS. Een tweede verschil is de invulling van het opdrachtgeverschap en de invloed die de opdrachtnemer daar op heeft. Bij sommige PPS-projecten kan er zelfs sprake zijn van een gedeeld opdrachtgeverschap in een PPS-ontwikkelingsmaatschappij.
De samenwerking van partijen bij bouwprojecten kan verschillend worden georganiseerd. Het kan zijn dat er sprake is van een geïntegreerd contract en dat er tevens sprake is van een PPS, maar dat zal zeker niet altijd het geval zijn. Dit is ook het derde verschil: een PPS is in de regel een geïntegreerd contract, maar een geïntegreerd aanbesteed project hoeft geen PPS te zijn.
In de praktijk blijken er verschillende visies te zijn over de term PPS. Andersson Elffers Felix, een bureau dat in opdracht van Rijkswaterstaat een evaluatierapport heeft opgesteld, stelt dat een project slechts als PPS kan worden beschouwd wanneer er uitsluitend sprake is van samenwerking. Wanneer er sprake is van een vastgelegde relatie tussen opdrachtgever en opdrachtnemer, is er geen sprake meer van een PPS. Het Kenniscentrum PPS heeft hierop duidelijk een andere visie. Zij geeft aan dat er sprake is van een PPS, wanneer er meerwaarde ontstaat door het samenwerken van partijen. Hierbij zal echter volstrekte duidelijkheid moeten bestaan over inbreng, taken en verantwoordelijkheden van de betrokken partijen.
In dit rapport wordt de visie van het Kenniscentrum PPS gehanteerd. De reden hiervoor is dat het Kenniscentrum onderdeel is van het ministerie van Financiën, waarbij zij de taak heeft, naast kennis en ervaring bijeen te brengen, het beleid op het gebied van PPS nader te formuleren.
Uitbreidingsmogelijkheid D,C&M contracten
Er zijn verschillende vormen van geïntegreerde contracten aan bod gekomen. Hierbij werd onderscheid gemaakt in D&C en D,C&M contracten. Er bestaan echter nog meer vormen. Er kan tevens een financieringsaspect worden meegenomen in het contract evenals een transferaspect. Onder het financieringsaspect wordt verstaan dat private partijen een rol spelen in de financiering van het project. Het transferaspect houdt de overdracht in van het product na een bepaalde periode. Bij de integratie van eveneens deze aspecten in de contracten kunnen dus meer verschillende vormen van geïntegreerde contracten ontstaan.
Wanneer het financieringsaspect wordt meegenomen in de contracten wordt wederom vaak gesproken van
een PPS, waarbij gebruik wordt gemaakt van het concessiemodel.
Het concessiemodel
Voor het concessiemodel zijn een aantal uitgangspunten geformuleerd door het Kenniscentrum PPS:
(KC PPS, 02-2001)
1. De overheid zet een geïntegreerd investeringsproject in de markt: ontwerp, aanleg, onderhoud en financiering;
2. De overheid werkt outputgericht en geeft voldoende ruimte aan marktpartijen: niet het product, maar de te leveren dienst of prestatie staat centraal;
3. Een concessie wordt Europees aanbesteed;
4. Het gebruik van vergelijkingsinstrumenten moet zeker stellen dat voor die aanbestedingswijze wordt gekozen die de meeste meerwaarde oplevert;
5. De risico’s worden gelegd bij de partij die het beste in staat is het betreffende risico te beheersen;
6. De integratie van de financiering in de concessie maakt de risico-overdracht hard (de investeringskosten van het project liggen bij de private partij);
7. Betaling is gebaseerd op de afgesproken dienst of prestatie in plaats van het product.
D,C&M vs. concessiemodel
Het D,C&M contract komt op veel punten overeen met het principe van het concessiemodel. Het verschil met het eerste punt is erg duidelijk. Bij D,C&M contracten wordt er in principe geen investeringsproject in de markt gezet. Het project zal ‘slechts’ bestaan uit de fasen ontwerp, aanleg en onderhoud. Echter, het kan zo zijn dat er een bepaalde mate van financiering door de opdrachtnemer aan te pas komt. Doordat afgerekend wordt op de prestatie van het product, zal de opdrachtnemer dus pas tijdens gebruiksfase betaald krijgen. Zo zwart-wit is het bij het D,C&M contract niet, aangezien het zo kan worden geregeld dat de opdrachtnemer al tijdens de uitvoering geld krijgt, waardoor de opdrachtnemer minder of geen geld hoeft te lenen. Dit principe staat echter nog niet vast, maar zal nog verder uitgewerkt moeten worden en zal wellicht per project verschillen. Het tweede punt is voor zowel het concessiemodel als het D,C&M contract gelijk. De prestatie of de dienst zal centraal staan, waardoor de overheid outputgericht werkt. Het Europees aanbesteden van een D,C&M contract is niet per definitie nodig. Er moet alleen Europees aanbesteed worden wanneer het project een bepaald bedrag overschrijdt. Het vierde punt is een niet te vergelijken punt. Hierover is alleen te zeggen dat het zinvol is om eerst objectief na te gaan of de aanbestedingswijze meerwaarde zal opleveren.
Het beheersen van de risico’s zal bij beide modellen gelegd worden bij de partij die ze het beste kan
beheersen. Toch zal dit punt iets moeilijker liggen bij het D,C&M contract dan bij het concessiemodel. Hierbij
sluit punt zes aan, die de verklaring hiervoor geeft. Toch zal dit aspect redelijk ondervangen worden door
hetgeen bij punt één reeds aan bod is gekomen. Het laatste punt komt dan ook vrijwel overeen bij beide
modellen.
Bijlage D Informatiestromen bij configuratiebeheer
Het onderstaande stroomschema (bron: Maas 1994, p.197) geeft de hoofdlijnen weer van de informatie- stromen die van belang zijn bij wijzingenbeheer.
Ontwerpafdeling Wijzigingscommissie CCB (Conf.control Overige afdelingen ondersteuning board, red.)
= Wijzigingscommissie
dien wijzigings- verzoek in op eerste vrijgave
(initiatie)
bereid wijzigingsorder en
distribueer
beoordeel voorstellen en autoriseer indien
accoord neem wijzigings- voorstellen door
en evalueer bereid voorstel
voor (incl. doc. en distr.) onderzoek gevolgen van
wijziging
vaardig leden af
verander doc.
en specs verander
basisdocumenten voer
veranderingen in
Bijlage E Het V-model (Bron: Yeates, 1996, p.64)
Steps in the development stage Product
Activity
Customer requirements
Requirements specification
Tested system
Module specifications Requirements
definition
Integration and test
Module testing Module
production High level
design
Technical specification
Low level design
Integrated system
Tested Modules
Developed Modules
System testing Customer acceptance Accepted system
Develop/
agree acceptance
criteria
Acceptance criteria
Generate system test
plan
Produce integration
test plan
System test plan
Integratie test plan
Module test plan Produce
module test plan
Pre-contract stage Completion stage
Bijlage F Gehanteerde vragenlijst interviews + overzicht geïnterviewde personen De onderstaande vragen zijn gebruikt als leidraad voor de interviews met personen die werken met een D,C contract. Niet alle vragen zijn gesteld aan elke geïnterviewde persoon. De keuze van de vragen is afhankelijk van de functie en de kant waar het open interview naartoe ging.
Geïnterviewde personen
- Dhr. N. Scholten functieomschrijving: projectingenieur bij HSL-Zuid
- Dhr. D. Santurio Gonzalez functieomschrijving: juridisch adviseur innovatieve aanbestedingen en PPS - Dhr. W. Klomp functieomschrijving: contractmanager bij HSl-Zuid
- Dhr. X. Utberg functieomschrijving: manager technical compliance & performance binnen de projectorganisatie IPCM (Infra Provider Contract Management)
Ontwerpfase Functionele eisen:
1. Hoe worden deze omschreven, zijn er verschillende niveaus in te vinden?
2. Worden er bijvoorbeeld materialen of oplossingen voorgeschreven?
3. Aan welke eisen moet de informatie voldoen, met het oog op de kwaliteit van de informatie?
4. Zijn er juridische consequenties voor de opdrachtgever wanneer deze zich ‘te veel’ verdiept in het ontwerp en berekeningen van de opdrachtnemer?
5. Vind er risico-overdracht plaats? Zijn er bepaalde kritische onderdelen waar de OG het risico van overneemt?
6. Wordt er nog onderhandeld over de prijs met de laatst overgebleven opdrachtnemer?
7. Bij HSL lag het ontwerp eigenlijk al klaar, terwijl dit eigenlijk tegen het idee van D&C contracten in gaat, wat zijn de nadelen/voordelen van dit gegeven?
Beheersing:
8. Hoe vind beheersing in de ontwerpfase plaats van de volgende aspecten, zowel bij OG als ON: tijd, geld, kwaliteit, informatie, organisatie en risico. Ook al met het oog op de volgende fasen?
9. Hoe wordt in deze fase de publieke verantwoordelijkheid gewaarborgd?
10. Is er een stoppunt/ beslisdocumenten aan het einde van de design-fase?
Construct-fase
11. Welke gegevens zijn nodig om de toestand van het systeem aan te geven onder de gegeven randvoorwaarden?
Audits:
12. Hoe worden de afwijkingen geregistreerd, welke afwijkingen worden geregistreerd?
13. a. Wat wordt juist wel en wat juist niet geaudit, kan dit terug worden gebracht naar een bepaald niveau in de specificatie?
b. Welke eisen/normen moeten beheerst worden?
14. Vindt er risico-overdracht plaats wanneer er wordt geaudit? Waarom wel/niet?
15. Hoe vindt de verwerking plaats van de afwijkingen/ gecontroleerde onderdelen, met welke norm wordt het vergeleken?
16. Wordt er onderhandeld, nadat er een onherstelbare afwijking is gesignaleerd over aanpassing van de termijnen?
17. Audits worden gehouden door de OG, niet door onafhankelijke derde, wat zijn de risico’s ten opzichte van auditing door derde.
18. Hoe wordt de informatie door ON aangeleverd?
19. Welke eisen worden aan de informatie gesteld, met het oog op de kwaliteit van informatie?
20. Hoe wordt in deze fase de publieke verantwoordelijkheid gewaarborgd?
Beheersing:
21. Tijd is ook een beheersaspect, waarom wordt dit gecontroleerd, als de einddatum maar wordt gehaald is het toch voldoende?
22. Hoe vind beheersing in deze fase plaats van de volgende aspecten, zowel bij OG als ON: tijd, geld, kwaliteit, informatie, organisatie en risico. Ook al met het oog op de volgende fase?
23. Welke stuurmaatregelen worden hier gebruikt?
Vragenlijst interview dhr. Utberg bij IPCM
De onderstaande vragen zijn gebruikt als leidraad voor het interview. Niet alle vragen hoeven worden gesteld aan de geïnterviewde persoon. De keuze van de vragen is afhankelijk van de kant waar het open interview naartoe gaat.
Leidraad:
Je wilt: het product dat je vraagt
weten of het product dat je krijgt voldoet aan je vraag inzicht in de totstandkoming zonder risico-overdracht
voldoende zekerheid mbt de ministeriele verantwoordelijkheid dat de boven- en onderbouw op elkaar aansluit
effectieve stuurmaatregelen kunnen uitvoeren optimale life-cycle kosten
minder inspanning vanuit de opdrachtgever.
Ontwerp-fase Functionele eisen:
1. Hoe worden deze omschreven, zijn er verschillende niveaus in te vinden?
2. Worden er bijvoorbeeld materialen of oplossingen voorgeschreven?
3. Zijn er voorwaarden verbonden aan de informatie (zoals ontwerp, berekeningen, tekeningen) die moet worden aangeleverd?
4. Is er bepaalde informatie die jullie niet willen weten met betrekking tot de juridische consequenties voor de opdrachtgever wanneer deze zich ‘te veel’ verdiept in het ontwerp en berekeningen van de opdrachtnemer?
5. Zijn er bepaalde kritische onderdelen waar de OG het risico van op zich neemt?
6. Wordt er nog onderhandeld over de prijs met de laatst overgebleven opdrachtnemer?
7. Het ontwerp dient, lijkt mij, af te hangen van het product dat ontstaat tijdens de bouw van de onderbouw. Hoe is die relatie gelegd, en hoe wordt omgegaan met wijzigingen die tijdens de bouw van de onderbouw optreden?
8. Hoe vind beheersing in de ontwerpfase plaats van de volgende aspecten, zowel bij OG als ON: tijd, geld, kwaliteit, informatie, organisatie en risico. Ook al met het oog op de volgende fasen?
9. Hoe wordt in deze fase de publieke/publieke verantwoordelijkheid gewaarborgd?
specificaties, waar rechtstreeks uit op te maken is waaraan het object moet voldoen?
13. Wat wordt juist wel en wat juist niet geaudit, kan dit terug worden gebracht naar een bepaald niveau in de specificatie?
14. Welke eisen/normen moeten beheerst worden?
15. Vindt er risico-overdracht plaats wanneer er wordt geaudit? Waarom wel/niet?
16. Hoe worden de afwijkingen geregistreerd, welke afwijkingen worden geregistreerd?
17. Hoe vindt de verwerking plaats van de afwijkingen/ gecontroleerde onderdelen, met welke norm wordt het vergeleken?
18. Wordt er onderhandeld, nadat er een onherstelbare afwijking is gesignaleerd over aanpassing van de termijnen?
19. Wordt gebruik gemaakt van stuurmaatregelen wanneer afwijkingen worden geconstateerd? (op tijd, geld, kwaliteit, informatie, organisatie en risico)
20. Worden er ook audits gehouden door een ‘onafhankelijke derde’,waarom wel/niet.
21. Hoe wordt de informatie aangeleverd?
22. Welke eisen worden aan de informatie gesteld, met het oog op de kwaliteit van informatie?
23. Hoe wordt in deze fase de publieke verantwoordelijkheid gewaarborgd?
24. Zal minder inspanning door de opdrachtgever mogelijk zijn in deze fase? Zo ja, hoe zal dit mogelijk gemaakt kunnen worden.
Maintain-fase
25. Wat wordt er precies verstaan onder Maintain, wat hoort wel/ niet bij de taken van de opdrachtnemer.
26. Hoe is dit aangegeven in de specificaties?
27. Vind na de onderhoudsfase productoverdracht plaats?
28. Hoe is geregeld?
29. Zijn er voorwaarden vastgelegd voor de verhouding opdrachtnemer – gebruiker, zoals het niet blijken voldoen van het product aan de specificaties is een geschil tussen beiden?
30. Hoe wordt de gevraagde prestatie vastgelegd in de functionele specificatie?
31. Hoe wordt in deze fase de prestatie van het product aangeven?
32. Op welk niveau worden toetsen uitgevoerd? Zijn deze objecten terug te vinden in de functionele specificaties, waar rechtstreeks uit op te maken is waaraan het object moet voldoen?
33. Wat wordt juist wel en wat juist niet getoetst, kan dit terug worden gebracht naar een bepaald niveau in de specificatie?
34. Welke eisen/normen moeten beheerst worden?
35. Wordt gebruik gemaakt van stuurmaatregelen wanneer afwijkingen worden geconstateerd? (op tijd, geld, kwaliteit, informatie, organisatie en risico)
36. Vindt er risico-overdracht plaats wanneer er wordt getoetst? Waarom wel/niet?
37. Worden er ook audits gehouden door een ‘onafhankelijke derde’,waarom wel/niet.
38. Hoe wordt de informatie aangeleverd?
39. Welke eisen worden aan de informatie gesteld, met het oog op de kwaliteit van informatie?
40. Hoe wordt in deze fase de publieke verantwoordelijkheid gewaarborgd?
41. Wordt bij de overdracht een ‘handboek’ gevraagd of komt deze binnen de organisatie van de
opdrachtgever tot stand?
Bijlage G Beheersing eindproduct d.m.v. verschillende toetsen in de verschillende fasen. (naar: V-model vlgs. Yeates)
Cyclisch proces
Bouwfase Verantwoor - ding ON Initiatief - &
definitiefase Verantwoor - ding OG
Klant wensen
Eisen Specificatie
Getest systeem Bouwmodule
Specificatie Eisen Definitie
Integreren en testen Testen
Bouwmodules
Productie Bouwmodule
High level ontwerp
Technische specificatie
Low level ontwerp
Geïntegreerd systeem Geteste
Bouwmodule Ontwikkelde bouwmodules
Testen systeem
Instemming klant
Gebruiksklaar systeem Ontwikkel/
overeen- stemmen acceptatie criteria Door ON
Acceptatie criteria Genereer
systeem test plan Door ON Vervaardig
integratie test plan Door ON
Systeem testplan
Integratie testplan
Bouwmodule testplan Vervaardig bouwmodule
test plan Door ON Ontwerpfase
Verantwoor - ding ON Func- tioneel PvE
Contract
‘beste aanbieding’
Vóór in gebruik name Verantwoor- ding ON Testen systeem
tijdens gebruik
Verminderd kwaliteitsniveau
systeem Ontwikkel
onderhoud test plan
Door ON Kwaliteitsniveau periodiek testplan
Gebruiksfase Verantwoor- ding ON gedurende X jaar Controleren
systeem
Gecontroleerd systeem
Verantwoor- ding OG op t = X jaar
Onderhouden systeem
Gebruikersvrien delijk systeem
Gebruiken systeem
Gebruiksfase Verantwoor- ding OG na t = X jaar
