Het verschaffen van zekerheden met de Gateway Review methode

Het verschaffen van zekerheden met de Gateway Review methode

Studentnaam: Opleiding: Begeleider: Studentnummer: Datum:

drs. L.H. Kwak MSc. RA Postgraduate IT Audit Opleiding van de Vrije Universiteit Amsterdam dr. R.P.H.M. Matthijsse RE 1882708 1-3-2010

Voorwoord Als onderdeel van de Postgraduate IT Auditing opleiding aan de Vrije Universiteit Amsterdam heb ik de scriptie ‘Het verschaffen van zekerheden met de Gateway Review methode’ geschreven. De scriptie zal me bijblijven als de meest boeiende en uitdagende scriptie die ik, tot op heden, geschreven heb. Dit komt voor een belangrijk deel omdat ik bij deze scriptie gebruik heb kunnen maken van de deskundigheid, ervaringen en vaardigheden van diverse sleutelfunctionarissen van binnen en buiten de Rijksoverheid. Mijn scriptiebegeleider, de heer dr. René Matthijsse RE, wil ik bedanken voor het meedenken over het scriptieonderwerp, het optreden als sparringpartner en klankbord. Daarnaast is de heer Matthijsse ook behulpzaam geweest bij het leggen van contacten voor interviews. De heer Michel Bouten RA, van het ICTU, bedank ik voor het aandragen van programma’s waarop ik in het kader van deze scriptie nader ben ingegaan. Tevens heeft de heer Bouten aangegeven welke personen door middel van een interview een kwalitatieve bijdrage kunnen leveren aan deze scriptie en heeft hij de concept scriptie van commentaar voorzien. De eerste interviews voor deze scriptie hebben plaatsgevonden met medewerkers van Het Expertise Centrum (de heren Mollema, de Graaf en de Roos). Deze medewerkers zijn er in geslaagd om de Gateway Review methode zo enthousiast aan mij over te brengen, dat mijn betrokkenheid bij het onderwerp gedurende het schrijven van de scriptie niet meer is weggeëbd. Mijn dank gaat uit naar alle geïnterviewden die bereid waren om mij te woord te staan over de Gateway Review methode en de programma’s die aanbod komen in deze scriptie. De diversiteit van meningen, conclusies en inzichten van de geïnterviewden zijn van onschatbare waarde geweest bij de totstandkoming van deze scriptie. Helaas is het niet mogelijk geweest om alle interessante, met de geïnterviewden besproken, onderwerpen op te nemen in de scriptie. De keuze over wat wel en wat niet op te nemen in deze scriptie was soms moeilijk. Bij het afronden van de scriptie heb ik zowel inhoudelijk als redactioneel ondersteuning gekregen van de heer Klaas Niewold RE en de heer Alfred Vegter RA. Beide heren hebben mij belangeloos van advies voorzien en hebben mijns inziens een waardevolle bijdrage geleverd aan de vorm en inhoud van de scriptie. Een woord van dank geldt ook mijn werkgever, Belastingdienst Zeer Grote Ondernemingen Noord, die mij instaat gesteld heeft om een deel van de scriptie in werktijd te schrijven. Dit terwijl er in deze periode veel werk op de plank lag. Deze scriptie is geschreven op persoonlijke titel.

2

Inhoudsopgave 1. INLEIDING....................................................................................................................................................... 5 1.1. INLEIDING ......................................................................................................................................................... 5 1.2. FALENDE ICT-PROJECTEN BIJ DE OVERHEID ..................................................................................................... 5 1.3. HET ANTWOORD OP DE PROBLEMATIEK ROND ‘FALENDE ICT PROJECTEN BIJ DE OVERHEID’ ........................... 9 1.4. CENTRALE VRAAGSTELLING ........................................................................................................................... 11 1.5. METHODOLOGIE EN ONDERZOEKAANPAK ....................................................................................................... 11 1.6. LEESWIJZER .................................................................................................................................................... 11 2. GATEWAY REVIEW METHODE .............................................................................................................. 12 2.1. DOEL EN INHOUD VAN DE GATEWAY REVIEW METHODE ................................................................................ 12 2.2. ONTWIKKELING EN UITGANGSPUNTEN VAN DE GATEWAY REVIEW METHODE................................................ 15 2.2.1. De ontwikkeling van de Gateway Review methode in Nederland ............................................................... 15 2.2.2. Uitgangspunten Gateway Review................................................................................................................ 16 2.3. BESCHRIJVING VAN DE VERSCHILLENDE GATEWAY REVIEWS ........................................................................ 17 2.3.1. Gateway 0: Strategische doorlichting......................................................................................................... 17 2.3.2. Gateway 1: Zakelijke rechtvaardiging ........................................................................................................ 18 2.3.3. Gateway 2: Verwerving- c.q. veranderstrategie ......................................................................................... 19 2.3.4. Gateway 3: Investeringsbeslissing .............................................................................................................. 20 2.3.5. Gateway 4: Gereedheid voor dienstverlening............................................................................................. 21 2.3.6. Gateway 5: Evaluatie van behaalde resultaten........................................................................................... 21 2.4. CONCLUSIE ..................................................................................................................................................... 22 2.4.1. Gateway Review versus reguliere audit ...................................................................................................... 22 2.4.2. Voor en nadelen van de Gateway Review methode..................................................................................... 25 2.4.3. Effectiviteit in te zetten Gateway Review’s.................................................................................................. 26 3. BESCHRIJVING OVERHEIDS IT-PROJECTEN..................................................................................... 27 3.1. GEMEENSCHAPPELIJKE MACHTIGING- EN VERTEGENWOORDIGINGSVOORZIENING ........................................ 27 3.1.1. Doel, beschrijving en voortgang van de GMV ............................................................................................ 27 3.1.2. Het GMV proces.......................................................................................................................................... 28 3.1.3. Organisatie op het GMV project................................................................................................................. 30 3.2. MODERNISERING GEMEENTELIJKE BASISADMINISTRATIE (MGBA)................................................................ 30 3.2.1. Doel, beschrijving en voortgang mGBA ..................................................................................................... 30 3.2.2. Organisatie op het mGBA programma ....................................................................................................... 33 3.2.3. Omgeving mGBA programma..................................................................................................................... 34 4. BEVINDINGEN EN ANALYSE VAN HET PRAKTIJKONDERZOEK ................................................. 35 4.1. GATEWAY REVIEW METHODE ......................................................................................................................... 35 4.1.1. Onafhankelijkheid ....................................................................................................................................... 35 4.1.2. Vertrouwelijkheid........................................................................................................................................ 36 4.1.3. Gateway Review en project auditing........................................................................................................... 38 4.1.4. Andere aspecten met betrekking tot de Gateway Review methode.............................................................. 38 4.2. BEHEERSING OP HET GMV PROGRAMMA IN RELATIE TOT DE GATEWAY REVIEW METHODE .......................... 42 4.3. DE GATEWAY REVIEW METHODE BIJ HET MGBA PROGRAMMA ..................................................................... 44 5. CONCLUSIE EN AANBEVELINGEN ........................................................................................................ 47 5.1. CONCLUSIE ..................................................................................................................................................... 47 5.2. VERBETERPUNTEN EN AANBEVELINGEN......................................................................................................... 49 LITERATUUR .................................................................................................................................................... 52 GEÏNTERVIEWDEN......................................................................................................................................... 54 3

BIJLAGEN .......................................................................................................................................................... 55 Bijlage 1. Voorbeeld van een aanbeveling met bijbehorende classificatie bij Gateway Review 0........................ 55 Bijlage 2. De ontwikkeling van de Gateway Review methode in Engeland .......................................................... 55 Bijlage 3. Beschrijving van de eisen aan reviews volgens het rapportage model grote ICT projecten ................ 56 Bijlage 4. Uitgangspunten die gelden bij de Gateway Review methode ............................................................... 57 Bijlage 5. Voorbeeld van een doelstelling van een Gateway Review 0 ................................................................. 58 Bijlage 6. Voorbeeld van vragen waarop het reviewteam antwoord dient te geven met het daarbij behorende verwachte bewijsmateriaal.................................................................................................................................... 58 Bijlage 7. Onderwerpen welke een business case moet bevatten .......................................................................... 58 Bijlage 8. Onderwerpen waarover het reviewteam bij Gateway Review 1 zekerheid wil verkrijgen.................... 58 Bijlage 9. Onderwerpen waarover het reviewteam bij Gateway Review 2 zekerheid wil verkrijgen.................... 59 Bijlage 10. Onderwerpen waarover het reviewteam bij Gateway Review 3 zekerheid wil verkrijgen.................. 59 Bijlage 11. Onderwerpen waarover het reviewteam bij Gateway Review 4 zekerheid wil verkrijgen.................. 60 Bijlage 12. Werkzaamheden die het reviewteam bij Gateway Review 5 uitvoert.................................................. 61 Bijlage 13. Afkortingenlijst ................................................................................................................................... 61

4

1. Inleiding 1.1. Inleiding Als onderdeel van de Postgraduate IT Audit Opleiding aan de Vrije Universiteit Amsterdam (Faculteit der Economische Wetenschappen en Bedrijfskunde) ligt voor u mijn scriptie over een onderwerp binnen IT auditing. Mijn zoektocht naar een boeiend onderwerp heeft me gebracht bij IT programma’s die de overheid ontwerpt, ontwikkelt en realiseert ten behoeve van andere overheidsonderdelen en burgers. Het ontwikkelen en realiseren van programma’s heeft de overheid grotendeels ondergebracht bij het ICTU (ICT uitvoeringsorganisatie), een stichting die opgericht is door het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (hierna: BZK) en de Vereniging van Nederlandse Gemeenten (hierna: VNG). Het ICTU voert uitsluitend opdrachten voor overheden uit.

IT projecten van de overheid trekken vaak media aandacht omdat er grote fouten in de projecten of in de opgeleverde producten zitten, overschrijdingen op de gecalculeerde kosten plaatsvinden of omdat een project stopt aangezien de kans op succes niet meer aanwezig is. Belangrijke en interessante aspecten die vaak bij overheidsprogramma’s naar voren komen zijn: de beheersing van de kosten, de tijdigheid van het opleveren van het project en de mate waarin de beoogde projectresultaten kunnen worden behaald. Opdrachtgevers hebben zekerheid nodig omtrent vorengenoemde punten, om een project goed te kunnen laten verlopen.

1.2. Falende ICT-projecten bij de overheid Gedeeltelijk of geheel mislukte ICT-projecten bij de overheid vormen aanleiding voor de keuze van het scriptieonderwerp. Het is onwaarschijnlijk dat de, later in deze scriptie te beschrijven, Gateway Review methode zijn intrede in Nederland zou hebben gedaan wanneer het overgrote deel van de overheids ITprojecten een succesvol verloop zou kennen.

Uit publicaties blijkt dat geheel of gedeeltelijk mislukte overheidsprojecten jaarlijks een beslag leggen op de overheidsmiddelen1 van € 4 tot € 5 miljard2. Dit is meer dan 50%3 van alle ICT-projecten binnen de overheid. Bij het mislukken van ICT-projecten binnen de overheid plaats ik twee kanttekeningen. Allereerst blijkt dat niet alleen ICT-projecten binnen de overheid problemen hebben om te komen tot de gewenste resultaten. Ook ander projecten van de overheid kennen dit probleem. De infrastructurele projecten van de overheid, zoals de Betuwelijn, zijn hiervan een sprekend voorbeeld. Een tweede kanttekening betreft het feit dat de overheid met betrekking tot de problemen rond ICT-projecten niet afwijkend is van grote

1 Hierbij dient opgemerkt te worden dat het verlies op ICT projecten een schatting is waarbij slagingspercentages van ICT-projecten uit een Amerikaanse enquête zijn losgelaten op de totale ICT uitgaven in Nederland in 2004. 2 Zie voor een nadere onderbouwing: Dekker, 2007a en 2007b. 3 Zoals uit, lessen uit ICT-projecten bij de overheid, Deel a van 29 november 207 van de Algemene rekenkamer (bladzijde 8 en 9) blijkt, zijn er diverse onderzoeken gedaan naar het percentage van (gedeeltelijk) mislukte overheidsprojecten. Deze onderzoeken kenmerken zich door de grote afwijkingen die ze ten opzichte van elkaar vertonen. Dit komt door de onderzoekssystematiek en de definities die gebruikt worden. Alle onderzoeken geven wel aan dat meer dan 50% van de overheids ICT-projecten (gedeeltelijk) mislukken.

5

ondernemingen. Alleen kunnen mislukte ICT-projecten van de overheid zich verheugen op grotere aandacht van politiek en media.

Om een indruk te krijgen waaraan te denken valt bij falende ICT-projecten, behandelt deze paragraaf voorbeelden van ICT-projecten die geheel of gedeeltelijke mislukken. Bij de projecten Wet administratieve lastenverlichting en vereenvoudiging in sociale verzekeringswetten (hierna: Walvis), Samenwerking UWV (Uitvoeringsinstituut Werknemersverzekeringen) en Belastingdienst (hierna: SUB), het project toeslagen van de Belastingdienst en het Modernisering Gemeentelijke Basisadministratie (hierna: mGBA) programma is sprake van het geheel of gedeeltelijk mislukken van het project of programma. Om een indruk van de problemen rond de vorengenoemde ICT-projecten te verkrijgen, vergelijk ik bij deze projecten de geplande met de daadwerkelijke realisatiedatum van de projecten en de begrote met de daadwerkelijke projectkosten (wanneer de daadwerkelijke projectkosten nog niet bekend zijn, wordt de aangepaste raming van de projectkosten gebruikt voor de vergelijking). Met betrekking tot het vergelijken van de begrote met de daadwerkelijke projectkosten gaat deze scriptie niet nader in op de diversiteit4 van oorzaken die ten grondslag liggen aan de overschrijding van de begrote projectkosten.

Walvis en SUB zijn projecten waarmee de Belastingdienst en het UWV beogen om de heffing en inning van werknemersverzekeringen over te hevelen van het UWV naar de Belastingdienst. Als onderdeel van de overheveling krijgt het UWV de verantwoordelijk voor de polisadministratie. Binnen het Walvis project is ten behoeve van de samenwerking tussen Belastingdienst en het UWV het polisadministratie systeem gebouwd. Voor het heffen, innen en het verzamelen en registreren van werknemersgegevens voor het doen van uitkeringen (het SUB project) zou de Belastingdienst een nieuw systeem bouwen. De geplande realisatiedatum van WALVIS en SUB was 1 januari 2006, thans is nog niet bekend wat bij beide projecten de daadwerkelijke realisatiedata zullen zijn. Ten opzichte van de begroting heeft er op het SUB project een grote overschrijding plaatsgevonden (oorspronkelijk begroot voor € 129 miljoen versus een bijgestelde raming van € 202 miljoen). Het Walvis project ligt wat betreft geraamde kosten op schema (oorspronkelijk begroot op € 360 miljoen en bijgesteld tot € 367 miljoen aan kosten). Binnen de totale geraamde kosten van het Walvis project (€ 360 miljoen) is er een geschatte meevaller op het te realiseren sociaal plan van € 62 miljoen. Deze meevaller is teniet gedaan doordat de geschatte ICT kosten ten opzichte van de oorspronkelijk begrote ICT kosten zijn gestegen met € 54 miljoen.

Het project toeslagen vindt zijn oorsprong in de per 1 januari 2006 inwerking getreden Algemene wet inkomensafhankelijke regelingen. Deze wet belegt de verantwoordelijkheid voor de uitvoering van onder andere de huur- en zorgtoeslag bij de Belastingdienst. Om deze verantwoordelijkheid in te vullen heeft de Belastingdienst het ICT systeem voor huur- en zorgtoeslagen gebouwd over de jaren 2003 tot en met 2007. De geplande opleverdatum van het project toeslagen was 1 januari 2007. Op 8 juni 2007, voordat het oorspronkelijke project toeslagen was afgerond, heeft de Belastingdienst besloten om het gebouwde toeslagen systeem te gaan vervangen per 1 januari 2009. Dit omdat de Belastingdienst het gebouwde systeem onvoldoende stabiel vond en omdat een zwak punt in het systeem slechts tegen zeer hoge kosten te verhelpen was. Het programma toeslagen was gebudgetteerd op een bedrag van € 77 miljoen,

4 Hierbij valt onder meer te denken aan ondeugdelijke ramingen en veranderde wensen van de opdrachtgever gedurende de ontwikkeling van het project.

6

rekeninghoudend met de kosten van het nieuwe project toeslagen is het totaal aan kosten voor toeslagen nu geraamd op € 275 miljoen (waarbij er tot en met 2007 € 219 miljoen besteed is aan het project). Ultimo 2009 blijkt het project nog niet afgerond te zijn en is de verwachting dat de Belastingdienst het nieuwe toeslagen systeem op zijn vroegst per 2011 gaat gebruiken.

Een programma waaraan deze scriptie nader aandacht besteed, mGBA, kent ook perikelen als het gaat om het behalen van de planning en om binnen de begroting te blijven. Het oorspronkelijke budget voor mGBA, van € 14 miljoen, is gedurende de uitvoering van het programma diverse malen bijgesteld tot een budget van € 34,5 miljoen. Hierna is het project voor herbezinning stopgezet, waarna het vervolgens weer is opgestart met een begroting van ongeveer € 67 miljoen. De datum waarop mGBA in eerste opzet gerealiseerd zou moeten zijn is 2010. Voorzover nu bekend, verwachten de betrokken partijen dat het weer opgestarte programma in 2015 geheel zal zijn afgerond.

Eén van de, ten behoeve van het praktijkonderzoek, geïnterviewde personen benadrukte dat er ten onrechte gesproken wordt over ICT-projecten. Er is eerder sprake van verandertrajecten, waarbij ICT een belangrijke rol speelt. SUB en Walvis zijn voorbeelden van dergelijke verandertrajecten. In eerste instantie lijkt het bij Walvis en SUB alleen maar om ICT te gaan, terwijl daarbij vergeten wordt dat UWV en de Belastingdienst elkaar eerst moesten leren kennen om vervolgens goed te kunnen samenwerken om te komen tot een andere manier van werken.

Falende ICT-projecten kennen meer dan één oorzaak. Aan de hand van de uitingen van onder meer de Algemene Rekenkamer, het Office of Government Commerce5 (hierna: OGC) en de voor het praktijkonderzoek geïnterviewde personen ga ik nader in op de oorzaken waardoor ICT-projecten binnen de overheid falen. Geenszins tracht ik uitputtend te zijn bij de onderstaande beschrijvingen van oorzaken van project falen. Het aantal oorzaken van project falen is daarvoor te groot, wel is het de bedoeling om de meest prominente en in het oogspringende redenen van project falen te noemen.

Door een combinatie van politieke, organisatorische en technische factoren zijn ICT-projecten binnen de overheid, volgens de Algemene Rekenkamer, vaak te complex en te ambitieus, hetgeen een oorzaak vormt voor het mislukken van ICT-projecten6. De partijen die van invloed zijn op de politieke, organisatorische en technische factoren, te weten: Ministers, Tweede Kamer en ICT-dienstverleners hebben daarbij ieder hun eigen belang die uitmondt in de afweging die ze maken. Politici willen daadkrachtig overkomen en denken deze daadkracht te kunnen uitdragen door zich te verbinden aan grote ICT-projecten en het daarbij stellen van krappe deadlines. Uit een heel andere overweging hebben ICT-dienstverleners baat bij grote ICTprojecten. Grote ICT-projecten betekent immers werk en bestaanszekerheid voor de ICT-dienstverlener. Wat opvalt is, dat de partijen ieder een eigen afweging maken, echter de uitkomst hetzelfde is, een groot ambitieus en complex ICT-project. Daar waar partijen elkaar zouden moeten remmen in het aangaan van grote, complexe en ambitieuze ICT-projecten, zullen politici en ICT-dienstverleners elkaar alleen maar stimuleren om te komen tot (te) grote, complexe en ambitieuze ICT-projecten.

5 Het ontstaan en de werkzaamheden van het Office of Government Commerce worden nader uiteengezet in bijlage 2 van deze scriptie. 6 Algemene Rekenkamer, lessen uit ICT-projecten bij de overheid, Deel A, 29 november 2007.

7

Als andere concrete oorzaken voor het falen van ICT-projecten binnen de overheid noemt de Algemene Rekenkamer: •

Dat veel hoge ambtenaren en politici geloven in ICT als wondermiddel voor allerlei beleidsvraagstukken;

•

Dat deadlines niet worden vastgesteld op basis van deugdelijke onderbouwingen maar op basis van politieke overwegingen;

•

Het gebrek aan voldoende zicht bij bestuurders op de mogelijkheden en onmogelijkheden van ICT;

•

Dat projecten vaak van start gaan zonder goede onderbouwing, waarbij niet voldoende tijd genomen wordt om te kijken of een project realistisch is;

•

Dat vaak beslissingen binnen projecten genomen worden zonder dat er een voldoende en volledige onderbouwing is.

Redenen waarom projecten niet alleen falen, maar waardoor tevens behoorlijke schade ontstaat zijn onder meer te vinden in de politieke onwenselijkheid om een project te heroverwegen. Ondanks dat er geen zakelijke rechtvaardiging meer is, kiest een overheidsopdrachtgever niet snel voor het stopzetten van lopende ICT-projecten. Dit mede door het ontbreken van een deugdelijke exit-strategie. Naast bovenstaande redenen waarom ICT-projecten binnen de overheid falen, onderkent de Algemene Rekenkamer dat de informatievoorziening met betrekking tot de uitvoering van ICT-projecten een probleem is. Opdrachtgevers krijgen niet altijd de (volledige) informatie die zij nodig hebben om te kunnen beoordelen wat de voortgang en problematiek rond ICT-projecten is. Oorzaken van project falen zoals het OGC deze onderkent, betreffen7: •

Gebrek aan duidelijke relaties tussen opdrachtgever en het project als het gaat om strategische prioriteiten;

•

Gebrek aan helder management, opdrachtgeverschap en leiderschap;

•

Gebrek aan zichtbare effectieve betrokkenheid van de belanghebbenden;

•

Gebrek aan vaardigheden en aantoonbare kwaliteiten in projectmanagement en risk management;

•

Te weinig aandacht om een project op te delen in stappen welke goed te managen zijn;

•

Het beoordelen van voorstellen op basis van de te betalen prijs, in plaats van te kijken naar de langer termijn opbrengst van een voorstel;

•

Gebrek aan inzicht en contact met de aanbiedende dienstverlenende organisaties (op managementniveau).

Uit de ten behoeve van hoofdstuk 4 van deze scriptie uitgevoerde interviews kwamen diverse redenen van project falen naar voren. Ten eerste wijzigen de wensen van de opdrachtgevers vaak. Aan een oorspronkelijk project voegen betrokken partijen gedurende de rit steeds meer wensen toe, wat de realisatie van het project bemoeilijkt. Een ander valkuil zijn de technisch specialisten, die soms te snel ja zeggen op de vraag of ze iets kunnen realiseren. Tevens noemt een aantal geïnterviewden het gebrek aan concurrentie als reden voor project falen. Veel van de programma’s lopen via het ICTU en op sommige IT gebieden zijn het aantal specialisten zo schaars dat er automatisch weinig concurrentie is.

7 Ontleend aan OGC Best Practice, Common Causes of Project Failure, bladzijde 2.

8

Dat wijzigingen in de op te leveren producten voor een project een basis kunnen vormen voor project falen wordt ook in de literatuur8 onderkend. Draagvlak voor het op te leveren resultaat vindt de Rijksoverheid van groot belang. Om draagvlak te creëren mogen belanghebbenden veelal extra functionaliteit toevoegen aan het oorspronkelijk beoogde projectresultaat. Hiermee verdwijnt de beoogde doelstelling van het project naar de achtergrond en zorgt het verkrijgen van draagvlak er voor dat de doelstellingen niet worden gehaald.

1.3. Het antwoord op de problematiek rond ‘Falende ICT projecten bij de overheid’ Het toevoegen van zekerheid aan ICT overheidsprogramma’s en projecten staat aan de basis van mijn scriptie. Van oudsher verkrijgt de opdrachtgever zekerheid over een project door een audit te laten uitvoeren. Het gereedschap waarmee de opdrachtgever zekerheid verkrijgt bij projecten bereidt zich steeds verder uit. Tegenwoordig ontlenen opdrachtgevers ook zekerheid aan adviezen, contra-expertises en reviews. Bij een advies gaat het erom, om de opdrachtgever te helpen bij zijn zoektocht naar wat hij moet doen. Hierbij helpt het advies de opdrachtgever bij de door hem te maken keuzes en afwegingen. Voor de opdrachtgever is een advies van invloed op het toekomstig handelen. Ten aanzien van de personen die adviezen geven is het van belang dat zij onpartijdig en onafhankelijk zijn. Wanneer de opdrachtgever kiest voor een audit, houdt dit meestal in dat hij zekerheid verkrijgt over tekortkomingen die zich al hebben voorgedaan, maar er kunnen ook aanpassingen plaatsvinden in het project voor de toekomst, op basis van de geconstateerde risico’s. Een contra-expertise ziet op de toetsing van een al uitgebracht auditrapport of advies. De toetsing geschiedt door een onafhankelijke en onpartijdige deskundige. De contra-expertise geeft toegevoegde zekerheid aan de zekerheid die de opdrachtgever al heeft, op grond van het uitgebrachte auditrapport of advies. Van een review, of te wel ‘opnieuw kijken’, is sprake als de opdrachtgever op van belang zijnde besluitvormingsmomenten een toetsing laat uitvoeren. Dit om snel te kunnen bijsturen, wanneer dit nodig is9. Reviews kunnen worden uitgevoerd door externe adviseurs, welke ervaren en deskundig zijn. Ook is het mogelijk dat interne collega’s reviews uitvoeren.

Met betrekking tot de mogelijkheden waaraan een opdrachtgever zekerheid kan ontlenen, heb ik ervoor gekozen om een relatief nieuwe review methode, de Gateway Review methode van het OGC, nader te beschouwen. Deze review methode is, vanwege het grote succes van de methode, in 2006 naar Nederland overgewaaid. De Gateway Review methode licht een IT programma door op belangrijke beslismomenten. Deze doorlichting gebeurt door een onafhankelijk team van ervaren mensen, werkzaam op het niveau van de opdrachtgever. Gedurende de looptijd van een IT programma kunnen verschillende Gateway Reviews worden uitgevoerd. Welke Gateway Review aan de orde is hangt af van de fase waarin een IT programma zich bevindt. In totaal zijn er 6, verschillende Gateway Reviews te onderscheiden, te weten: •

Strategische beoordeling (Gateway 0);

•

Zakelijke rechtvaardiging (Gateway 1);

8 Zie voor een uitgebreide beschrijving: Geld verspilling bij ICT projecten van de overheid door gebrek aan doelgerichtheid, Pieter Gremmen, Twynstra Gudde. 9 Voor meer informatie over de verschillende soorten zekerheden (audits, adviezen, contra-expertises en reviews) verwijs ik naar ‘Voor alle zekerheid, Over adviezen, audits en contra-expertises: een gids voor ICT-opdrachtgevers in de publieke sector’ een papernote van HEC.

9

•

Verwerving- cq. veranderstrategie (Gateway 2);

•

Investeringsbeslissing (Gateway 3);

•

Gereedheid voor dienstverlening (Gateway 4);

•

Evaluatie van de behaalde resultaten (Gateway 5).

In hoofdstuk 2 van deze scriptie ga ik uitvoerig in op de Gateway Review methode. Daarbij besteed ik allereerst aandacht aan het doel en de inhoud van de methode (paragraaf 2.1.). Dit geef ik een vervolg met de beschrijving van de ontwikkeling van de methode en uitgangspunten van methode (paragraaf 2.2.). Daarna ga ik inhoudelijk in op de Gateway Review methode (paragraaf 2.3.1. tot en met 2.3.6.). Ik heb gekozen voor een uitgebreide beschrijving van de Gateway Review methode om in het vervolg van de scriptie een goede koppeling te kunnen leggen tussen de onderzochte projecten en de programma’s enerzijds en de Gateway Review methode anderzijds. Tevens vormt de uitvoerige inhoudelijke beschrijving van de Gateway Review methode het fundament voor de conclusie van hoofdstuk 2 (paragraaf 2.4.). In deze conclusie ga ik nader in op verschillen en overeenkomsten tussen de Gateway Review methode en de reguliere audit (paragraaf 2.4.1.). Ook beschrijf ik in de conclusie de voor- en nadelen van de Gateway Review methode (paragraaf 2.4.2.), zoals genoemd in de literatuur.

Hoofdstuk 3 gaat nader in op het programma Gemeenschappelijke Machtigings- en Vertegenwoordigingsvoorziening10 (hierna: GMV). Het GMV programma is bedoeld om een elektronische voorziening te bieden waarmee een burger machtigingen, voor het per internet laten verrichten van rechtshandelingen met de overheid, kan registreren en onderhouden. Het GMV programma is een programma waarop geen Gateway Review heeft plaatsgevonden. Een tweede onderwerp welke ik in hoofdstuk 3 behandel, is het mGBA programma. Met het mGBA programma beoogt BZK de Gemeentelijke Basisadministratie persoonsgegevens (hierna: GBA) te moderniseren. De keuze om mGBA in deze scriptie nader te belichten heeft twee redenen. Ten eerste is de Gateway Review methode toegepast op het mGBA programma. Maar misschien nog wel een belangrijker reden vormt de openheid die BZK betracht bij het beschikbaar stellen van projectdocumentatie van het mGBA programma op internet.

Aan de hand van een synthese van de gehouden interviews geef ik in hoofdstuk 4 de mogelijke effecten van de Gateway Review methode op het GMV programma weer, wanneer de methode toegepast zou zijn op het GMV programma (paragraaf 4.2.). Hierbij probeer ik met behulp van interviews een indruk te krijgen of de Gateway Review methode een bijdrage had kunnen leveren aan het programma. Daarna bekijk ik met behulp van interviews en projectdocumentatie de invloed van de Gateway Review methode op het mGBA programma (paragraaf 4.3.). Naast het verband dat ik leg tussen de Gateway Review methode en de twee programma’s, geef ik in hoofdstuk 4 met behulp van de uitkomsten van de interviews een kritische beschouwing van de Gateway Review methode (paragraven 4.1.1. en 4.1.2.). Onderwerpen als de onafhankelijkheid en de vertrouwelijkheid van de Gateway Review methode behandel ik hierbij.

10 De naamgeving is gedurende het schrijven van deze scriptie verandert van Gemeenschappelijke Machtigings- en Vertegenwoordigingsvoorziening in Digimachtiging.

10

In hoofdstuk 4 kom ik tevens terug op de relatie tussen de Gateway Review methode en de reguliere audit (paragraaf 4.1.3.). Dit doe ik aan de hand van wat de geïnterviewden verteld hebben over het onderwerp.

1.4. Centrale vraagstelling In het hoofdstuk ‘Conclusie en Aanbevelingen’, hoofdstuk 5 van deze scriptie, beantwoord ik de volgende hoofdvraag: Verschaft de Gateway Review methode, vanuit de optiek van IT auditing11, voldoende zekerheden aan de opdrachtgever bij het realiseren van grootschalige complexe IT projecten?

Vragen die tevens in hoofdstuk 5 en de daaraan voorafgaande hoofdstukken aanbod komen zijn: 1.

Wat houdt de Gateway Review methode in als instrument van IT project auditing12?

2.

Wat is de betekenis van het GMV programma voor het informatiebeleid van de publieke sector?

3.

Wat is de betekenis van het mGBA programma voor de informatievoorziening van de overheid en de burger?

4.

Welke verbeterpunten zijn er te onderkennen bij de praktische toepassing van de Gateway Review methode ten behoeve van het verschaffen van zekerheden?

Tevens geef ik aanbevelingen die voortkomen uit het gedane onderzoek. Daarbij beperk ik me niet enkel en alleen tot de aanbevelingen die voortkomen uit de relatie tussen de Gateway Review methode en programma’s en projecten. Voorzover het naar voren komt in mijn onderzoek, geef ik ook aanbevelingen op het bredere gebied van programma- en projectbeheersing.

1.5. Methodologie en onderzoekaanpak De onderzoeksaanpak die ten grondslag ligt aan deze scriptie bestaat uit twee elementen, te weten een literatuurstudie welke zijn weerslag vindt in de hoofdstukken 2 en 3 en het veldonderzoek. Dit veldonderzoek, dat voornamelijk bestaan heeft uit het houden van interviews met behulp van gestructureerde vragenlijsten en uit het doornemen van projectdocumentatie, is verwoord in hoofdstuk 4 van deze scriptie. De interviews zijn uitgevoerd gedurende de maanden juli 2009 tot en met januari 2010. Met betrekking tot de gehouden interviews is er met de geïnterviewden een hoor en wederhoor procedure toegepast13.

1.6. Leeswijzer Om de leesbaarheid van deze scriptie te bevorderen is er voor gekozen om onderdelen van de scriptie onder te brengen in de bijlagen van deze scriptie. Voor het complete beeld van de Gateway Review methode raad ik de lezer aan om, daar waar ik in de scriptie verwijs naar een bijlage, deze bijlage in samenhang te lezen met het stuk dat verwijst naar de bijlage. Ter verhoging van het leesgemak is als bijlage (bijlage 13) ook een lijst met gehanteerde afkortingen opgenomen.

11 Onder IT-auditing wordt in dit kader verstaan “het beoordelen van, dan wel adviseren over één of meer kwaliteitsaspecten van (onderdelen van) de informatie omgeving waar wordt gebruikgemaakt van informatietechnologie”. Overgenomen uit Grondslagen IT-auditing, bladzijde 81. 12 Onder (IT) project auditing wordt in het kader van deze scriptie verstaan: het beoordelen van waarborgen die ervoor moeten zorgen dat de doelstellingen van een project bereikt worden. 13 De procedure is van toepassing geweest op alle geïnterviewden met uitzondering van de heer P. Frijns (Kwartiermaker Rijksbrede Vernieuwingen). Omdat dit interview zeer laat in de onderzoeksfase plaatsgevonden heeft, was het niet mogelijk om de conceptscriptie aan de heer Frijns voor te leggen voor commentaar.

11

2. Gateway Review methode Dit hoofdstuk behandelt ondermeer de eerste deelvraag, zoals gesteld in paragraaf 1.4. van deze scriptie, namelijk: Wat houdt de Gateway Review methode in als instrument van IT project auditing? Hoofdstuk 2 is vervaardigd op basis van een uitgebreide literatuur studie. Allereerst beschrijft paragraaf 2.1. het doel en de inhoud van de Gateway Review methode. Paragraaf 2.2. besteed aandacht aan de ontwikkeling en de uitgangspunten van de Gateway Review methode. De ontwikkelingen van de methode worden benaderd vanuit het Nederlands perspectief (paragraaf 2.2.1.). Uitgangspunten van de Gateway Review methode zijn vastgelegd door OGC en in deze scriptie toegelicht in paragraaf 2.2.2. Vanuit de OGC best practice handboeken vindt er in paragraaf 2.3. een beschrijving plaats van de diverse Gateway Reviews. Afsluitend worden er, op basis van de voorgaande paragrafen, in paragraaf 2.4. conclusies getrokken.

2.1. Doel en inhoud van de Gateway Review methode Bij de Gateway Review methode vindt er op een aantal sleutelmomenten van een (ICT) project een review plaats door een team van 3 á 4 ervaren deskundigen. Deze deskundigen zijn onafhankelijk van het projectteam, dat bezig is met de uitvoering van het project. Een dergelijke review valt ook aan te duiden als een peer review, of te wel collegiale toetsing. De bedoeling van de review is om zekerheid te verkrijgen of het project gereed is om naar de volgende fase te gaan. Hierbij ligt het voor de hand dat het reviewteam aanbevelingen geeft, die kunnen leiden tot een verbetering van het project.

Een Gateway Review voert een reviewteam uit in opdracht van de opdrachtgever, of te wel de Senior Responsible Owner (hierna: SRO). Alvorens over te gaan tot de uitvoering van een Gateway Review, maakt de SRO eerste een risicoanalyse. Om deze risicoanalyse te objectiveren heeft OGC een ‘Risk Potential Assessment’ model ontworpen. Bij het ‘Risk Potential Assessment’ model moet de SRO vragen beantwoorden over het project. Iedere vraag uit het ‘Risk Potential Assessment’ model biedt de SRO de mogelijkheid om te kiezen tussen twee of meer antwoorden. De gegeven antwoorden koppelt het ‘Risk Potential Assessment’ model vervolgens aan wegingsfactoren. Wanneer de SRO de ‘Risk Potential Assessment’ model invult, bepaalt de som van de wegingsfactoren het risiconiveau van het ICT-project. Aan de hand van het risiconiveau mag of de Gateway-organisatie of de voor het project verantwoordelijke overheidsinstelling het Gateway reviewteam samenstellen14. Projecten met een hoog risico, welke meestal groot, complex en ‘Mission Critical’ zijn, krijgen een review teamleider toegewezen van Gatewayorganisatie. Teamleden, die onderleiding van de teamleider de review uitvoeren, zijn onafhankelijk van de overheidsorganisatie onder wiens verantwoordelijkheid het ICT-project wordt uitgevoerd. Dit verschilt van een project met een gemiddeld risico. Bij een dergelijk project stelt OGC weliswaar de teamleider aan, de andere leden van het reviewteam mogen onafhankelijke stafmedewerkers zijn van de verantwoordelijke overheidsorganisatie zelf. Het OGC gaat bij het samenstellen van het reviewteam voorbij aan de (theoretische) vraag in hoeverre zij stafmedewerkers van een verantwoordelijk ministerie als onafhankelijk kan bestempelen. Op zijn minst zijn de stafmedewerkers van het verantwoordelijke ministerie financieel afhankelijk van het ministerie. Wanneer de SRO het risico over een ICT-project als laag kwalificeert, dan

14 Volledigheidshalve merk ik hierbij op dat dit een beschrijving is van de Engelse werkwijze.

12

kan de voor het project verantwoordelijke overheidsorganisatie zelf de leden van het reviewteam aanwijzen, inclusief de teamleider.

In het kader van het al omvattende doel van de SRO om zijn zakelijke doelen te halen, beoogt de Gateway Review methode hieraan bij te dragen door15: •

de best beschikbare vaardigheden en ervaring aan het project te koppelen;

•

te zorgen dat alle belanghebbenden bij het project op de hoogte zijn van de status van het project;

•

zekerheid te verstrekken dat het project met succes kan beginnen aan de volgende projectfase;

•

ervaring en vaardigheden van het reviewteam te vergroten door deelname van de teamleden aan andere reviewteams en kennis uit te wisselen met anderen die reviews uitvoeren en;

•

het adviseren en begeleiden van projectteams16.

Een uitgevoerde Gateway Review resulteert in een status17 die aangeeft of een project geschikt is om verder te gaan naar de volgde projectfase. Er is er bij de Gateway Review methode gekozen om de status aan te geven door middel van de kleur symbolen van een verkeerslicht. Wanneer het reviewteam tijdens de review bij een bepaalde Gate tot de conclusie komt dat de beoordeelde projectfase succesvol is afgerond dan geeft zij “groen” licht om door te gaan naar de volgende projectfase. Indien de projectorganisatie verantwoord kan doorgaan met het project naar de volgende projectfase, maar er wel risico’s te onderkennen zijn waarop de projectorganisatie moet letten om geen bedreiging te gaan vormen voor het succesvol doorlopen en afronden van het project, dan geeft het reviewteam dit aan met een ‘oranje/groen‘ status. Wanneer een Gateway Review team een project als ‘oranje’ kwalificeert, betekent dit dat succesvolle afronding van het project mogelijk is, met dien verstande dat er wel onderwerpen/problemen van materieel belang bestaan, welke in deze fase al aandacht van het management vragen. Op het moment van het constateren van de problemen, zijn de problemen nog wel oplosbaar binnen de budgettaire mogelijkheden van het project.

Er is sprake van een ‘oranje/rood’ status bij een Gateway Review wanneer er twijfels bestaan over risico’s en onderwerpen op sleutelgebieden binnen een project. Er is haast geboden om de problemen en onderwerpen te lijf te gaan die het Gateway Review team geconstateerd heeft. Tevens is het van belang dat de SRO vaststelt dat het project nog levensvatbaar is. Een code ‘rood’, is de meest negatieve kwalificatie welke een Gateway Review team geeft. Hiermee geeft zij aan dat ze van mening is dat het succesvol afronden van het project niet te verwachten is. Om het project weer levensvatbaar te maken, bij een code ‘rood’, zijn onmiddellijke acties geboden.

Naast het oordeel over een bepaalde Gate, doet het Gateway Review team ook aanbevelingen in haar rapport naar de SRO. Om het belang van een aanbeveling richting het projectteam te benadrukken voegt het reviewteam aan iedere aanbeveling van een kwalificatie toe. Het Gateway Review team werkt daarbij met drie standaard kwalificaties, te weten: kritiek, essentieel en tip. Genoemde kwalificaties sluiten aan bij

15 The Procurement Toolkit –Best Practice Guides, 16 Project Management & OGC Gateway Review, bladzijde 6. 16 De Nederlandse Gateway-organisatie, zo blijkt uit één van de gehouden interviews, wil in de toekomst de adviezen welke uit Gateway Reviews komen meer richten op het procedurele vlak. De adviezen moeten een bijdrage leveren om te komen tot een professionele project/programmaorganisatie. 17 OGC Gateway Process Review 5: Operations reviews & benefits realisation, version 4.0, june 2008.

13

de codes rood (kritiek), oranje (essentieel) en groen (tip) waarmee een reviewteam aangeeft of een project geschikt is om naar de volgende projectfase te gaan. Voor een voorbeeld van een advies dat een reviewteam gegeven heeft, verwijs ik naar bijlage 1 van deze scriptie. De Gateway Reviews: 0 ‘Strategische beoordeling’, 1 ‘Zakelijke rechtvaardiging’, 2 ‘Verwerving/veranderstrategie’, 3 ‘Investeringsbeslissing’, 4 ‘Gereedheid voor dienstverlening’ en 5 ‘Evaluatie van resultaten’ zijn als volgt binnen projecten te plaatsen18:

18 Dit model is overgenomen uit de HEC flyer: Het OGC Gateway proces, Gateway reviews: De weg naar success, 2007.

14

2.2. Ontwikkeling en uitgangspunten van de Gateway Review methode 2.2.1. De ontwikkeling van de Gateway Review methode in Nederland Alvorens in te gaan op de ontwikkeling van de Gateway Review methode in Nederland, verwijs ik naar bijlage 2 van deze scriptie voor de ontstaansgeschiedenis van de Gateway Review methode in Engeland. In 2006 is Het Expertise Centrum19 (hierna: HEC) op eigen initiatief begonnen met de introductie van de Gateway Review methode in Nederland. Hiervoor is HEC gaan samenwerken met verschillende overheden zoals ministeries, uitvoeringsorganisaties en grote gemeenten. Tijdens een studiereis naar enkele ministeries in Londen in september 2006 is een verdere stap gezet in de introductie van de Gateway Review methode in Nederland. Genoemde studiereis organiseerde het Ministerie van Economische Zaken, welke hiervoor medewerkers van HEC, ICT-bedrijfsleven en IT spil medewerkers van diverse ministeries uitnodigde. Tijdens de studiereis spraken de partijen af dat er een standaardwijze van reviewen van ICTprojecten zou komen. Ook spraken partijen af om voor 1 november 2006 3 pilot-projecten te selecteren, om deze projecten vervolgens te onderwerpen aan de Gateway Review methode. Het gehele proces om de Gateway Review methode naar Nederland te halen kende binnen HEC als grote trekker Maarten Hillenaar20, die bij Pink Elephant werkte toen deze ITIL uit Engeland haalde.

De vrijwillige invoering van de Gateway Review methode, zoals door het HEC in 2006 in Nederland geïntroduceerd, is in een stroomversnelling gekomen door berichten over geheel of gedeeltelijk mislukte overheidsprojecten. Realistische ambities, grip op ICT-projecten en betere informatievoorziening kan de overheid bereiken door goede sturing op ICT-projecten. Hierbij is het van belang om de sturing op ICTprojecten op cruciale punten met extra waarborgen te omkleden. Dit is te bereiken door onafhankelijke collega’s mee te laten kijken met ICT-projecten. In dit kader past de Gateway Review methode als middel om te komen tot een betere sturing op ICT-projecten21.

Op grond van vorenstaande heeft de Minister van BZK besloten om een prominente rol toe te kennen aan de Gateway Review methode. Een en ander vindt zijn weerslag in een tweetal brieven22 van de Minister van BZK aan de Tweede Kamer. Allereerst geeft de Minister bij brief van 26 juni 2008 aan dat zij een Gatewayorganisatie gaat opzetten. In vervolg hierop heeft de Minister in haar brief van december 2008 kenbaar gemaakt dat de Gateway-organisatie haar diensten in 2009 gaat aanbieden aan ministeries. Daarnaast geeft de Minister in laatstgenoemde brief aan, dat ze in overleg is met de Britse overheid om de Gateway Review methode in Nederland formeel te adopteren23.

19 HEC is een stichting, welke opgericht is in 1988, die ten doel heeft het verbeteren van de organisatie en informatisering van de overheid. HEC voert contra expertises uit, begeleidt de overheid bij complexe projecten, adviseert de overheid en verzorgt opleidingen. 20 Maarten Hillenaar is per 1 januari 2009 benoemd tot directeur Informatiseringsbeleid Rijk en tevens Rijks CIO. 21 Zie ook Algemene Rekenkamer, lessen uit ICT-projecten bij de overheid, Deel B, 1 juli 2008, bladzijde 10. 22 Kamerstuk 2007-2008, 26643, nr. 128 en Kamerstuk 2008-2009, 26643, nr. 135 . 23 Op 28 januari 2010 heeft Bureau Gateway ( de Nederlandse Gateway-organisatie) een officiële licentie ontvangen voor één jaar van het OGC. Dit betekent dat Bureau-Gateway de Gateway Review methode nu mag gebruiken en doorontwikkelen binnen Nederland (www.vernieuwingrijksdienst.nl).

15

Naar aanleiding van de problemen bij grote ICT-projecten binnen het Rijk is op 27 maart 2008 de werkgroep ICT-projecten bij de overheid opgericht. De werkgroep, welke is samengesteld uit leden van de Tweede Kamer die deelnemen aan de vaste commissies voor Binnenlandse Zaken en Economische Zaken, heeft als opdracht gekregen om een onderzoeksvoorstel op te stellen naar aanleiding van de problematiek van ICT-projecten bij de overheid. Per juni 2009 heeft de commissie eindverslag uitgebracht. In het eindverslag24 doet de commissie de Minister van BZK de aanbeveling om over te gaan tot de verplichte toepassing van de Gateway Review systematiek bij grote ICT-projecten. In een reactie25 op het eindverslag verklaart de Minister van BZK met betrekking tot het verplicht stellen van de Gateway Review methodiek dat ze reviews bij grote ICT projecten van de overheid verplicht gaat stellen. Dit kunnen Gateway Reviews zijn, maar mogen ook ander vormen van reviews zijn. Als voorbeeld van een andere vorm van een review noemt de Minister de audit van een auditdienst. Van de uit te voeren review, eist de Minister wel dat deze voldoet aan de eisen zoals ze zijn vastgelegd in het rapportagemodel voor grote ICT projecten bij de overheid. Het heeft er de schijn van dat de Minister van BZK in haar reactie beoogd heeft om antwoord te geven op de vraag van de werkgroep ICT-projecten bij de overheid, die de werkgroep op 28 mei 2009 gesteld heeft. Schriftelijk vroeg de werkgroep aan de Minister van BZK: “Overigens is het onduidelijk wat het verschil in gebruik is van de Gateway-systematiek en de reviews door auditdiensten. Het lijkt er op dat het hier gaat om twee wezenlijk andere oordelen, respectievelijk een collegiale toets versus een oordeel van een auditdienst. Kunt u het verschil in deze reviewmethoden toelichten?” Nu de Minister van BZK duidelijk maakt dat zowel de Gateway Review methode als een audit van een auditdienst kan voldoen als reviewmethode, is het van belang om te kijken naar de eisen die zij stelt aan de review. Deze eisen zijn vastgelegd in het rapportage model26 dat geldt voor grote ICT-projecten27. Het rapportage model noemt vier reviews, te weten: 1. Review project start, 2. Review projectuitvoering en – voortgang, 3. Review realisatie en 4. Review evaluatie. Een gemeenschappelijk kenmerk van de 4 verschillende voorgeschreven reviews vormt de eis dat het reviewteam de review dient af te sluiten met een oordeel. Ook schrijft het rapportagemodel duidelijke toetspunten voor die de reviewers bij hun beoordeling dienen te gebruiken. Een meer uitgebreide uiteenzetting van de eisen waaraan een review volgens het rapportagemodel dient te voldoen, is terug te vinden in bijlage 3 van deze scriptie.

2.2.2. Uitgangspunten Gateway Review OGC heeft als ontwikkelaar van de Gateway Review methode een aantal uitgangspunten, zogenaamde ‘Brand Principles’, geformuleerd. Gebruikers van de methode dienen deze uitgangspunten in acht te nemen, wanneer zij een Gateway Review uitvoeren. Het werken met uitgangspunten is noodzakelijk om oneigenlijk gebruik van de kwalificatie Gateway Review te voorkomen. In eerste instantie zijn de uitgangspunten geschreven voor de Engelse situatie, waar OGC leidend is bij de Gateway Review

24 Zie voor het complete eindverslag van de werkgroep ICT-projecten binnen de overheid: parlis.nl/pdf/kamerstukken/KST133336.pdf. 25 Overgenomen uit brief van de Minister van Binnenlandse Zaken en Koninkrijksrelatie, Kamerstuk 2009-2010, 26643, nr. 144, 30 september 2009. 26 Voor een meer uitgebreide beschrijving van de criteria van het rapportage model verwijs ik naar: Rapportagemodel grote ICT-projecten, www.ikregeer.nl/document/BLG18302. 27 Ten tijde van het schrijven van deze scriptie, dat wil zeggen begin januari 2010, wordt er gewerkt aan een nieuwe versie van het rapportage model Grote ICT projecten. Dit model is nog niet openbaar en de Interdepartementale Commissie van Chief Information Officers moet dit model nog goedkeuren. Vandaar dat dit model nog niet verwerkt is in de scriptie. Wel is bekend dat het nieuwe rapportage model een stuk concreter gaat zijn.

16

methode. OGC staat overheden uit andere landen toe de Gateway Review methodiek te gebruiken, waarbij deze overheden de uitgangspunten moeten handhaven en respecteren. Hiertoe dienen de uitgangspunten vertaald te worden. In de Nederlandse situatie zal dit betekenen dat, daar waar in de uitgangspunten OGC genoemd wordt, in Nederland de opgerichte Gateway-organisatie in de uitgangspunten geïncorporeerd zal worden.

In totaal zijn er 14 uitgangspunten, die OGC verdeeld heeft in drie categorieën. De drie categorieën zijn: toewijding en leiderschap, verwerving en ‘Best Practice’ en stijl. In bijlage 4 van deze scriptie zijn de uitgangspunten van OGC nader uiteengezet.

In de paragrafen 2.3.1. tot en met 2.3.6. ga ik nader in op de diverse Gateway Reviews bij de verschillende Gate’s. Per Gateway Review kijk ik hierbij naar de doelen die de Gateway Review methode nastreeft, op welke manier deze doelen te bereiken zijn en in welke mate het bouwwerk van OGC specifiek ingaat op IT onderwerpen.

2.3. Beschrijving van de verschillende Gateway Reviews 2.3.1. Gateway 0: Strategische doorlichting Het grote verschil tussen Gateway Review 0 ‘Strategische doorlichting’ en de andere Gateway Reviews, is het feit dat Gateway Review 0 alleen van toepassing is op programma’s en niet op afzonderlijke projecten. Een programma valt te definiëren als28: “een verzameling van tijdelijke, samenhangende en dynamische doelen, inspanningen en middelen.” OCG29 definieert programma’s als: “programmes are about managing change, with a strategy vision and routemap of how to get there; they are able to deal with uncertainty about achieving the desired outcomes.” Een programma bestaat ondermeer uit subprogramma’s en projecten. Binnen de overheid vloeien programma’s voort uit beleid, welke vertaald wordt in strategische doelen. Programma’s kunnen zien op het maken en leveren van nieuwe diensten (zoals bijvoorbeeld de vele nieuwe geautomatiseerde diensten die de overheid aan haar burgers aanbiedt), de manier waarop een (overheids) organisatie werkt, het veranderen van de maatschappij door bepaalde ontwikkelingen op te starten en deelprojecten die worden ondergebracht in één programma30.

Binnen het strategisch doorlichten van een programma zijn een aantal doelen te onderkennen. Ten eerste dient de review vast te stellen dat de doelen en het op te leveren product bijdraagt aan de ‘overall’ strategie van het overheidsonderdeel waaronder het programma valt. In dit kader dient de review ook uitsluitsel te geven over de ondersteuning van andere betrokkenen aan het programma. Daarnaast zal het reviewteam moeten kijken in hoeverre een programma in een groter geheel is geplaatst. Dat wil zeggen hoe is de relatie tussen het programma en ander beleidsdoelen en programma’s binnen de overheid. Op het gebied van het managen en monitoren van een programma gaat de review in op de inrichting hiervan. Ten aanzien van de risico’s kijkt het reviewteam bij Gateway Review 0 hoe het programmamanagement het systeem heeft ingericht dat ziet op het identificeren en managen van programmarisico’s. Een ander belangrijk doel

28 Tak van der T, G, Wijnen, Programmamanagement Sturen op samenhang, Kluwer,2e druk, 2006, bladzijde 26. 29 Best Practice-Gateway to success, Review 0: strategic assessment, 2007, bladzijde 4. 30 OGC Best Practice-Gateway to success, Review 0: strategic assessment, 2007, bladzijde 8.

17

van de review vormt het vaststellen dat de opdrachtgever voldoende middelen toewijst aan het programma. Met betrekking tot dit facet richt het reviewteam zich op de financiering van het programma, wat voor ervaring en vaardigheden nodig zijn voor het programma en of deze ook daadwerkelijk zijn toegerekend aan het programma. Na de eerste review hebben de volgende Gateway Reviews 0 tevens het doel om de voortgang van het programma ten opzichte van de planning te beoordelen. In welke mate de in eerdere reviews afgegeven adviezen zijn opgevolgd binnen het programma, vormt ook een onderwerp van beoordeling door het reviewteam wanneer zij Gateway Review 0 herhaald. Dat de standaard doelen die Gateway Review 0 beoogt, in werkelijkheid niet altijd allemaal geraakt worden en mogelijk ook anders geformuleerd worden, blijk uit een reviewverslag van Gateway Review 0, met betrekking tot mGBA31. Het reviewverslag van mGBA maakt duidelijk dat er vrijheid bij de opdrachtgever bestaat, betreffende het formuleren van de doelstelling van de review. Voor de omschrijving van de doelstelling van Gateway Review 0 bij mGBA verwijs ik naar bijlage 5.

De vragen die voortkomen uit de geformuleerde doelen voor Gateway Review 0 zijn vertaald in een aantal standaard vragen binnen de Gateway Review methode. In het Gateway Review model zijn de doelen met de bijbehorende vragen gerubriceerd in zes hoofdcategorieën, te weten: beleid en bedrijfsomgeving, business case en belanghebbende, management en beoogde uitkomsten, risk management, beoordeling van de huidige stand van zake en gereedheid voor de volgende fase. In elk van de hoofdcategorieën staan vragen, die voortvloeien uit de genoemde doelen van de review, met het daarbij gewenste bewijsmateriaal (Een voorbeeld van laatst genoemde vragen en het daarbij gewenst bewijsmateriaal is opgenomen in bijlage 6 van deze scriptie). Om antwoord te kunnen geven op deze vragen houdt het Gateway Review team interviews en neemt zij kennis van de stukken die er met betrekking tot het programma zijn.

Het reviewteam verricht een Gateway Review 0 bij de start van een programma en vervolgens herhaalt een reviewteam Gateway Review 0 bij alle belangrijke afwegingspunten gedurende het programma en als laatste herhaalt een reviewteam Gateway Review 0 aan het eind van het programma.

2.3.2. Gateway 1: Zakelijke rechtvaardiging De Gateway Review met betrekking tot Gateway 1, ‘Zakelijke rechtvaardiging’, vindt plaats nadat de projectorganisatie een strategische ‘business case’ heeft opgesteld en voordat de business case ter goedkeuring is voorgelegd aan het orgaan dat moet beslissen of de ‘business case’ een vervolg krijgt met de uitwerking van een bepaald scenario. Een ‘business case’ beantwoordt de vraag waarom een project bestaansrecht heeft. Voor onderwerpen welke minimaal in een business case dienen te staan verwijs ik naar bijlage 7 van deze scriptie.

Bij de toetsing van de ‘business case’ aan de zakelijke rechtvaardiging beoogt het reviewteam zekerheid te verstrekken aan beslissingsbevoegden van het project over de mate waarin het voorgestelde project voldoet aan de zogenaamde ‘business requirements’. Ook is het de bedoeling bij Gateway Review 132 vast te stellen dat de uitkomsten van het project gedefinieerd zijn door de projectorganisatie, op een hoog abstractieniveau. Daarnaast stelt het reviewteam door middel van Gateway Review 1 vast of de

31 mGBA Rapport Gateway Review 0 – Strategisch Assessment, Versie nummer: Concept 0.96, Datum van oplevering aan SRO: 4 november 2008. 32 OGC Best Practice-Gateway to success, Review 1: Business justification, 2007, bladzijde 8.

18

projectorganisatie, om de voortgang in het bereiken van de projectuitkomsten te meten, gedefinieerde meetinstrumenten gaat gebruiken. De in hoofdlijnen beschreven doelen, zijn bij de Gateway Review methode vervolgens vertaald naar onderwerpen waarover het reviewteam zekerheid wil verkrijgen, deze onderwerpen33 zijn nader beschreven in bijlage 8 van deze scriptie.

Een onderscheid tussen de Gateway Review 0 en de andere Gateway Reviews vormt het feit dat de werkboeken van OGC vanaf Gateway Review 1 concreet, met vragen, ingegaan op IT aspecten. Zo vraagt OGC in het handboek over Gateway Review 1 aan het reviewteam om bewijs te verzamelen, waaruit naar voren komt dat IT gedreven projecten in compliance zijn met e-government frameworks en voldoen aan de vereisten op het gebied IT beveiliging en privacy regels. Ander bewijs dat specifiek ziet op IT gedreven projecten betreft het bewijs omtrent de transparantie en duidelijkheid van de projectdoelen en hoe deze projectdoelen te bereiken zijn. Met betrekking tot deze onderwerpen verwacht OGC bewijs waaruit blijkt dat de te ontwikkelen IT past binnen een breder programma van veranderingen ten behoeve van de burgers. Voor zogenaamde ‘mission-critical’ projecten geldt dat er vastleggingen moeten zijn over aan wie, welke verantwoordelijkheden zijn toegewezen voor de te realiseren IT. Op het gebied van risk management, besteed Gateway Review 1 specifiek aandacht aan IT gedreven projecten, door van dergelijke projecten opsommingen te verlangen van de informatie beveiligingsrisico’s, risico’s verband houdende met egovernment en risico’s van het niet of moeizaam van de grond komen van het IT project. Ook blijkt het essentieel te zijn dat de rollen en verantwoordelijkheden binnen de projectorganisatie duidelijk zijn. Voor IT gedreven projecten betekent dit, dat er een Chief Information Officer aanwezig moet zijn en een IT beveiligingsmanager welke de SRO ondersteunt.

2.3.3. Gateway 2: Verwerving- c.q. veranderstrategie Nadat de ‘business case’ ondermeer getoetst is op zijn robuustheid bij Gateway Review 1, gaat de projectorganisatie verder met het duidelijk definiëren van het project en het maken van een implementatieplan voor het project. Bij Gateway Review 2 kijkt het reviewteam34 naar de levensvatbaarheid van het project, de mogelijkheid dat het project een succes wordt, of de opdrachtgever ‘waarde voor geld’ krijgt en de mate waarin de projectorganisatie met de voorgestelde benadering de projectdoelen kan behalen. Om zekerheid aan de opdrachtgever te kunnen verstrekken of een project al dan niet klaar is voor de volgende projectfase35, dient het reviewteam antwoord te verkrijgen op een aantal vragen die voortvloeien uit de genoemde doelen van Gateway Review 2. Deze vragen zijn weergegeven in bijlage 9 van deze scriptie.

Het handboek van OGC over Gateway Review 2 gaat specifiek in op IT. Zo staat er in het handboek de vraag of de aanbestedingsopties geëvalueerd zijn. Hierbij zal het reviewteam voor IT gedreven projecten een afweging van de projectorganisatie moeten zien tussen aanbesteding voor zogenaamde bouwstenen en een aanbesteding die ziet op het project als geheel. Daar waar het gaat om het faciliteren van de communicatie en samenwerking tussen partijen vraagt OGC voor IT gedreven projecten bewijs waaruit blijkt dat de aanbieders die in de aanbestedingsprocedure op de shortlist staan een eigen ‘senior

33 OGC Best Practice-Gateway to success, Review 1: Business justification, 2007, bladzijde 7. 34 OGC Best Practice-Gateway to success, Review 2: delivery Strategy, 2007, bladzijde 8. 35 OGC Best Practice-Gateway to success, Review 2: delivery Strategy, 2007, bladzijde 7.

19

responsible industry executive’ aanwijzen om als gesprekspartner te dienen voor de SRO. Op het gebied van risk management verlangt OGC ten aanzien van IT gedreven projecten dat de projectorganisatie risico’s met betrekking tot IT en informatiebeveiliging onderkent en vastlegt.

Een reviewteam voert Gateway Review 2 uit alvorens de projectorganisatie overgaat tot het benaderen van marktpartijen, in het kader van een aanbestedingsprocedure. Bij grote aanbestedingsprojecten, welke maanden kunnen duren, kan het nodig zijn Gateway Review 2 meerdere malen te herhalen.

2.3.4. Gateway 3: Investeringsbeslissing Met als startpunt de uitkomsten Gateway Review 2, die aanleiding vormden om naar de volgende projectfase te gaan, gaat de projectorganisatie verder met het uitnodigen van (dienst)aanbieders om voorstellen en offertes te doen. De projectorganisatie maakt de uitgewerkte eisen, aangaande het met het project te verkrijgen product, in deze fase kenbaar aan de potentiële dienstaanbieders. Het doel van Gateway Review 336 is, om vast te stellen dat de door de projectorganisatie aanbevolen investeringsbeslissing37 het meest passend is om de projectdoelstellingen te halen. Gateway Review 3 zorgt voor zekerheid over het selectieproces van de aanbieders. Tevens stelt het reviewteam bij Gateway Review 3 vast of het projectteam het selectieproces goed managed. Ook kijkt het reviewteam naar de mate waarin de voorstellen en offertes van de aanbieders voldoen aan de projectvereisten. Een ander punt van aandacht bij Gateway Review 3 is het verkrijgen van zekerheid over de mogelijkheid dat zowel de opdrachtgever als de aanbieder instaat zijn om het project uit te voeren. Daarnaast onderzoekt het reviewteam of er voldoende processen zijn ingericht om na afloop van het project verder te kunnen gaan met de project uitkomsten. Om zekerheid te verkrijgen over de hiervoor weergegeven onderwerpen verwerkt het reviewteam deze onderwerpen in concrete vragen38. Deze concrete vragen zijn opgenomen in bijlage 10 van deze scriptie.

Het reviewteam verricht Gateway Review 3 voorafgaand aan het daadwerkelijk sluiten van de aanbestedingsovereenkomst(en). Doordat het projectteam soms binnen een project volgtijdelijk meerdere investeringsbeslissingen neemt, kan het gebeuren dat Gateway Review 3 meer dan één keer plaatsvindt binnen een project. Het kan bijvoorbeeld bij een IT project gebeuren dat er eerst een investeringsbeslissing nodig is voor een pilot, waarna vervolgens een investeringsbeslissing nodig is voor de gehele realisatie van het project.

In het OGC Best Practice werkboek over Gateway Review 3 zijn enkele vragen gericht op IT gedreven projecten. Zo vraagt het werkboek voor IT gedreven projecten naar onderbouwingen die aantonen dat er aandacht besteed is aan de invloed van e-business en legacy systemen. Ten aanzien van risk management zijn er voor IT gedreven projecten vragen opgesteld die erop gericht zijn om informatie te verzamelen over de informatiebeveiliging met de bijbehorende risicoanalyse en risicomanagement.

36 OGC Best Practice-Gateway to success, Review 2: Investment decision, 2007, bladzijde 8. 37 Onder Investeringsbeslissing verstaat OGC het geheel van te sluiten aanbestedingscontracten. 38 OGC Best Practice-Gateway to success, Review 3: Investment decision, 2007, bladzijde 7.

20

2.3.5. Gateway 4: Gereedheid voor dienstverlening Aanbesteding door de projectorganisatie volgt na afloop van Gateway Review 3. Inhoudelijk ontwikkelen de dienstaanbieders in samenwerking met de projectorganisatie vervolgens het product dat beschreven staat in de ‘business case’ en de projectbeschrijving. Voor IT gedreven projecten omschrijft OGC gedetailleerd wanneer het reviewteam Gateway Review 4 dient uit te voeren39. Dit gebeurt nadat de testen, inclusief de business integratie tests en betrouwbaarheidstesten zijn afgerond en voorafgaand aan het definitief in een productieomgeving plaatsen van het ontwikkeld product. Het hoofddoel van Gateway Review 4 is de beantwoording van de vraag: Kan het ontwikkelde product geïmplementeerd worden? Deze vraag is veelomvattend. Het gaat hierbij over:


Gereedheid van de (klant)organisatie om haar eigen organisatie aan te passen op het nieuwe product;




Inrichting van een evaluatie methodiek om de prestaties van het nieuwe product te meten;




Aanwezigheid van voldoende deskundig personeel;




Aanwezigheid van voldoende budget voor de operationele fase van het product en




Structuren tussen klant en aanbieder met betrekking tot het onderhoud van het nieuwe product.

Uit bovenstaande nuanceringen van de bij Gateway Review 4 te beantwoorden hoofdvraag zijn een aantal vragen40 afgeleid welke in bijlage 11 van deze scriptie zijn weergegeven. OGC heeft de vragen verwerkt in een Best Practice werkboek over Gateway Review 4. Genoemd werkboek refereert ook een aantal keren specifiek aan IT. Zo verwacht OGC bij de vraag of de organisatie gereed is voor de ‘business change’ stukken die aangeven of de IT gereed is voor deze verandering. Daarnaast dient het reviewteam vast te stellen dat IT gedreven projecten in overeenstemming zijn met beveiligingsstandaarden, zoals de ISO code voor informatiebeveiliging. Daar waar het reviewteam kijkt naar het ‘business’ calamiteiten- en uitwijkplan, dient zij zich ook te richten op bewijs over de verwerking van de IT componenten in deze plannen. Tevens dient het reviewteam van de dienstaanbieder uitsluitsel te krijgen of de Senior Responsible Industry Excecutive van de dienstaanbieder de plannen, die zien op implementatie en het gebruik van het product, draagt. Als laatste kijkt het review team of de kosten van onderhoud van de IT infrastructuur in lijn liggen met de verwachtingen. Calamiteiten en back-up plannen maken in deze fase deel uit van het onderzoek, als ook documentatie over informatiebeveiliging, IT onderhoudsinstructies en de door de aanbieders afgegeven garanties.

2.3.6. Gateway 5: Evaluatie van behaalde resultaten In de operationele fase, nadat door de SRO vastgesteld is dat het project de beoogde bijdrage levert aan een programma, verricht het reviewteam Gateway Review 5. De eerste Gateway Review 5 is ten tijde van de uitvoering van Gateway Review 4 gepland om samen te vallen met de beslismomenten die zich voordoen nadat de ‘Post Implementation Review’ plaats gevonden heeft. Om de SRO zekerheid te geven dat het investeren in de ‘business case’ gerechtvaardigd was en dat er iets gedaan wordt met de uit het project geleerde lessen, voert de projectorganisatie een ‘Post Implementation Review’ uit. De gegevens die zijn verkregen uit de ‘Post Implementation Review’ gebruikt het reviewteam als belangrijke input voor Gateway Review 5.

39 OGC Best Practice-Gateway to success, Review 4: Readiness for service, 2007, bladzijde 8. 40 OGC Best Practice-Gateway to success, Review 4: Readiness for service, 2007, bladzijde 7.

21

Een Gateway Review 5 zal een reviewteam gedurende de levensduur van het product een aantal keren uitvoeren. Het Engelse OGC Gateway Review model ziet er in dat opzicht ook anders uit dan het in paragraaf 2.1. getoonde model. In plaats van één Gateway Review 5 onderkent het Engelse model41 een fasering in 3 delen. Deel 1 van Gateway Review 5 richt zich op de ‘business case’ en de mate waarin de contracten tussen leveranciers/aanbieders en de klantorganisatie zorgdragen voor een goede werking tijdens de operationele fase van het product. Afhankelijk van de levensduur van de operationele fase zal de producteigenaar een of meerdere ‘midden’ Gateway Reviews 5 initiëren. Wanneer deze ‘midden’ Gateway Reviews geschieden, bepaalt de operationeel eigenaar van het product. Gemiddeld gaat het product binnen een jaar nadat het in de operationele fase is gekomen over van de SRO naar de operationele eigenaar. Na de overgang wordt de operationeel eigenaar verantwoordelijk voor de resultaten die hij met het product behaalt en het beheer van het product. Naar alle waarschijnlijkheid zullen bij IT gedreven projecten de operationele fases korter zijn dan bij grote bouwprojecten. Als gevolg hiervan zullen er bij grote bouwprojecten meer ‘midden’ Gateway Reviews plaatsvinden dan bij een doorsnee IT project. De ‘midden’ Gateway beoogt de werking van het operationeel management vast te stellen. In detail richt het reviewteam zich in deze fase op veranderingen in het contractmanagement42 welke leiden tot verbeteringen in ‘waarde voor geld’ en stimuleringsmaatregelen om de prestaties te verbeteren.

De afsluitende Gateway Review 5 is gericht op de ontmanteling en afwikkeling van het geleverde product. Vragen die hierbij spelen zijn: hoe wikkelt de producteigenaar de met de leveranciers aangegane contracten af en welk vervolg geeft hij aan het product? Concrete werkzaamheden43 die het Gateway Review team bij Gateway Review 5 verricht zijn vastgelegd in bijlage 12 van deze scriptie. In het door OGC ontwikkelde ‘Best Practice’ werkboek over Gateway 5 zijn geen vragen opgenomen die het reviewteam specifiek voor een IT gedreven project moeten beantwoorden.

2.4. Conclusie 2.4.1. Gateway Review versus reguliere audit Om in te kunnen gaan op de overeenkomsten en verschillen tussen de Gateway Review methode en een reguliere audit is het noodzakelijk om eerst eenduidigheid te krijgen over wat onder een reguliere audit wordt verstaan. In het kader van deze scriptie versta ik onder een reguliere audit44: “dat door middel van het verzamelen en beoordelen/evalueren van evidence, toetsing plaatsvindt van één of meer aspecten van een gedefinieerd object aan een vooraf vastgestelde (set van) norm(en), met als doel om, op grond van de resultaten van die toetsing één of meer (door een auditor of een derde) gecertificeerd(e) oordeel/oordelen te kunnen afgeven aan de opdrachtgever of, via de opdrachtgever, aan derden, waarbij zowel aan de audit als aan de auditor bepaalde eisen worden gesteld.”

41 Best Practice-Gateway to success, Review 5: Operations review and benefits realisation, 2007, bladzijde 8. 42 Contractmanagement is hier gedefinieerd als: “het op operationeel niveau managen van alle contractueel vastgelegde verantwoordelijkheden, verplichtingen, procedures, afspraken, voorwaarden en tarieven rond een bepaalde overeenkomst plus het managen van alle onduidelijkheid, hiaten of ongewenste wijzigingen daarin. De contractmanager voert deze taken met bijbehorende verantwoordelijkheden uit in opdracht van en met gedelegeerde bevoegdheden van de contracteigenaar.” Vorenstaande is overgenomen uit Contractmanagement voor ICT op basis van CATS CM van J. van Beckum en G. Vlasveld, 2008, Van Haren Publishing. 43 Best Practice-Gateway to success, Review 5: Operations review and benefits realisation, 2007, bladzijde 7. 44 Overgenomen uit: Twintig over Internal/Operational Auditing, ‘auditing, audit, auditor, wat moeten we er ermee?’, C. Kocks, 2003, Vera/Eurac, bladzijde 4.

22

Het moment waarop de instrumenten worden ingezet kan een verschil vormen tussen de reguliere audit en de Gateway Review. Voorafgaand aan een belangrijke beslissing, het doorgaan naar de volgende project fase, zet de opdrachtgever de Gateway Review methode in. Bij een reguliere audit zijn er meerdere momenten te kiezen door de opdrachtgever om het instrument in te zetten. Van oudsher zet de opdrachtgever de regulier audit achter af in bij een project. Daarnaast kan de opdrachtgever gedurende de looptijd van het project projectaudits laten uitvoeren45.

Binnen de Gateway Review voeren collega-bestuurders, managers en andere deskundigen die binnen en buiten de overheid werkzaam zijn, op het zelfde terrein als het te reviewen project, de review uit. Deze reviewers zijn onafhankelijk van het project. Gedurende het jaar voeren reviewers één of enkele reviews uit. Om de review uit te voeren krijgen de reviewers een cursus van enkele dagen. Audits van accountantskantoren, interne accountantsafdelingen en departementale auditdiensten gebeuren door professionele gecertificeerde auditors, welke een langdurig opleidingstraject hebben gevolgd. De hoofdtaak, dan wel één van de hoofdtaken van deze auditors vormt het uitvoeren van audits. Waarbij de gecertificeerde auditors gehouden zijn aan de door hun eigen beroepsorganisatie opgelegde gedrags- en beroepsregels en vaktechnische richtlijnen. Dit heeft zowel consequenties voor de manier waarop de auditor werkzaamheden verricht (te denken valt hierbij ondermeer aan de vereisten waar aan een opdrachtformulering dient te voldoen) als ook de vastlegging van de audit (er dient een duidelijke audittrail in het dossier aanwezig te zijn vanuit het verzamelde bewijsmaterieel naar de conclusie).

Terugkomend op laatst genoemd onderwerp, de vastlegging van de audit, is er een belangrijk verschil te onderkennen met de Gateway Review methode. Het verzamelde bewijsmateriaal bij een Gateway Review, bestaand uit ontvangen documenten en aantekeningen van gehouden interviews, vernietigt de teamleider van het reviewteam na afloop van de review.

Een ander verschil tussen een reguliere audit en de Gateway Review vormt de normatiek waaraan beide toetsen. Wanneer de auditor een audit uitvoert, toetst de auditor het bewijs aan normen. Normen zijn voorafgaand aan de audit bekend en komen voort uit de kwaliteitsaspecten (zoals beschikbaarheid, integriteit en vertrouwelijkheid) waarover de auditor een uitspraak wil doen. Het voldoen aan de norm levert een positief oordeel op, vice versa levert het niet voldoen aan de norm een negatief oordeel op. De Gateway Review methode kent als basis de OGC Best Practice werkboeken. Deze werkboeken zijn de resultante van de verdere uitwerking van de OGC Best Practices. Samengevat staan er in de werkboeken de belangrijkste doelstellingen van de review, de uit de doelstelling voortvloeiende aandachtspunten, te stellen vragen, het te verkrijgen bewijsmateriaal en mogelijk beschikbare informatie bij de projectorganisatie. Doordat vrijwel elk programma en project uniek is, heeft het OGC gekozen om de werkboeken het karakter te geven van handreikingen. Expliciete kwaliteitseisen en de daaruit voorkomende normen zijn niet terug te vinden in de werkboeken. Voor de bepaling of iets een risico is en de inschatting van de urgentie van het risico, vertrouwt OGC op de ervaring en expertise van het Gateway Reviewteam.

45 Uit de reacties van de geïnterviewden op de conceptscriptie kwam het verrassende beeld naar voren dat de geïnterviewden een zeer uiteenlopende visie hebben op de inhoud van de audit, de bruikbaarheid van de uitkomsten van een audit en het moment waarop interne auditdiensten en externe auditors audits uitvoeren bij projecten.

23

Daar waarbij een reguliere audit de scope van te voren helder en duidelijk vaststaat en zijn weerslag vindt in een auditplan en werkprogramma’s, daar is de scope bij de Gateway Review minder helder en duidelijk. Op basis van waarnemingen van het Gateway reviewteam, bepaalt het reviewteam gaande weg de richting van de review. Ook ten aanzien van de uit te voeren werkzaamheden zijn er verschillen tussen een audit en de Gateway Review. De Gateway Review kent twee bronnen waaraan zij het bewijs ontleent, te weten: interviews en de, op het project betrekkinghebbende, ter beschikking gestelde stukken. Eigen waarnemingen ter plaatse maken geen onderdeel uit van de Gateway Review methode, terwijl deze waarnemingen een belangrijk onderdeel vormen van een reguliere audit.

Met betrekking tot de rapportage die voortkomt uit een reguliere audit en een Gateway Review zijn er ook verschillen te onderkennen. Op basis van vertrouwelijkheid verstrekt het Gateway reviewteam haar rapportage enkel en alleen aan de SRO. Het is aan de SRO om al dan niet iets te doen met de aanbevelingen uit de rapportage van het reviewteam. Dat de Gateway-organisatie de rapportage van het Gateway Review team als een intern stuk beschouwt, blijkt uit de argumentatie omtrent het openbaar maken van de rapportage. Met betrekking tot de openbaarmaking doet de Gateway-organisatie een beroep op artikel 11 van de Wet Openbaarheid van Bestuur. Artikel 11 lid 1 biedt de mogelijkheid om openbaarmaking te voorkomen van, ten behoeve van intern beraad, opgestelde documenten waarin zich persoonlijke beleidsopvattingen bevinden. Een auditrapport is daarentegen een verantwoordingsstuk en generiek bedoeld voor breder publiek. In het kader van de regeling Grote Projecten, worden auditrapporten bij voortgangsrapportages van de departementale auditdienst of een extern accountantskantoor uitgebracht aan de Tweede Kamer. Andere auditrapporten, die departementale auditdiensten dan wel extern accountantskantoren opleveren, die zien op projecten, zijn vaak gericht aan de leiding van een departement. Het oordeel dat de auditor geeft bij een verantwoording is veelal openbaar.

Naast het grote aantal verschillen tussen de reguliere audit en de Gateway Review is er ook één belangrijke overeenkomst. Beide, zowel de reguliere audit als de Gateway Review verstrekken de respectievelijke gebruikers van hun rapportage zekerheid. Bij een Gateway Review geeft het reviewteam zekerheid over de mate waarin een project gereed is om naar de volgende projectfase te gaan. De zekerheid die de opdrachtgever met deze methode verkrijgt, is ook wel eens quality assurance46 genoemd. Het is echter de vraag of deze term recht doet aan de doelen die OGC beoogt met de Gateway Review methode. OGC schrijft over de zekerheid die een opdrachtgever verkrijgt met de Gateway Review47 dat ze weliswaar zekerheid verschaft, maar dat het uitvoeren van alleen deze review niet voldoende is. Daarnaast benadrukt OGC dat de opdrachtgever de scope en de beperkingen van de review niet uit het oog mag verliezen. Als laatste geeft OGC nog aan dat de reviews niet in de plaats kunnen treden van een deugdelijke ‘governance framework’.

46 R. Sedee, C. Wauters, Gateway naar success, de EDP-Auditor, nummer 1, 2007, bladzijde 10. 47 Best Practice-Gateway to success, Review 0: strategic assessment, 2007, bladzijde 4 en 5.

24

2.4.2. Voor en nadelen van de Gateway Review methode Om een helder beeld te krijgen van de Gateway Review methode is het wenselijk om te kijken naar de voor- en nadelen van de methode. Voordelen van de Gateway Review methode zijn48: •

De zekerheid die de methode de opdrachtgever biedt dat het project door kan naar de volgende projectfase.

•

Dat de kans dat projectorganisatie de doelen ten aanzien van de tijdsplanning en gebudgetteerde kosten haalt, toeneemt.

•

Dat de SRO bij het project beter op de hoogte is van de toestand van een project en in welke fase een project zich bevindt. Of andere belanghebbenden ook inzicht krijgen is afhankelijk van de openbaarheid van het rapport.

•

Dat de deelnemers in het reviewteam kennis en ervaring opdoen die ze elders binnen de overheid bij andere projecten in de rol als medewerker van een projectorganisatie, SRO of reviewer kunnen gebruiken.

•

Dat de rapportage meer draagvlak bij de SRO krijgt, door een reviewteam zo samen te stellen dat één of meerdere teamleden voor wat betreft achtergrond en professionele ervaring gelijk waardig zijn aan de SRO.

•

Dat medewerkers van het projectteam niet terughoudend hoeven te zijn, de opdrachtgever en andere betrokkenen gebruiken de review rapportage immers niet als verantwoording. Door bevindingen van het reviewteam vertrouwelijk te behandelen en het reviewdossier gelijk na de review te vernietigen, is er een open en transparante medewerking van de projectorganisatie.

De Gateway Review methode, is een relatief jonge methode, hetgeen ook zijn weerslag heeft in de literatuur, als het gaat om kritiek op deze methode. Vooralsnog komen er vanuit de literatuur slechts enkele nadelen bovendrijven, dit zijn: •

Financiële, beleidsmatige en management gerelateerde aspecten van grote IT projecten ondervangt de Gateway Review methode, maar ze gaat voorbij aan de technische aspecten die vaak de oorzaak zijn van het falen van een IT project49.

•

Het uitvoeren van de Gateway Review methode kost geld. Deze kosten bestaan uit het opleiden van reviewers, de uitvoering van de review, de tijd die de review in beslag neemt bij de projectorganisatie voor het beantwoorden van schriftelijke en mondelinge vragen en het bijhouden van additionele projectdocumentatie door de projectorganisatie50. De kosten van de reviews moeten eerst worden terugverdiend om te kunnen spreken van een geldelijk voordelig saldo51 bij de toepassing van de Gateway Review methode.

•

De gekwantificeerde financiële baten die de Gateway Review realiseert, zijn moeilijk toetsbaar. Dit blijkt ondermeer uit het feit dat de door OGC in Engeland gepubliceerde besparingen niet

48 Ontleend aan, Gateway naar success, van R. Sedee, C. Wauters, de EDP-Auditor, num. 1, 2007, bladzijde 8. 49 Ontleend aan, Ga verder dan Gateway, G Leih, Digitaal Bestuur, 19 maart 2009. 50 Zie ook: Toetsen kost ook (heel veel) geld, T. Bestenbreur, BinnenlandsBestuur, 27 maart 2009. 51 Phil Kemp, brandmanager van OGC, geeft aan dat er door de Gateway Review in het fiscale jaar 2007/2008 ongeveer 2,5 miljard pond bespaard is, gelijk aan 3% van de totale projectuitgaven, dit terwijl de Gateway kosten niet meer dan 0,01 % van de uitgaven bedroegen. Vorenstaande houdt in dat de Gateway netto tot een enorme kostenbesparing leidt. Zie ook: Collegiale klap op ICT-project, 27 februari 2009, F. Blankena, digitaal bestuur.

25

onderworpen zijn geweest aan een financiële audit, welke de besparing kon bevestigen. Het lijkt erop dat de besparingen bestaan uit schattingen en extrapolaties. Bovengenoemde opsomming van voor- en nadelen van de Gateway Review methode vanuit de literatuur, krijgt een vervolg in paragraaf 4.1.4. ‘Andere aspecten met betrekking tot de Gateway Review methode’ waar voor- en nadelen van de methode vanuit de praktijk aan de orde komen.

2.4.3. Effectiviteit in te zetten Gateway Review’s Met betrekking tot de zes Gateway Reviews, is het voor de keuze die de opdrachtgever maakt, om één of meerdere Gateway Reviews te laten uitvoeren van belang om rekening te houden met het effect van het bijsturen of veranderen van het project. Gateway Review 0 en Gateway Review 1 staan aan het begin van een project. Het bijsturen op basis van deze reviews levert veel effect op voor alle daarop volgende projectfasen. Het bijsturen of veranderen van het project op basis van een Gateway Review 4 of Gateway Review 5 levert minder effect op voor het project als geheel, dit omdat reeds een groot deel van het project doorlopen is op het moment dat de opdrachtgever bijstuurt. Grafisch is het effect van bijsturen aan de hand van de diverse Gateway Reviews in onderstaande grafiek weergegeven52:

52 Wanna J., J. Buting, Improving Implementation: Organisational Change and Project Management, Chapter 16. Governments Can deliver: Better Practice in Project and Program Delivery, ANZOG/ANU, 2006.

26

3. Beschrijving overheids IT-projecten Het GMV en mGBA zijn twee programma’s die ik in dit hoofdstuk op basis van de door mij verrichte literatuurstudie beschrijf. Hierbij start ik in onderhavig hoofdstuk met de GMV waarbij ik een algemene beschrijving van de GMV geef, het doel van de GMV uiteenzet en inga op de voortgang van het GMV project (paragraaf 3.1.1.). Vervolgens komt in paragraaf 3.1.2. het GMV proces aanbod. Waarna paragraaf 3.1.3. dieper ingaat op de organisatie op het GMV project. Bij het mGBA programma start ik met een de doelstellingen van het programma, waarna ik een globale beschrijving van het programma geef en inga op de voortgang van het programma (paragraaf 3.2.1.). Daarna komt de organisatie op het mGBA aan de orde (paragraaf 3.2.3.) om als laatste nader in te gaan op de omgeving van het mGBA programma (paragraaf 3.2.4.). Hoofdstuk 3 vormt het fundament voor het antwoord dat in hoofdstuk 5 gegeven wordt op de deelvragen 2 en 3, zoals weergegeven in paragraaf 1.4. van deze scriptie. Deze vragen betreffen: Wat is de betekenis van het GMV programma voor het informatiebeleid van de publieke sector en wat is de betekenis van het mGBA programma voor de informatievoorziening van de overheid en de burger?

3.1. Gemeenschappelijke Machtiging- en Vertegenwoordigingsvoorziening 3.1.1. Doel, beschrijving en voortgang van de GMV De overheid, in brede zin, stelt burgers en bedrijven steeds meer in staat om diensten van de overheid op digitale wijze te gebruiken. Deze vorm van dienstverlening is inmiddels zeer uitgebreid en neemt dagelijks nog steeds toe. Enkele voorbeelden van deze dienstverlening zijn de digitale aangifte Inkomstenbelasting van de Belastingdienst, de digitale aanvraag van een bouwvergunning bij gemeenten en het digitaal indienen van bezwaarschriften tegen de WOZ beschikking bij gemeenten. Een continue verbetering van de digitale dienstverlening draagt bij aan één van de overheidsdoelstellingen, te weten het terugdringen van de administratieve lasten voor de burgers en bedrijven.

De GMV is een voorziening die er voor zorg moet dragen dat een burger iemand anders kan machtigen, of te wel formeel toestemming geeft om namens de burger digitale rechtshandelingen te verrichten. Het betreft hier alleen handelingen die zien op digitale overheidsdiensten. Hierbij is het voor alle partijen van belang dat er zekerheid bestaat over het feit dat een burger iemand anders gemachtigd heeft om namens hem gebruik te maken van een overheidsdienst. Met de GMV moet op een veilige en betrouwbare manier vastgelegd en gecontroleerd kunnen worden wie namens een bepaalde burger gemachtigd is voor welke digitale overheidsdiensten. De GMV is mede bedoeld om het voor de overheid ongewenste gedrag van de burger, dat ontstaat door het uitlenen van hun eigen DigiD53, te voorkomen. Door het uitlenen van de DigiD kon een ander, voor de burger die de DigiD had uitgeleend, gebruik maken van de digitale overheidsdiensten. In opdracht van het Ministerie van BZK is in juli 2007 een start gemaakt met het GMV programma.

53 De DigiD, digitale identiteit, is een gemeenschappelijk systeem waarmee overheidsinstellingen de identiteit kunnen verifiëren van burgers en bedrijven die gebruik maken van de elektronische diensten van de overheidsinstellingen. Vorenstaande definitie is ontleend aan www.encyclo.nl/begrip/DigiD.

27

Concrete doelen welke de overheid met de GMV wil bereiken zijn54:” •

Administratief gemak voor burgers door het uniformeren van de machtigingssystematiek van verschillende overheidsdiensten.

•

Privacybescherming doordat de GMV ervoor zorgt dat alleen gemachtigden persoonsgegevens kunnen inzien.

•

Voorkomen van onrechtmatigheden doordat overheidsdiensten kunnen verifiëren of gegevens aan de juiste persoon worden aangeleverd.

•

Bevorderen van het gebruik van de mogelijkheden van elektronische dienstverlening.”

Met de GMV streeft de overheid na om te komen tot één systematiek van machtigingen voor alle eoverheidsdiensten. Hiermee voorkomt de overheid dat versnippering en additionele lastenverzwaring ontstaat doordat iedere overheidsorganisatie aan een eigen machtigingssysteem gaat werken. Daarnaast tracht de overheid de GMV zo in te richten dat de voorziening eenvoudig in het gebruik is voor de burger en ook eenvoudig aan de burger uit te leggen is.

Als uitgangspunt geldt dat de GMV gebruik maakt van al bestaande en door de e-overheid erkende identificatie en authenticatiemiddelen. Een ander uitgangspunt vormt het veiligheidsniveau. Binnen de GMV is het de dienstaanbieder, de digitale dienstverlenende overheidsinstelling, die bepaald welk veiligheidsniveau voor een machtiging gewenst is. Voor de ontwikkeling van de GMV is ervoor gekozen om NORA als richtinggevende architectuur te kiezen. NORA staat voor de Nederlandse Overheid Referentie Architectuur. Om samenhang te realiseren in de bouw en inrichting van de elektronische digitale overheid bevat het NORA, voor projecten en programma’s, een aantal inrichtingsprincipes.

3.1.2. Het GMV proces Gesimplificeerd weergegeven valt het proces dat ten grondslag ligt aan het machtigen van iemand anders voor overheidsdiensten op te splitsen in de volgende stappen: 1.

De persoon die zich wil laten vertegenwoordigen, kan een machtigingskaart telefonisch aanvragen via de DigiD helpdesk. Personen die zich willen laten vertegenwoordigen en zelf toegang tot internet hebben, kunnen inloggen met hun DigiD (op de website van de overheidsinstelling voor wiens digitale dienst hij of zij een machtiging wil verstrekken, dan wel via machtigen.DigiD.nl) en een machtigingscode aanvragen voor een bepaalde digitale overheidsdienst. Van de aanvraag tot de machtiging vindt centrale registratie plaats door GMV.

2.

Wanneer de aanvraag telefonisch is gebeurd, ontvangt de aanvrager van de machtigingscode binnen 5 werkdagen een machtigingskaart met code. Aan degene die online een machtigingscode heeft aangevraagd, verstrekt GMV online een machtigingscode.

3.

De schriftelijk ontvangen machtigingskaart met code, dan wel de online verkregen machtigingscode, verstrekt de burger die zich wil laten vertegenwoordigen aan de gemachtigde.

4.

Om de machtiging te activeren logt de gemachtigde in met zijn eigen DigiD en activeert hij de machtiging met de machtigingscode in de centrale GMV.

54 Renoir, e-overheid: bouw mee aan betere dienstverlening, Basisinformatie GMV, versie 1.1 augustus 2009 bladzijde 3.

28

Producten die voortvloeien uit GMV zijn: een voorziening welke de machtigingen registreert en die door overheidsinstellingen kan worden ingezien om vast te stellen of de machtiging geldig is. Daarnaast levert GMV een helpdesk op, die gebruikers van de machtigingsvoorziening ondersteunt en een interface met burgers voor het inzien en beheren van de machtigingen die de burgers hebben afgegeven. GMV gebruikt het Burger Service Nummer (Hierna: BSN) ter identificatie van de persoon die zich wil laten vertegenwoordigen en de persoon die als vertegenwoordiger gaat optreden. Voor de authenticiteit maakt GMV gebruik van DigiD. Daarnaast doet GMV een beroep op de GBA voor de NAW-gegevens van degene die vertegenwoordigd wordt en de vertegenwoordiger. Op basis van de doelstelling en de uitgangspunten die ten grondslag liggen aan de GMV is er een schema gemaakt. Dit stroomschema duidt gemeenten en andere overheidsinstellingen waar een burger een machtiging kan aanvragen, wijzigen of gebruiken aan met DA (Dienst Aanbieder). Daarnaast zijn er in het schema koppelingen getekend. Deze koppelingen zorgen ervoor dat de (sub)processen op elkaar aansluiten. Met betrekking tot de koppeling tussen de DA en het centrale GMV machtigingsregister maakt de GMV gebruik van standaard XML55 (Extensible Markup Language) gegevensstructuren in standaard SOAP (Simple Object Access Protocol) berichten. Bij het opvragen door de DA en het teruggeven van het antwoord op het autorisatie verzoek gebruikt de GMV de SAML (Security Assertion Markup Language) standaard. Voor de andere belangrijke GUI (Grafische User Interface) koppeling, die tussen de burger en de DA, is HTTP (Hyper Text Transfer Protocol) de standaard voor het opnemen van generieke gebruikers interactie in de eigen website van de DA. Met uitzondering van de directe communicatie vanuit de DA systemen, zullen de GMV processen met behulp van OSB56 (Overheidservicebus) standaarden te bereiken zijn. Het (architectuur)schema van GMV ziet er als volgt uit57:

BURGER

DA gegevens

KOPPELING

DA processen

KOPPELING

BURGER

KOPPELING

DA frontoffice

machtiging verifiëren

KOPPELING

GMV gegevens

KOPPELING

GMV processen

KOPPELING

GMV frontoffice

KOPPELING

aanvragen activeren wijzigen intrekken ontkoppelen raadplegen

basisregistraties

BEDRIJF

55 Omdat het niet bijdraagt aan de beantwoording van de onderzoeksvragen, heb ik ervoor gekozen om niet nader in te gaan op de inhoud en werking van XML, SOAP, SAML en HTTP GUI bij GMV. 56 OSB zorgt voor standaardisatie bij het berichtenverkeer dat er tussen de verschillen de overheden plaatsvindt. Voor meer informatie zie www.overheidsservicebus.nl. De OSB heet vanaf 2010 DigiKoppeling. 57 Schema uit een presentatie van Rein During, gegeven op 21 januari 2009, onder de titel e-overheid: Bouw mee aan een betere dienstverlening.

29

3.1.3. Organisatie op het GMV project Het Ministerie van BZK, na afronding van het project eigenaar van de voorziening, is opdrachtgever van het GMV project. Er is een periodiek opdrachtgeveroverleg tussen BZK en de programmamanager. In dit overleg wordt de financiering en de financiële uitputting van het programma besproken. De opdrachtgever wordt geadviseerd door een stuurgroep waarin BZK, de Ministeries van Economische Zaken en van Financiën, Belastingdienst en GBO Overheid58 zitting hebben. Oorspronkelijk nam ook het Ministerie van Landbouw Natuur en Visserij (Hierna: LNV) deel aan de stuurgroep, maar het Ministerie van LNV heeft zich teruggetrokken en is verder gegaan met de ontwikkeling van een eigen machtigingssysteem. De voorbereiding van overleggen van de stuurgroep geschiedt door het GMV overleg. Dit zogenaamde tactisch overleg bestaat uit vertegenwoordigers van alle partijen die ook deelnemen aan het stuurgroep overleg. Voor de inhoudelijke afstemming binnen het GMV programma is er een architectenoverleg. Deelnemers aan het architectenoverleg zijn medewerkers van de Belastingdienst, GBO en ICTU. In het architectenoverleg is GBO niet alleen als beheerpartij aanwezig, maar treedt ze ook op als bewaker van de generieke toepassingsmogelijkheid van de GMV.

3.2. Modernisering Gemeentelijke Basisadministratie (mGBA) 3.2.1. Doel, beschrijving en voortgang mGBA De GBA is de basisregistratie waarmee iedere gemeente de persoonsgegevens van de burgers van de gemeente vastlegt en beheert. Met behulp van de GBA stellen gemeenten persoonsgegevens, zoals familienaam, voornamen, geslacht, geboortedatum en plaats, burgerlijke staat, adres en burgerservicenummer beschikbaar ten behoeve van het maatschappelijk gebruik. Deze werkwijze, van digitale persoonslijsten, is sinds 1994 ingevoerd als vervanger van de analoge persoonskaart. Na de invoering van de GBA is de behoefte ontstaan om de GBA te moderniseren. Hiertoe is de commissie Snellen opgericht, welke als doel had om doelstellingen te formuleren die het mGBA programma moet realiseren. In 2003 heeft de commissie Snellen haar doelstellingen geformuleerd, deze zijn59: •

GBA als spil in de identiteitsinfrastructuur;

•

Snelheid en toegankelijkheid verhogen: 24 * 7 online en sneller doorgeven van mutaties;

•

Meer flexibiliteit en lagere kosten voor aanpassingen aan het systeem;

•

Betere gegevenskwaliteit en minder complexe bijhouding;

•

Verhogen van marktwerking ten aanzien van gemeentelijke ICT pakketten.

Vanuit de doelstelling van de commissie Snellen, is in 2004 een start gemaakt met het mGBA programma. Inmiddels is vanuit dit programma GBA-Verstrekkingen Online gerealiseerd. Met GBA-Verstrekkingen Online kunnen afnemers de GBA 24*7 uur online bevragen en meteen antwoord krijgen. De verwerking in de GBA is echter niet realtime waardoor mutaties in de GBA met een minimale vertraging van 24 uur toegankelijk zijn voor afnemers.

58 Gemeenschappelijke beheerorganisatie GBO.Overheid heeft als doel om te zorgen voor een samenhangende ICT-infrastrucuur zodat burgers en bedrijven electronisch zaken kunnen doen met de overheid op een betrouwbare, snelle en makkelijke mannier. 59 Overgenomen uit de Definitiestudie mGBA Versie 2.0, 28 april 2009, bladzijde 13.

30

Door de complexiteit van het mGBA programma was het niet eenvoudig om een goede kosten en baten inschatting te maken voor het programma. Dit leidde ertoe dat het programma te maken kreeg met budgetoverschrijdingen. Het oorspronkelijke budget voor mGBA, van € 14 miljoen, is gedurende de uitvoering van het programma diverse malen bijgesteld tot een budget van € 34,5 miljoen. Toen er begin 2008 signalen werden afgegeven dat de programmaorganisatie ook het budget van € 34,5 miljoen waarschijnlijk zou overschrijden, heeft de Staatssecretaris van het Ministerie van BZK ingegrepen door het mGBA programma stop te zetten. Voordat het mGBA programma weer opgestart werd diende er eerst een nieuwe business case en een herijking van de definitiestudie plaats te vinden, op basis van de situatie zoals deze aanwezig was toen de Staatssecretaris van het Ministerie van BZK het programma stopzette.

Uit de nieuw opgestelde definitiestudie blijkt dat er nieuwe doelstellingen zijn waarmee het mGBA programma rekening moet houden, als het gaat om vervolgbeslissingen. De nieuwe doelstellingen, die toegevoegd zijn aan de doelstellingen van de commissie Snellen, betreffen: •

Plaatsonafhankelijk werken door gemeenten;

•

De eis om te kunnen werken met shared service centra;

•

Expliciet toepassen van e-overheidstandaarden.

De nieuw opgestelde business case mGBA gaat uit van vier ‘oplossingscomponenten’ om de doelstellingen te kunnen bereiken. Deze vier ‘oplossingscomponenten’ vormen in wisselende samenstelling de drie scenario’s, die met elkaar vergeleken worden in de business case. GBA-Verstrekkingen Full Service is de eerste oplossingscomponent. Met dit component kan het Agentschap Basisadministratie Persoonsgegevens en Reisdocumenten (hierna: BPR) selecties en mutaties, welke de gemeenten volgens de oude werkwijze rechtstreeks aan afnemers verstrekken, vanuit één centraal punt aan afnemers leveren. Hieruit volgt dat de verantwoordelijkheid voor het verstrekken van gegevens verschuift van gemeenten naar het Agentschap BPR, die verantwoordelijk is voor de centraledatabase.

Moderne interfaces vormen de tweede oplossingscomponent in de nieuwe business case. Ten tijde van het stopzetten van het mGBA programma was er al een centrale database gerealiseerd, de gegevens in deze database zijn echter nog niet actueel. Dit komt omdat GBA niet realtime werkt met betrekking tot het bijhouden van de centrale GBA-Verstrekkingen kopie, spontane mutaties naar afnemers en intergemeentelijk berichten verkeer. Moderne interfaces zorgen ervoor dat het berichtenverkeer gaat lopen volgens OSB specificaties en maakt realtime berichtenverkeer mogelijk. Een ingegeven wijziging bij een gemeente leidt in dat geval onmiddellijk tot een wijziging in de centraledatabase.

Een derde oplossingscomponent is het burgerzakensysteem-kern (hierna BZS-K). Door dit nieuwe systeem krijgen alle gemeenten een centraal ontwikkelde uniforme kernapplicatie voor het opzoeken, wijzigen en opslaan van persoonsgegevens t.b.v. burgers en binnengemeentelijke afdelingen in dienstverlenende processen60. Als laatste oplossingscomponent kent de business case het ‘Logisch Ontwerp 4 gegevensmodel’ (hierna: LO 4). In LO 4 zijn de eisen vastgelegd die worden gesteld aan de gegevensset en het gegevensmodel van

60 Overgenomen uit business case modernisering GBA, Utrecht, december 2008, bladzijde 28.

31

het burgerzaken systeem van een gemeente. Ten opzichte van logisch ontwerp 3 zijn er in LO 4 verbeteringen en verduidelijkingen aangebracht, zo kan in LO 4 een scheiding plaatsvinden tussen actuele gegevens en de historie. Door dit laatste is het niet langer noodzakelijk om de historie onderdeel te laten uitmaken van berichtenverkeer.

Bovengenoemde oplossingscomponenten zijn als bouwstenen gebruikt bij de drie scenario’s die nader uitgewerkt zijn in de business case. Scenario 1 ziet op het ontwikkelen van de GBA-Verstrekkingen Full Service in combinatie met de Moderne Interfaces. In scenario 2, het meest vergaande scenario om alle doelen te realiseren, komen alle oplossingscomponenten tot ontwikkeling. Bij scenario 3 vindt alleen de ontwikkeling en invoering van LO 4 plaats. In het Bestuurlijk Akkoord van 5 maart 2009, over het vervolgtraject mGBA, hebben de Minister van BZK en de VNG vastgelegd om scenario 2 te gaan realiseren. De veranderingen tussen de huidige situatie en scenario 2 zijn als volgt weer te geven61:

Huidige situatie

Afnemer Directe levering via GBA-V online

24 uurs levering van mutaties 48 uurs levering van adhoc vragen via GBA-netwerk

Gemeente

GBA-V 24 uurs levering via GBA-netwerk

Toekomstige situatie

Afnemer Directe levering via moderne interfaces

Gemeente BZS-K

GBA-V Realtime leveringen via moderne interfaces

61 Overgenomen uit business case modernisering GBA, Utrecht, december 2008, bladzijde 36.

32

3.2.2. Organisatie op het mGBA programma De Staatssecretaris van BZK is politiek verantwoordelijk voor het mGBA programma. Deze verantwoordelijkheid ziet ook op het budget en het tijdpad van het programma, als ook de inhoudelijke kwaliteit van de uitkomsten van het programma. Ambtelijk is de directeur Openbaar Bestuur en Democratie van BZK er verantwoordelijk voor, dat het mGBA programma de maatschappelijke en bedrijfsmatige doelstellingen haalt. Gemeenten dragen op grond van de wet verantwoordelijkheid over hun lokale GBA en zijn daarmee medeverantwoordelijk voor het mGBA programma en de met mGBA te bereiken doelstellingen.

Uit bovengenoemde verantwoordelijkheden zijn overleggen afgeleid. Zo is er met betrekking tot het mGBA programma een Bestuurlijk overleg. BZK overlegt met gemeenten, welke verenigd zijn in de VNG, onder eindverantwoordelijkheid van de Staatssecretaris. Doel van het bestuurlijk overleg is om strategische kaders voor het mGBA programma vast te stellen. Dit overleg vindt minimaal twee keer per jaar plaats. Beslissingen over het beleggen van verantwoordelijkheden en planning, de financiering van mGBA en de op te leveren producten zijn aanleiding om bestuurlijk overleg te voeren. Invulling van de ambtelijke verantwoordelijkheid, op onder andere de beoordeling van de investeringsbeslissing en de voortgang van het programma, vindt op het hoogste niveau plaats door de stuurgroep. De stuurgroep keurt ondermeer wijzigingen in programmaplan en business case goed. Concreet zorgt de stuurgroep voor de beheersing van het budget, dat de realisatie binnen de planning blijft en de kwaliteit van het mGBA programma. Deelnemers aan de stuurgroep zijn: de VNG namens de gemeenten, BZK als opdrachtgever en voorzitter van de stuurgroep, gebruikers, directeur Dienstverlening Regeldruk en Informatiebeleid van BZK als bewaker van het beleid op e-overheid als geheel en de directeur BPR als verantwoordelijke voor het functioneren van de GBA-stelsels en het beheer op de GBA voorziening. De stuurgroep rapporteert rechtstreeks aan het Bestuurlijk overleg.

Kwaliteitswaarborging binnen het mGBA programma is vorm gegeven door een van de programmamanager onafhankelijke kwaliteitsmanager aan te stellen, welke deel uitmaakt van de staf van de opdrachtgever. Genoemde functionaris rapporteert aan de stuurgroep. Daarnaast is in het programmaplan vastgelegd dat BZK de mogelijkheid heeft om audits uit te voeren op het programma. In het programmaplan is tevens vastgelegd dat er bij belangrijke faseovergangen in het programma verplicht Gateway Reviews plaatsvinden ten behoeve van de stuurgroep en het bestuurlijk overleg. De planning van de Gateway Reviews is als volgt vastgelegd in het programmaplan:

33

Zoals uit bovenstaande tekening te herleiden is, is er binnen het mGBA programma gekozen voor twee resultaatpaden. Om de oplossingscomponenten voort te brengen zal de programmaorganisatie binnen de resultaatpaden deelprojecten laten uitvoeren. Het eerste resultaatpad is GBA-V. Binnen dit pad realiseert het programma GBA Full Service en Moderne Interfaces. BZS-K vormt het tweede resultaat pad. Binnen dit pad realiseert het mGBA programma naast BZS-K ook LO4. Voor het benoemen, inrichten en monitoren van de deelprojecten binnen de twee beschreven resultaatpaden is als leidraad RUP62 (Rational Unified Process) gekozen. Daarnaast werkt de projectorganisatie bij deelprojecten met Prince2. Zo dient ieder deelproject een PID (Project Initiatie Document) te hebben. Aanvullend op Prince2 past het programmamanagement op programmaniveau MSP63 (Managing Successfull Programms) als best-practice methodiek toe.

3.2.3. Omgeving mGBA programma Het bedrag waarmee het oorspronkelijk budget voor mGBA wordt overschreden en het stopzetten van het programma door de staatssecretaris zou kunnen duiden op het feit dat het mGBA programma een complex programma is. Een indruk van de complexiteit van het mGBA wordt verkregen door te kijken naar de omgeving van het mGBA programma. Wie heeft er nu allemaal te maken met het programma? Dit zijn onder andere64 gemeenten, VNG, ander e-programma’s, burgers, BZK, BPR, leveranciers, een grote groep afnemers en het stelsel van basisadministraties. De relaties met ander e-Overheidsprogramma’s zijn zeer omvangrijk. GBA is een van de belangrijkste bouwstenen voor de realisatie van e-Overheid.

62 RUP kent de volgende stappen: opstellen concept (Inception), uitwerking concept (Elaboration), bouwen (Construction) en transitie (Transition). 63 MSP is een methode die ontwikkeld is door OGC en bevat principes en processen voor het gebruik en het beheer van programma’s. De principes en processen zijn gebaseerd op best-practices. 64 Een uitvoerige belichting van alle betrokkenen bij mGBA is terug te vinden op bladzijde 14 van het programmaplan mGBA.

34

4. Bevindingen en analyse van het praktijkonderzoek Het praktijk onderzoek heeft bestaan uit een tiental interviews met personen die nauw betrokken zijn bij de Gateway Review methode, de GMV of het mGBA programma. Bij het benaderen van personen voor interviews is getracht om een goede spreiding te vinden tussen uitvoerders van de Gateway Review methode, projectmanagers, SRO’s, auditors en deskundigen. Dit om een zo breed en diep mogelijke zienswijze te krijgen op de Gateway Review methode en de relatie tussen de Gateway Review methode en beide genoemde programma’s. De interviews hebben plaatsgevonden met behulp van een vooraf opgestelde gestructureerde vragenlijst. Deze vragenlijst is per geïnterviewde op details aangepast afhankelijk van de functie en het deskundigheidsgebied van de geïnterviewde. De pijlers van de Gateway Review methode, te weten: onafhankelijkheid, vertrouwelijkheid en de kwaliteit van de review hebben een prominente plaats ingenomen in de vragenlijst. Naast de pijlers van de Gateway Review methode is er bij de interviews uitvoerig ingegaan op de onderzoeksvragen, zoals deze verwoord zijn in paragraaf 1.4. ‘centrale vraagstelling’ van deze scriptie. In onderstaande paragrafen zijn de belangrijkste meningen, uitspraken en conclusies van de geïnterviewden samengevat. Omdat de inzichten binnen de overheid en in de IT in rap tempo veranderen is het van belang om de uitspraken die gedaan zijn door de geïnterviewden te relateren aan de periode waarin de interviews gehouden zijn, te weten juli 2009 tot en met januari 2010.

4.1. Gateway Review methode 4.1.1. Onafhankelijkheid Het is volgens OGC mogelijk dat reviewers bij de Gateway Review methode, medewerkers zijn van het departement dat verantwoordelijk is voor het onderhavige project. Een en ander hangt af van het risicoprofiel van het project dat het reviewteam gaat reviewen. De uitvoering van de Gateway Review methode door medewerkers van het eigen departement lijkt in strijd met de eisen die er in het algemeen gesteld worden aan onafhankelijkheid, zoals financiële, functionele en mentale onafhankelijkheid65. Vorenstaande vormde voldoende reden om bij de gevoerde interviews dieper in te gaan op de onafhankelijkheid van de Gateway Reviewers.

Het blijkt dat in Nederland ook stafmedewerkers als reviewers deelnemen aan reviews op projecten, waarbij hun eigen departement verantwoordelijk is voor het project. Met een dergelijke manier van werken zijn ervaringen opgedaan door Het Expertise Centrum (hierna: HEC). Op basis van de opgedane ervaringen is HEC terughoudend met het inzetten van stafmedewerkers van het verantwoordelijke departement.

Bij wijze van uitzondering geldt dat kennis voor onafhankelijkheid gaat. Waarbij de Gateway-organisatie extra waarborgen inbouwt om een bepaald niveau van onafhankelijkheid te kunnen garanderen. Nadrukkelijk stelt de heer Mollema (HEC) hierbij dat het belangrijk is dat de uitzondering niet de regel gaat overvleugelen. Dit zou de Gateway Review methode ondermijnen.

65 In het kader van deze scriptie wordt voorbij gegaan aan het onafhankelijkheidsvraagstuk van externe auditors bij de uitvoering van audits. Enige geïnterviewden menen dat er wel iets valt af te dingen op de onafhankelijkheid van externe auditors.

35

Onafhankelijkheid vormt ook een mogelijke belemmering voor het aantrekken van externe deskundigen van grote marktpartijen om deel te nemen in reviews, vindt de heer Mollema. Allereerst zijn alle grote marktpartijen meestal wel op de een of andere manier betrokken bij de grote projecten van de overheid. Anderzijds is het mogelijk dat de externe deskundige, die ingehuurd is als reviewer, te maken krijgt met een situatie waarin hij een commerciële mogelijkheid ziet. Mag er van deze medewerker verwacht worden dat hij deze mogelijkheid aan zich, en zijn werkgever voorbij laat gaan? Andere geïnterviewden zijn van mening dat het onvermijdelijk is om marktpartijen te betrekken bij reviews. Een mogelijke oplossing voor tegenstrijdige belangen kan zijn om tenderpartijen uit te sluiten om deel te nemen aan de review. Binnen ICTU heerst de opvatting dat, om de vraag te beantwoorden of iemand kan optreden als Gateway Reviewer, het gaat om de persoonlijke integriteit. In plaats van onafhankelijkheid lijkt het in Nederland ingeburgerde begrip onpartijdigheid meer passend als eis voor een reviewer. Enige geïnterviewden vinden de discussie over onafhankelijkheid ondergeschikt aan het belang dat ze hechten aan een reviewer van hetzelfde niveau als de opdrachtgever. Dit omdat zij veel waarde toekennen aan de acceptatie van de uitkomsten van de Gateway Review door de opdrachtgever. Een opdrachtgever zal, volgens de geïnterviewden, het resultaat van een Gateway Review eerder accepteren van iemand die gelijkwaardig is aan de opdrachtgever op basis van functie, ervaring en deskundigheid.

De Gateway-organisatie is momenteel de mogelijkheid aan het bekijken om mensen uit het bedrijfsleven en de wetenschap aan te trekken als reviewer. Onafhankelijkheid van de reviewers definieert de Gatewayorganisatie als het niet hebben van directe en indirecte betrokkenheid bij een project. Hierbij vindt de Gateway-organisatie de opdrachtgever leidend, bij twijfels over onafhankelijkheid, in het bepalen of iemand al dan niet kan deelnemen aan een reviewteam.

Op een hoger niveau onderkent één van de geïnterviewden een ander onafhankelijkheidsvraagstuk. De Gateway-organisatie is als uitvoeringsorganisatie door BZK opgericht en als zodanig ook nog steeds verbonden met BZK. Het ICTU de hoofduitvoerder van vele programma’s en projecten is, zoals eerder in deze scriptie genoemd, door BZK en VNG opgericht. BZK treedt zelf als opdrachtgever op bij vele programma’s. Binnen de driehoek van de Gateway-organisatie (reviewer), ICTU (uitvoerder) en BZK (opdrachtgever) kan, gezien de gelieerdheid, snel de schijn van mogelijke belangenverstrengeling ontstaan.

4.1.2. Vertrouwelijkheid Samen met onafhankelijkheid en de kwaliteit van het reviewteam vormt vertrouwelijkheid de kern van de Gateway Review methode. Doordat de opdrachtgever het Gateway Review rapport niet openbaar maakt, loopt de opdrachtgever niet het gevaar dat hij verantwoording moet afleggen over de uitkomsten van het rapport. Ook voor geïnterviewden kan vertrouwelijkheid van belang zijn. Geïnterviewden zullen minder terughoudend vragen beantwoorden, als bekend is dat de opdrachtgever vertrouwelijk met de informatie omgaat. Als laatste heeft vertrouwelijkheid ook invloed op de reviewer zelf. Door de vertrouwelijkheid van het Gateway Review rapport komt de reviewer niet in een situatie waarin zijn adviezen en meningen als een oordeel gelezen worden waarover hij verantwoording zal moeten afleggen.

36

Naar aanleiding van rechtzaken die OGC in Engeland voert met de media66 over het openbaar maken van Gateway Review rapporten, zijn er aan de geïnterviewden vragen gesteld over het openbaar maken van Gateway Review rapporten en de gevolgen daarvan voor de Gateway Review methode in Nederland67. Het merendeel van de geïnterviewden is van mening dat openbaarmaking van Gateway Review rapporten op termijn niet te vermijden zal zijn. Voor bestuurders zal het niet openbaar maken van Gateway Review rapporten minimaal net zoveel schade opleveren als het wel openbaar maken van de rapporten. Ten aanzien van de openbaarmaking van de Gateway Review rapportages onderkent de heer Mollema (HEC), voor wat betreft de gevolgen welke de openbaarmaking zal hebben, twee situaties. De presentatie die het Reviewteam aan de SRO geeft en die onderdeel uit maakt van het reviewrapport, kan volgens de heer Mollema in beperkte kring gepubliceerd worden. Het betreft hier een zorgvuldig geformuleerde korte weergave van wat het reviewteam tijdens de review is tegengekomen. Het tweede deel van het Gateway Review rapport leent zich niet voor publicatie. Dit gedeelte van het review rapport bevat uitwerkingen, waaronder toelichtingen op de adviezen van het reviewteam. Deze uitwerkingen zijn beknopt geformuleerd en niet zelfstandig leesbaar. Hetgeen ook bijna onmogelijk is gezien de doorlooptijd van de review (4 á 5 dagen). Als oplossing voor de toekomst ziet de heer Molema een standaard te publiceren stuk.

Dat openbaarmaking van het reviewrapport (of een deel daarvan) consequenties zal hebben, daarover zijn de meeste geïnterviewden het eens. Het meest vergaande gevolg van openbaarmaking is de afbrokkeling van de gehele Gateway Review methode. In dit scenario zal de SRO strategisch gedrag gaan vertonen, omdat hij zich bewust is dat de Gateway Review methode door de openbaarmaking verworden is tot een verantwoordingsstuk. Met betrekking tot de geïnterviewden kunnen de gevolgen wellicht beperkt blijven, dit omdat de Gateway Review methode werkt met aantekeningen die niet te herleiden zijn naar individuele personen (in plaats van een bespreekverslag). Aan het eind van de review vernietigt de teamleider de aantekeningen.

Uit de openbaarmaking van de Gateway Review rapportage vloeit de vraag voort of de opdrachtgever de Gateway Reviewers en te interviewen personen, op de hoogte moet brengen van zijn intentie om de Gateway Review rapportages openbaar te maken. Om een review zuiver te houden is het noodzakelijk dat de reviewer en de geïnterviewde voorafgaand aan de review weten of de opdrachtgever de Gateway Review rapportages openbaar wil maken. Geeft de opdrachtgever dit niet voorafgaand aan de review aan, dan bestaat de kans dat de reviewers en geïnterviewden op voorhand terughoudend en strategisch gedrag gaan vertonen. Vorenstaande mede gebaseerd op de onzekerheid over de mogelijkheid dat de opdrachtgever de resultaten uit de Gateway Review openbaar maakt.

Met betrekking tot het openbaar maken van het Gateway Review rapport blijkt er bij de betrokkenen van het mGBA een andere, afwijkende, visie te zijn. Het functioneren in complete openheid, inclusief het openbaar

66 Zie voor nadere informatie over de openbaarmaking van Gateway Review rapporten in Engeland: Computer Weekly publishes 'secret' gateway review, 23 Feb 2009, www.computerweekly.com. 67Nadat de interviews gehouden zijn, heeft de Minister van BZK eind september 2009 , in een schriftelijke reactie op het eindverslag van de werkgroep ICT projecten binnen de overheid, aangegeven dat zij niet bereid is de resultaten van reviews op te nemen in haar periodieke rapportages (hiertoe had de werkgroep verzocht omdat zij het voor de commissies BZK en EZ van belang vindt om inzicht te krijgen in de bevindingen van de reviews). Hierbij merkt zij tevens op dat het Gateway Review rapport in principe alleen voor de opdrachtgever beschikbaar is. De opdrachtgever kan zelf bepalen om de Kamer te informeren over een Gateway Review.

37

maken van het Gateway Review rapport van Gateway Review 0 en de follow-up lijst met actiepunten en de manier hoe de programmaorganisatie rond de mGBA deze actiepunten wil aanpakken, stimuleert de programmaorganisatie om voldoende waarborgen in te bouwen om te zorgen dat het programma de gestelde planning en doelen haalt. De handelswijze bij mGBA staat haaks op de visie van één geïnterviewde die bij de vertrouwelijkheid van het Gateway Review rapport een vergelijking maakt met patiëntendossier welke een patiënt bij de dokter heeft. Hierbij trekt de geïnterviewde de vergelijking door en is hij van mening dat de patiënt minder open zal zijn bij de dokter wanneer de patiënt weet dat de dokter het patiëntendossier openbaar maakt. Met de vergelijking benadrukt de geïnterviewde de onwenselijkheid van het openbaar maken van een Gateway Review rapport.

4.1.3. Gateway Review en project auditing Op de vraag wat de Gateway Review kan betekenen voor project auditing antwoordt de heer Mollema: ”Wat kan een koe voor een auto betekenen? Een koe kan toch tegen een auto aanlopen”. Vorenstaande geeft aan dat, volgens de heer Mollema, projectaudits en Gateway Reviews eigenlijk niets voor elkaar kunnen betekenen. Dit omdat de Gateway Review methode niet kwalificerend is, het gaat niet om norm en uitkomst en er wordt geen uitspraak gedaan in de vorm van een oordeel, maar een status. De opdrachtgever en de projectorganisatie krijgt door middel van de Gateway Review methode een spiegel voorgehouden over de effectiviteit van handelen in relatie tot de stappen die hij wil nemen. Anders gezegd de Gateway Review methode bevindt zich op een ander vlak dan de reguliere audit. Bij de Gateway Review wil je de opdrachtgever helpen met vragen als: wat zijn je zorgen, kunnen we je helpen? Waarmee wil je dat het Gateway Review team je helpt? Een kenmerk van de Gateway Reviews zijn gesprekken zonder angst waarbij vrijuit gesproken kan worden tussen reviewers enerzijds en opdrachtgever en andere geïnterviewden anderzijds. Bij een Gateway Review bepaalt de opdrachtgever in belangrijke mate de scope van de review, in overleg met de teamleider van het reviewteam.

Anderen zijn van mening dat de auditor de uitkomsten van een Gateway Review kan gebruiken bij een projectaudit en vice versa. Hierbij merken zij nadrukkelijk op dat de Gateway Review methode geen echte audittool is en dat een audittrail, ter onderbouwing van de conclusies ontbreekt. Daarnaast kan het, volgens een geïnterviewde, voorkomen dat de opdrachtgever in het kader van de vertrouwelijkheid weigert om het Gateway Review rapport te verstrekken aan de auditdienst.

Afwijkend van bovenstaande opvattingen is één geïnterviewde van mening dat de Gateway Review een daadwerkelijke audit is, de normen zijn te vinden in de praktijkervaring die de reviewers meenemen en de best practise handboeken van OGC. De normen zijn wel minder hard dan de normen die een auditor normalitair bij een reguliere audit gebruikt. Hierbij maakt de geïnterviewde de kanttekening dat de normen bij een normale audit hard zijn, maar dat tussen de norm, de uitleg van de norm en de toepassing van de norm een wereld van verschil kan zitten.

4.1.4. Andere aspecten met betrekking tot de Gateway Review methode Kijkend naar de verschillen tussen Engeland en Nederland dan valt op dat in Nederland de Gateway Review methode slechts tot ontwikkeling is gekomen bij IT projecten, daar waar opdrachtgevers in Engeland een grote diversiteit van projecten onderwerpen aan de Gateway Review methode. De insteek die HEC gekozen heeft, verklaart het verschil. Met de Gateway Review methode heeft HEC zich allereerst

38

gericht op IT projecten binnen de overheid. In de toekomst zal HEC ook andere gebieden (zoals de bouw), waarbinnen grote overheidsprojecten plaatsvinden, aanboren om te kijken of de Gateway Review methode toegevoegde waarde kan hebben. Om een indruk te krijgen hoeveel Gateway Reviews in Nederland tot op heden zijn uitgevoerd, is aan HEC een inventarisatie van de reviews gevraagd. In Nederland zijn er door HEC 20 Gateway Reviews uitgevoerd over de periode 2007 tot en met september 2009. Daarnaast heeft het Gateway-bureau inmiddels 3 Gateway Reviews georganiseerd. De door HEC begeleidde reviews, zijn als volgt over de verschillende soorten Gateway Reviews verdeeld:

Soort Gateway Review Aantal Gateway Review 0 6 Gateway Review 1 4 Gateway Review 2 4 Gateway Review 3 2 Gateway Review 4 2 Gateway Review 5 0 Health checks68 2 Totaal 20 Opvallend is, dat er vooralsnog geen Gateway Review 5 in Nederland is uitgevoerd, volgens HEC komt deze situatie overeen met de situatie in Engeland waar OGC ook slechts sporadisch een Gateway Review 5 verricht. Waarschijnlijk houdt dit verband met het in paragraaf 2.4.3. getoonde verband tussen een bepaalde Gateway Review en de mogelijkheid om waarde te genereren door aanpassingen aan het project aan te brengen. Dit zou tevens een verklaring kunnen zijn voor het feit dat tot op heden Gateway Review 0 het meest is uitgevoerd. De geïnterviewde medewerkers van HEC bevestigen dat met name Gateway Review 0 van groot belang kan zijn voor de kansen op succes bij een project.

In paragraaf 2.4.2. is nader ingegaan op de voor en nadelen van de Gateway Review methode. Aan de hand van de gehouden interviews zijn de in paragraaf 2.4.2. genoemde voor- en nadelen van de Gateway Review methode verder uit te bereiden. Voordelen van de Gateway Review methode zijn: •

De Gateway Review methode is simpel en doelgericht;

•

De uitvoering van de methode, tijdens de week zelf, levert al een bijdrage doordat binnen de projectorganisatie medewerkers praten en nadenken over hoe zij dingen aanpakken;

•

De methode brengt partijen dichter bij elkaar en zorgt voor het kweken van gezamenlijk begrip;

•

De methode heeft aanleiding gevormd bij auditdiensten om zelf ook over de kaders van hun eigen audittools te kijken en tools te ontwikkelen voor de opdrachtgever zodat deze al in een vroeg stadium zekerheid krijgt over de gang van zaken bij zijn programma of project.

Nadelen die naar bovengekomen zijn door de interviews: •

Tussen twee Gateway Reviews kunnen soms maanden zitten, dit houdt in dat bijsturing soms (te) lang op zich laat wachten;

•

Wanneer een reviewteam Gateway Review 0 uitvoert, is er al een programma aanwezig, eigenlijk is deze review te laat in het proces en zou het reviewteam eerder een review moeten verrichten op de fase waarin het programma vorm krijgt69;

68 Health checks, verschillen in hoofdlijnen niet van Gateway Reviews, wel zien ze op een breder terrein dan Gateway Reviews op programma niveau. Daarnaast duurt de uitvoering van Health checks langer en zijn ze meer gericht op de middelen voor het project. 69 OGC heeft ook een Starting Gateway ontwikkeld. Dit is een korte onafhankelijke review op de fase waarin er nog geen sprake is van een programma.

39

•

De opdrachtgever kan de Gateway Review gebruiken voor een oneigenlijk doel, bijvoorbeeld ter onderbouwing van een al geplande vervanging van een programmamanager;

•

In theorie is het punt wanneer de opdrachtgever de Gateway Review methode moet inzetten duidelijk. De werkelijkheid is weerbarstiger, een opdrachtgever dient een Gateway Review ver voor de afronding van een projectfase al te plannen, dit omdat alle reviewers hun agenda voor één week vrij moeten maken en dit laatste is moeilijk adhoc te realiseren. Ook kan het in werkelijkheid moeilijk zijn om duidelijke projectfases te onderkennen binnen een project.

•

Gateway Reviewers leggen in Nederland geen verantwoording af over de conclusie die zij bij een review trekken en de adviezen die ze geven in hun reviewrapporten.

•

De kans is groot dat de Gateway reviewers onvoldoende bekend zijn met de organisatie en haar processen.

•

De Gateway Review methode gaat voorbij aan het (beoordelen van het) voldoen aan wet- en regelgeving en de kwaliteitsaspecten beschikbaarheid, integriteit van gegevens en vertrouwelijkheid.

Aan de deskundigen op het gebied van de Gateway Review is gevraagd welke zwaktes ze onderkennen bij de Gateway Review methode. Als zwakte bij de Gateway Review methode noemen de geïnterviewden het gevaar dat er te eenzijdig informatie verstrekt wordt aan het reviewteam. Daarnaast bestaat de kans dat het reviewteam haar rol niet goed kan vervullen door een gebrek aan de voor de review gewenste kwaliteiten bij het reviewteam. Er ontstaat ook een zwakte wanneer men elkaar gaat sparen binnen de Gateway Review methode. Dit is een reëel risico dat mede voortkomt uit het feit dat de wereld van de overheidsprogramma’s en projecten klein is, waardoor programmamanagers, opdrachtgevers en projectleiders elkaar nagenoeg allemaal kennen uit eerdere samenwerkingsverbanden. Een van de geïnterviewden onderkende zelfs een carrousel van personen die dan weer eens bij het Ministerie van BZK werken en dan weer bij ICTU of HEC werken. De geïnterviewde had er de nodige moeite mee dat dergelijke personen toch zitting konden hebben in een reviewteam dat een project reviewed waarbij het Ministerie van BZK en/of het ICTU een rol speelt. Vanuit de praktijk noemen geïnterviewden ook het gebrek aan operationele ondersteuning voor de reviewers als een tekortkoming gezien.

Een probleem dat kan gaan optreden bij veelvuldig gebruik van de Gateway Review methode, vormt de vijver waaruit de Gateway organisatie de reviewers vist. In paragraaf 4.1.1. is al kort ingegaan op de effecten van het inhuren van marktpartijen voor het leveren van reviewers. Goede onafhankelijke reviewers vinden kan een probleem worden. De Gateway organisatie zoekt reviewers met een ambtelijke- , persoonlijke- en maatschappelijke status welke overeenkomt met de status van de opdrachtgever. In het bijzonder het verkrijgen van teamleiders voor de reviewteams kan een knellende factor vormen. Het gaat hier meestal om bestuurders en directeuren binnen departementen. Deze personen kunnen naar alle waarschijnlijkheid hooguit 2 reviews per jaar uitvoeren (gezien de vereiste om zich een hele week vrij te maken van afspraken). Ex (gepensioneerde) overheidsbestuurders kunnen de leemte die ontstaat door een tekort aan reviewers invullen, volgens één van de geïnterviewden. Een ander optie, om gebruik te maken van auditors van de Rijksauditdienst, ondersteunen de meeste geïnterviewden niet. Het gaat bij de Gateway Review om bestuurlijke en beleidsmatige vraagstukken welke het reviewteam interpreteert en in een bepaald kader plaatst. Hiertoe is de auditor van de Rijksauditdienst niet opgeleid en op dit vlak

40

ontbreekt het hem meestal ook aan ervaring. Daarnaast zitten de auditors niet op het gelijke niveau als de opdrachtgever, wat de acceptatie van de conclusies uit een Gateway Review ook bemoeilijkt. Enkele geïnterviewden zien wel een meerwaarde in de aanwezigheid van een auditor in een reviewteam. De meerwaarde zien deze geïnterviewden met name in de specifieke kennis en ervaring die auditors hebben. Hierbij valt te denken aan de geleerde interviewtechnieken van de auditor en de vaardigheid om (financiële en organisatorische) situaties te doorgronden. De vaktechnisch boeiende vraag of een Register Edp auditor of een Register Accountant vanuit zijn gedrags- en beroepsregels mag deelnemen aan een Gateway Review is niet gesteld aan de geïnterviewden omdat de vraag buiten de reikwijdte van deze scriptie ligt. Ter voorkoming van een tekort aan reviewers, leidt de Gateway-organisatie maandelijks 15 nieuwe reviewers op bij de Rijksacademie voor Financiën en Economie. Formeel huldigt de Gateway-organisatie het standpunt dat deelname van externen aan een review slechts geschiedt wanneer er bepaalde kennis binnen de overheid niet aanwezig is dan wel dat de aanwezige experts binnen de overheid onvoldoende onafhankelijk zijn.

Een boeiend element van de Gateway Review methode is de doorlooptijd van een Gateway Review. Deze doorlooptijd bedraagt 4 tot 5 dagen. Hierbij is de vraag aan de geïnterviewden voorgelegd, hoe zij de doorlooptijd zien, in het licht van de sterk verschillen tussen programma’s en projecten voor wat betreft de complexiteit, hoeveelheid betrokken partijen en de omvang. De kern van het antwoord van de geïnterviewden komt erop neer dat er bij grote projecten en programma’s een andere organisatorische structuur aanwezig is dan bij kleinere programma’s en projecten. Hierdoor steekt het reviewteam de Gateway Review op een ander manier en niveau in. Tevens gaat het reviewteam uit van de aanname dat het met de kennis en kunde wel goed zit binnen een project of programma.

Belangrijk bij de uitvoering en naleving van de procedures rond de Gateway Review methode is de Gateway-organisatie. Voorafgaand aan de review beoordeelt de Gateway-organisatie of zij kan voldoen aan het verzoek van een opdrachtgever om een Gateway Review uit te voeren, dit gebeurt aan de hand van een intake gesprek. Vervolgens stelt de Gateway-organisatie het reviewteam samen, in overleg met de opdrachtgever. Wanneer het reviewteam de Gateway rapportage oplevert, beoordeelt de Gatewayorganisatie de rapportage op formele punten, zoals de herleidbaarheid naar individuele personen in de rapportage. Daarnaast gaat de Gateway-organisatie enkele weken na de review het review proces evalueren met de opdrachtgever en de teamleider van het reviewteam. Daarbij kijkt de Gateway-organisatie ook of de opdrachtgever de adviezen inhoudelijk begrepen heeft en hoe de opdrachtgever invulling aan de adviezen gegeven geeft.

De Minister van BZK heeft op 8 oktober 2009 besloten dat er bij grote projecten verplicht reviews dienen plaats te vinden. Dit hoeven echter geen Gateway Reviews te zijn, maar kunnen ook andere methoden zijn die vallen binnen de door de Minister gestelde voorwaarden, zoals uiteengezet in paragraaf 2.2.1. Om meer inzicht te krijgen in de keuze van de Minister voor het niet verplicht stellen van de Gateway Review methode is de geïnterviewden de vraag gesteld wat de beweegredenen zouden kunnen zijn om de Gateway Review methode niet verplicht te stellen. Volgens één van de geïnterviewden zou de reden om af te zien van het verplicht stellen van de Gateway Review methode gelegen kunnen zijn in de wens van de Minister van BZK om niet verantwoordelijk te worden voor diverse grote ICT-projecten. Als de Minister van

41

BZK instrumenten voorschrijft om een project te beheersen, neemt ze ook verantwoordelijk voor de uitvoering van het project. Wat de Minister eigenlijk wilde zeggen tegen de opdrachtgevers van grote ICTprojecten is: “Ik wil dat je kritisch naar je eigen project kijkt”. Daarnaast doet het verplicht stellen van audittools geen recht aan de pluriformiteit van projecten.

4.2. Beheersing op het GMV programma in relatie tot de Gateway Review methode Om te kijken welke effecten de Gateway Review methode zou kunnen hebben op het GMV programma is er een interview gehouden met de heer Bronkhorst, van BZK, die optreedt als ambtelijke opdrachtgever en de heer During van ICTU, die programmamanager op het GMV programma is. Bij de vragen aan genoemde heren heb ik als basis de in paragraaf 2.3.1. tot en met paragraaf 2.3.6. genoemde onderwerpen naar voren laten komen. Volledigheidshalve merk ik op dat de heren Bronkhorst en During niet bij de start van het programma in functie waren. De heer During heeft medio 2008 een andere programmamanager vervangen op het GMV programma en de heer Bronkhorst is sinds ongeveer een half jaar betrokken bij het GMV programma. Ter indicatie van de grootte van het programma is te melden dat de kosten van het GMV programma momenteel een omvang hebben van tussen de € 10-15 miljoen. Het GMV programma heeft zich voornamelijk gebaseerd op de eisen en wensen van de Belastingdienst ten aanzien van de voorziening. Bij de bouw van de voorziening is niet gekeken naar de wens van andere partijen, zoals gemeenten en ministeries. Een gevolg hiervan is dat GMV een generieke voorziening is, die volgens de geïnterviewden mogelijk niet voldoet aan alle wensen van iedere overheidsorganisatie.

Uit de gesprekken met de beide heren blijkt dat er ten aanzien van GMV oorspronkelijk een business case is opgesteld. Deze business case is niet meer bijgewerkt en dient ook niet meer als basis voor de huidige werkzaamheden aan het GMV programma. Een business case was niet direct noodzakelijk volgens de geïnterviewden, omdat er een noodzaak bestond voor een machtigingsvoorziening. De noodzaak ontstond in 2007 door het advies, van de Belastingdienst aan personen die zonder DigiD elektronisch aangifte Inkomstenbelasting wilden doen, om de DigiD van de buurman te gebruiken. Aangezien ministeries een oplossing wilden voor het uitlenen van de DigiD, speelden de kosten van het realiseren van de voorziening een minder belangrijke rol. Stappen, zoals het actualiseren van een business case, zijn volgens de geïnterviewden niet altijd gevolgd, dit komt omdat het logisch nadenken voorop staat en de programmaorganisatie stappen alleen volgt wanneer dit waarde toevoegt.

De opdrachtgever wil absolute transparantie van zijn opdrachtnemer en vindt dat de opdrachtgever deze transparantie ook terug dient te geven. Een voorbeeld van deze transparantie is de mogelijkheid voor de opdrachtgever om op ieder willekeurig moment in administratie te kunnen kijken van de opdrachtnemer, deze administratie dient actueel te zijn, zodat er een duidelijk beeld is van de financiële toestand van het project. Anderzijds moet de opdrachtgever ideeën over aanpassingen en veranderingen in een project direct door spreken met de opdrachtnemer. BZK heeft bij het GMV programma niet gevraagd om zekerheden, welke zij kan verkrijgen door de audit’s, reviews of contra-expertises. Wel zijn er binnen het GMV programma zelf onafhankelijke instanties ingezet voor penetratietesten en performance testen. TNO heeft het informatiebeleid met betrekking tot het GMV onderzocht. De rapportages van de uitgevoerde onderzoeken heeft de projectleider ook beschikbaar

42

gesteld aan de opdrachtgever. Als laatste zal er bij de overgang van GMV naar GBO Overheid als beheerder een acceptatietest plaatsvinden door GBO Overheid.

Op het gebied van het identificeren en analyseren van risico’s is er bij het GMV project in 2008 een risicoanalyse uitgevoerd. Over de uitkomsten van de analyse weet de huidige programmamanager geen details, de risicoanalyse is uitgevoerd onder zijn voorganger. Ook is er in 2008 door een onafhankelijke externe partij een Afhankelijkheid en Kwetsbaarheidanalyse uitgevoerd op het GMV programma. In 2009 zijn er geen risicoanalyses uitgevoerd op het GMV programma. Een mechanisme voor het beoordelen van een projectfase, nadat deze gereed is, of het project gereed is om naar de volgende fase te gaan, is bij het GMV programma niet aanwezig.

Processen en procedures rond aanbestedingen, welke in diverse fasen binnen de Gateway Review methode een prominente rol spelen zijn ook te onderkennen bij het GMV programma. Voorafgaand aan de aanbesteding is er bij het GMV programma een keuze gemaakt voor het bouwen van de voorziening via een iteratieve methode. Dat wil zeggen dat programmaorganisatie eerst een stuk software laat bouwen en hierop voortborduurt bij de verdere bouw van software. De bouw van de voorziening volgens de iteratieve methode is één (van de) reden(en) om niet de gehele bouw van de voorziening uit te besteden en slechts te sturen op de producten die het GMV programma moet voortbrengen. Deze laatste optie, om de gehele bouw van de voorziening uit te besteden, past wel binnen de visie van de programmamanager om de markt te laten doen wat de markt kan doen en om op geen enkele wijze in concurrentie te treden met de markt.

Procedures rond inhuur van extern personeel begeleidt en bewaakt het inkoopbureau van het ICTU. In eerste instantie kijkt het inkoopbureau van het ICTU welke mantelovereenkomst van toepassing is. Deze mantelovereenkomsten bieden een mogelijkheid om snel in contact te komen met de markt. Vanuit de mantelovereenkomst vraagt het inkoopbureau conform de procedure een aantal offertes aan. Met de partijen, die een offerte uitbrengen, vindt een gesprek plaats waarna het ICTU een keuze maakt. In de mantelovereenkomsten zijn de maximale tarieven vastgelegd die de dienstverleners in rekening mogen brengen. Voorzover bekend bij de programmamanager, vinden er op het aanbestedingstraject geen externe audits of ander vormen van externe monitoring plaats.

Omdat hij, door de tussenkomst van ICTU, op afstand staat van de daadwerkelijke marktpartijen die door middel van aanbesteding de softwareontwikkeling gaan doen, vindt de opdrachtgever het belangrijk dat hij een plaats heeft in het aanbestedingsteam en dat hij bestekken inziet.

Bij de Gateway Review methode is kwaliteit binnen een programma een onderwerp dat aan bod komt, dit blijkt ondermeer uit een vraag als: Zijn er procedures gebruikt welke de kwaliteit binnen het project moeten waarborgen (zie ook bijlage 9)? Navraag leert dat er geen kwaliteitsplan voor het GMV programma is. Wel stuurt ICTU bij het programma op de kwaliteit van de ingehuurde mensen. Dit werkt goed, het is volgens de geïnterviewden niet bekend of ICTU deze manier van sturing ook richting de aanbieder formaliseert. Daarnaast wordt de kwaliteit van de opgeleverde voorziening beoordeeld door de pilots, die plaatsvinden voordat de programmaorganisatie de voorziening operationeel uitzet. Bij andere programma’s en projecten, die gebeuren onder het opdrachtgeverschap van BZK, wordt op de software ook nog een onafhankelijke

43

(kwaliteits) audit of review gedaan, dit is bij GMV niet gebeurd. Los van het GMV programma onderkent de opdrachtgever dat de overheid bij ICT-projecten soms (te) weinig stuurt op kwaliteit.

Belangrijk in de Gateway Review methode is de mate waarin betrokkenen een project dragen. Vanuit deze invalshoek is gekeken naar de financiering van het GMV programma. Zoals in hoofdstuk 3 aangegeven financiert BZK het programma zelf. Met betrekking tot de financiering van overheidsprogramma’s en projecten in de operationele fase zijn er twee mogelijkheden. Allereerst kunnen deelnemers aan het programma wachten met de bouw van een voorziening totdat financiering voor de operationele fase geregeld is. Als tweede mogelijkheid kunnen deelnemers aan het programma er voor kiezen om het programma te starten en om in een latere fase te bepalen wie wat gaat bijdragen aan de kosten in de operationele fase van het programma. Bij het GMV programma is ervoor gekozen om eerst de voorziening te bouwen en vervolgens te kijken wie de (vaste) kosten tijdens de operationele fase van de voorziening wil betalen. Doordat betrokken partijen de financiering van de operationele fase van GMV voorafgaand aan de start van het programma niet regelden, is er een onzekere situatie ontstaan. Lange tijd heeft het bij betrokken partijen aan eenstemmigheid ontbroken over de financiering van de operationele fase van de GMV. Dit terwijl de GMV voor wat betreft de daadwerkelijke ontwikkeling bijna klaar was. Per december 2009 is de financiering van de operationele fase van de GMV geregeld. Enige vertraging binnen het GMV programma is ontstaan doordat bij de Belastingdienst vertraging is ontstaan bij de start van pilots.

Los van het GMV programma, is de opdrachtgever van mening dat de overheid moet waken voor het te dicht willen regelen van programma’s en het willen loslaten van te veel audit’s op programma’s. Als politici en bestuurders alle risico’s willen uitsluiten ontstaat er een ongekend audit bolwerk op programma’s en projecten waarbij de voortgang van programma’s en projecten in gevaar kan komen. Het is beter om vooraf goed te kijken of een programma of project moet worden gestart en daarvoor voldoende voorbereidingstijd te nemen dan snel te beginnen en te trachten via reviews greep te houden.

Ten aanzien van het GMV programma zien de geïnterviewden, gegeven de voortgang, niet direct een grote toegevoegde waarde in de toepassing van de Gateway Review methode. Vorenstaande vloeit voort uit het feit dat het GMV programma op orde is en binnen de planning loopt. Per 31 december 2009 is het GMVsysteem feitelijk opgeleverd en kan het als DigiD-Machtigen in bedrijf worden genomen.

4.3. De Gateway Review methode bij het mGBA programma Bij het mGBA programma is een Gateway Review 0 uitgevoerd. Deze review, die is uitgevoerd in één week (27 oktober 2008 tot en met 30 oktober 2008), kende zoals een van de geïnterviewden kort en bondig formuleerde, als hoofdvraag: Is alles klaar voor de herstart van het mGBA programma? Na het onderzoek heeft het reviewteam geconcludeerd dat het mGBA programma niet klaar was voor een overall besluit over de herstart van het programma. Dit heeft het reviewteam met een aantal als urgent te bestempelen issues onderbouwd. Issues als het feit dat de betrokkenen bij het programma geen gedeeld beeld van de doelstellingen van mGBA hebben, er geen gedeeld beeld over de scope van het programma is en dat duidelijk moet zijn dat de beschreven scenario’s niet tot hetzelfde resultaat leiden, vormen reden voor het reviewteam om geen groen licht te geven voor de doorstart voor het programma.

44

Om de invloed te bekijken die de Gateway Review methode gehad heeft op het mGBA programma zijn, naast diverse interviews met onder andere de programmamanager en een kwaliteitsbewaker, ook diverse programmadocumenten doorgenomen van het mGBA programma. Tot deze programmadocumenten behoren ook het Gateway Review rapport en het ‘Overzicht met aanbevelingen Gateway Review en opvolging door BZK’ welke publiekelijk toegankelijk zijn via het internet.

Ten aanzien van de openbaarmaking van programmadocumenten en speciaal de Gateway Review rapportage geven de geïnterviewden aan dat dit een bewuste keuze geweest is. Een van de redenen om alles openbaar te maken is de veronderstelling bij de geïnterviewden dat alles toch wel op de een of ander manier in de openbaarheid komt, dan kun je er beter zelf voor kiezen om openheid van zaken te geven. Daarnaast betekent werken in volledige openbaarheid een stimulans om het programma goed uit te voeren en (kwaliteits)waarborgen in te bouwen om te voldoen aan de eisen zoals gesteld in het programmaplan.

Om een beeld te krijgen van de toegevoegde waarde van de methode is geïnterviewden gevraagd of de uitkomsten van Gateway Review 0 verrassend waren. Gateway Review 0 heeft volgens de geïnterviewden niet tot verrassende conclusies geleid. Andere rapportages van onderzoeken onderbouwen dit. Zo heeft de auditdienst van BZK in haar auditrapport van 8 november 2007 geconstateerd dat er een nieuwe business case moest komen met betrekking tot BZS-K. Reden hiervoor was het feit dat de oude business case en opgestelde specificaties te veel ruimte lieten voor discussies over de scope. Het Gateway Review team geeft in haar rapport met betrekking tot BZS-K aan dat er geen gedeeld beeld over BZS-K is, dit geldt in het bijzonder als het gaat om de inhoud en over de realisatie van alternatieven. Geconcludeerd kan worden dat de problematiek rond BZS-K al in 2007 bekend was en in 2008 door middel van de Gateway Review rapportage nog eens benadrukt is. Vorenstaande is een belangrijke bijdrage die de methode levert, het nog eens voor het voetlicht van de opdrachtgever en opdrachtnemer brengen van bepaalde aandachtspunten en problemen. Waardoor de partijen min of meer verplicht zijn om de door het Gateway Review rapport onder de aandacht gebrachte punten op te pakken. Een van de bijdragen die de methode geleverd heeft, is het feit dat vanuit de betrokken partijen belangrijker functionarissen toegewezen zijn aan de diverse overleg- en besluitvormingsstructuren zoals deze voor het mGBA programma aanwezig zijn.

Naar aanleiding van het openbaar maken van het ‘Overzicht met aanbevelingen Gateway Review en opvolging door BZK’ is de geïnterviewden gevraagd hoe, na publicatie van de lijst op internet, is omgegaan met de lijst. Uit de interviews blijkt dat de programmaorganisatie nog steeds met een dergelijke lijst werkt, waarbij opgemerkt dat de interne follow up lijst er anders uitziet dan de lijst op internet. De interne lijst bestaat uit issues, afhankelijkheden en risico’s. Issues zijn onderwerpen die boven komen drijven en aandacht nodig hebben. Afhankelijkheden zijn te splitsen in interne- en externe afhankelijkheden. Een voorbeeld van een interne afhankelijkheid is het LO4 dat niet in de pas loopt met de planning. Bij externe afhankelijkheden valt te denken aan andere e-overheidsprogramma’s welke gerelateerd zijn aan mGBA. Risico’s, het laatste onderwerp op de interne lijst, onderkent de programmaorganisatie vanuit onder andere audits en reviews. De interne follow up lijst heeft een dynamisch karakter, er komen steeds nieuwe items bij en wanneer een item is afgedaan, voert de programmaorganisatie het item weer van de lijst af.

Terugkomend op het ‘Overzicht met aanbevelingen Gateway Review en opvolging door BZK’ blijkt dat alle

45

aanbevelingen die de kwalificatie kritisch en essentieel hebben gekregen, verwerkt zijn in het programmaplan, definitiestudie en/of de business case. Hieruit valt af te leiden dat de opdrachtgever, BZK, de aanbevelingen van Gateway Review 0 serieus ter hand heeft genomen. Een voorbeeld van een aanbeveling die overgenomen is, betreft de volgende aanbeveling70: “Houd doelstellingen en scope opnieuw tegen het licht en stel ze dan vast in overleg met alle partijen”. In de nieuwe definitiestudie71 komt de vraag aan bod of de oorspronkelijke doelstelling en scope nog helemaal adequaat is. Vanuit de vraagstelling gaat de definitiestudie nader in op veranderingen die leiden tot de bijstelling van doelstellingen. Voorbeelden die naar voren komen zijn plaatsonafhankelijk dienstverlening door gemeenten en gewenste afspraken over standaardisatie en de samenhang binnen e-overheid. Deze nieuwe doelen zijn ook, conform de aanbeveling van de Gateway Review 0, duidelijk vastgelegd. Dit is onder meer gebeurd in een bestuurlijk Akkoord tussen het Ministerie van BZK en de VNG.

Eén van de geïnterviewden was van mening dat niet alle, in het Gateway Review rapport bij Gateway Review 0, getrokken conclusies juist zijn. Hierbij doelde de geïnterviewde op onder andere de conclusie over het gebrek aan het gedeelde beeld bij de betrokkenen over de doelstellingen van mGBA en de scope van het programma. Daar de documentatie, zoals de aantekeningen van de tijdens Gateway Review 0 gehouden interviews, door de teamleider vernietigd is, valt de getrokken conclusie van het Gateway Review team niet te verifiëren. Dat vorenstaande constatering over een onjuist advies welke het Gateway reviewteam geeft in haar rapportage niet op zich zelf staat blijkt uit de opmerkingen van een andere geïnterviewde. Bij één van de eerste in Nederland uitgevoerde Gateway Reviews, bleek volgens de opdrachtgever achteraf dat het gegeven advies aantoonbaar onjuist was72.

Gateway Reviews vinden bij het mGBA, zoals weergegeven in paragraaf 2.2.2., op programmaniveau plaats. Volgens de geïnterviewden is gekozen voor de uitvoering van de Gateway Review methode op programmaniveau omdat het bij mGBA gaat om de voortgang van het programma en daarbij speelt het geen rol dat de onder het programma hangende projecten zich in verschillende voortgangsstadia bevinden. Op projectniveau voert de programmaorganisatie zelf een soort Gateway Review uit. Naar verwachting zal een Gateway reviewteam in januari 2010 Gateway Review 1 uitvoeren. De scope van deze review en de daarop volgende reviews binnen het mGBA programma bepaalt de opdrachtgever. De opdrachtgever betracht een open structuur bij de vaststelling van de scope van de review, waarbij de programmamanager ook kan aangeven welke onderwerpen hij van belang vindt voor de review.

In diverse publicaties wordt gesuggereerd dat de programmaorganisatie het mGBA programma in 2010 afrondt. Niets blijkt minder waar, thans hebben de geïnterviewden 2015 genoemd als jaar waarin het gehele programma afgerond kan zijn. Wel zullen onderdelen van het programma in de jaren tussen 2010 en 2015 de operationele fase bereiken. Afsluitend constateerden de geïnterviewden dat Gateway Review 0 een wezenlijke bijdrage heeft geleverd om te komen waar het programma nu staat.

70 Overgenomen uit mGBA Rapport Gateway Review 0 – Strategische Assessment, Versie nummer: Concept 0.96, bladzijde 4. 71 Zie ook ‘een moderne GBA mogelijk gemaakt…’ Herijking van oorspronkelijke definitiestudie, versie 2.0, 28 april 2009, bladzijde 4 en 5. 72 In onderhavig geval verklaarde de geïnterviewde het onjuiste advies door te kijken naar het reviewteam. Daarbij constateerde de geïnterviewde een gebrek aan onbevooroordeeldheid in het reviewteam. Het reviewteam stond, volgens de geïnterviewde/opdrachtgever, te weinig onbevangen tegenover de betrokken partijen (ondermeer omdat teamleden bij een of meerdere van de bij het programma betrokken partijen tot voor kort al eens gewerkt hadden).

46

5. Conclusie en Aanbevelingen Hoofdstuk 5 begint met de conclusie (paragraaf 5.1.). In deze conclusie wordt op basis van de literatuurstudie en gehouden interviews antwoord gegeven op de hoofdvraag van deze scriptie. Tevens komen de andere vragen uit paragraaf 1.4. in de conclusie aanbod, dit met uitzondering van de vraag: ‘Welke verbeterpunten zijn er te onderkennen bij de praktische toepassing van de Gateway Review methode ten behoeve van het verschaffen van zekerheden?’. Laatstgenoemde vraag kent zoveel overlapping met een aantal aanbevelingen die voortvloeien uit het onderzoek, dat besloten is om deze vraag te beantwoorden in paragraaf 5.2. ‘verbeterpunten en aanbevelingen’. Bij de aanbevelingen heb ik ervoor gekozen om me niet te beperken tot de Gateway Review methode maar ook aanbevelingen te doen op het bredere vlak van project- en programmabeheersing.

5.1. Conclusie Een in Nederland relatief nieuw instrument bij de beheersing van ICT-projecten binnen de overheid, de Gateway Review methode, is het onderwerp van deze scriptie. In hoofdstuk één van deze scriptie is de keuze voor de Gateway Review methode als scriptieonderwerp gemotiveerd door middel van voorbeelden van mislukte ICT-projecten binnen de overheid (paragraaf 1.2.). In hoofdstuk twee van deze scriptie heb ik uitvoerig aandacht besteed aan het theoretisch kader van de Gateway Review methode. Dit om de bevindingen welke uit het praktijkonderzoek (hoofdstuk vier) naar voren komen in een juist perspectief te kunnen plaatsen. Na hoofdstuk twee zijn er in hoofdstuk drie een tweetal ICT-programma's van de overheid nader uiteengezet. Met behulp van deze ICT-programma’s heb ik in hoofdstuk vier van deze scriptie bekeken wat de Gateway Review methode betekend heeft bij de programma's, dan wel betekend zou kunnen hebben bij de programma's.

In hoofdstuk één (paragraaf 1.4. ‘centrale vraagstelling’) heb ik de hoofdvraag geformuleerd die ik met behulp van de scriptie wil beantwoorden. De hoofdvraag, “verschaft de Gateway Review methode, vanuit de optiek van IT auditing, voldoende zekerheden aan de opdrachtgever bij het realiseren van grootschalige complexe IT projecten?”, herbergt een aantal deelvragen. Deze deelvragen zijn: •

Wat wordt verstaan onder IT auditing?

•

Wat wordt bedoeld met voldoende zekerheden aan de opdrachtgever?

IT auditing is in deze scriptie gedefinieerd als:“Het beoordelen van, dan wel adviseren over één of meer kwaliteitsaspecten van (onderdelen van) de informatie omgeving waar wordt gebruikgemaakt van informatietechnologie”. In de definitie dient “beoordelen” opgevat te worden als het toetsen aan normen. Een vrije vertaling van “voldoende zekerheden aan de opdrachtgever”, is dat de opdrachtgever naar aanleiding van de Gateway Review een gefundeerde beslissing durft te nemen om een project of programma al dan niet door te laten gaan naar de volgende project- of programmafase.

Vanuit de optiek van IT auditing verschaft de Gateway Review methode geen zekerheden. Dit wordt zowel vanuit de theorie als vanuit de praktijk onderbouwd. De theorie sluit de Gateway Review methode onder meer uit omdat de methode geen gebruik maakt van expliciete normen maar van werkboeken waarin best practices zijn vastgelegd. Uit de gehouden interviews ontstaat het beeld dat de geïnterviewden de Gateway Review methode niet zien als iets dat vanuit een IT auditing perspectief te benaderen is. Juist de kracht van

47

de Gateway Review methode zit erin dat het een ander pad bewandelt dan IT auditing. Peers treden op als sparringpartner van de opdrachtgever. Hierbij speelt vertrouwelijkheid een grote rol. In principe wordt het Gateway Review rapport niet openbaar gemaakt en vernietigt de teamleider van het reviewteam de verzamelde dossierstukken. Een groot aantal geïnterviewden vindt dat er terughoudend dient te worden omgegaan met het opnemen van IT auditors in het Gateway Review team, anders wordt de kans gelopen dat de Gateway Review methode haar eigen unieke kwaliteiten verliest. Dat wil zeggen met een andere pet op, die van collega bestuurder of deskundige, kijken naar een project.

Een geheel andere, lastig te beantwoorden, vraag is: “Levert de Gateway Review zekerheden voor de opdrachtgever op?” Het ligt voor de hand om deze vraag direct met ja te beantwoorden. Echter niet alle geïnterviewden onderschreven dit. Het antwoord op de vraag of de Gateway Review methode zekerheden oplevert, hangt af van de duiding van de uitkomsten van het Gateway Review rapport. Vanuit de richting dat de Gateway Review methode niet kwalificerend is omdat het niet gaat om norm en uitkomst en omdat de Gateway Review methode geen uitspraak doet in de vorm van een oordeel, is de stelling te verdedigen dat de opdrachtgever geen zekerheid aan de Gateway Review methode kan ontlenen. Het merendeel van de geïnterviewden onderkent echter wel dat de opdrachtgever zekerheid kan ontlenen aan de Gateway Review methode. De Gateway Review methode verschaft zekerheid aan de opdrachtgever over de mate dat een programma of project gereed is om naar de volgende fase te gaan. Dit ligt ook in lijn met wat OGC schrijft over de Gateway Review methode (paragraaf 2.4.1.). Samenvattend kan geconcludeerd worden dat de Gateway Review methode (een zekere mate van) zekerheid verschaft aan de opdrachtgever bij het realiseren van grootschalige complexe IT projecten, deze zekerheid kwalificeert echter niet als zekerheid zoals deze bedoeld wordt vanuit de IT auditing.

Bij de beantwoording van de hoofdvraag is bewust voorbij gegaan aan de uitspraak van de Minister van BZK die bij grote overheids ICT-projecten het instrument ‘reviews’ verplicht wil laten toepassen. In dit kader heeft de Minister aangegeven dat de opdrachtgever ervoor kan kiezen om de Gateway Review methode toe te passen. Deze keuze is echter aan de opdrachtgever, welke er volgens de Minister ook voor kan kiezen om een audit door een auditdienst te laten uitvoeren. Een brandende onbeantwoorde vraag hierbij is of de Minister een audit van een auditdienst gelijk stelt aan de Gateway Review methode. Het heeft er alle schijn van. Kijkend naar de manier waarop de geïnterviewden de Gateway Review methode omschreven hebben, vindt de Minister het blijkbaar geen probleem dat zij twee zeer verschillende instrumenten als reviewinstrument inzet. Vanuit de karakteristieke kenmerken van beide instrumenten is het ook maar zeer de vraag of de uitkomsten van beide onderzoeksmethoden enigszins bij elkaar in de buurt zullen liggen.

In aansluiting op bovenstaand punt bieden de voorwaarden, zoals uiteengezet in pararaaf 2.2.1, waaraan een review moet voldoen ook geen opheldering over hoe de Minister de Gateway Review methode ziet (ten opzichte van de audit). De voorwaarden van de Minister komen er op neer dat het reviewteam bij de vier verplicht uit te voeren reviews, bij grote ICT overheidsprojecten, een inhoudelijk oordeel geeft, waarbij het reviewteam toetst aan normen welke zij afleidt uit diverse project documenten (zoals business case en projectplan). Dit staat haaks op de Gateway Review methode, welke kijkt op basis van best practices of een project klaar is voor de volgende fase. Van een oordeel zoals deze gedefinieerd is binnen IT auditing is bij de Gateway Review methode dan ook geen sprake.

48

Dat de Minister gekozen heeft voor het niet verplicht stellen van de Gateway Review methode kan te maken hebben de verantwoordelijkheid die gepaard gaat met het verplicht stellen van de Gateway Review methode. De Minister van BZK wil niet dat zij verantwoordelijkheid draagt voor de beheersing en uitvoering van ICT-projecten van andere departementen en in dit kader past het niet om de Gateway Review methode verplicht te stellen.

“Wat houdt de Gateway Review methode in als instrument van IT project auditing?” Is subvraag 1 uit de inleiding van deze scriptie. Eigenlijk kan de Gateway Review weinig betekenen als instrument van IT project auditing. Dit komt omdat de Gateway review methode niet kwalificerend is, er wordt geen uitspraak gedaan in de vorm van een oordeel maar er wordt een status afgegeven. De Gateway review methode is bedoeld als hulp voor de opdrachtgever, die een spiegel voorgehouden wordt op het gebied van effectiviteit van handelen. Uit vorenstaande vloeit voort dat de Gateway Review methode zich op een ander vlak bevindt dan IT auditing. Ondanks dat de Gateway review methode weinig kan betekenen als instrument van IT project auditing, kunnen auditors wel gebruik maken van de informatie uit de Gateway Review rapportages. Waarbij opgemerkt, dat niet alle opdrachtgevers Gateway Review rapportages ten behoeve van IT project audit’s willen verstrekken.

Deelvragen 2 en 3 uit paragraaf 1.4. van deze scriptie zien op de door mij in het praktijkonderzoek betrokken programma's. Van het GMV-programma wilde ik weten wat dit programma betekende voor het informatiebeleid van de publieke sector. In paragraaf 3.1.1. van deze scriptie heb ik het belang van de GMV uiteengezet. De voorziening biedt mensen, die zelf niet in staat zijn om digitaal gebruik te maken van bepaalde overheidsdiensten, de mogelijkheid om dit via een rechtsgeldige machtiging te beleggen bij een ander persoon, die dan optreedt als vertegenwoordiger.

Ten aanzien van het mGBA heb ik me in de inleiding afgevraagd wat de betekenis van het mGBA programma is voor de overheid en de burger. Uit het doel en de beschrijving van de GBA die gegeven is in paragraaf 3.2.2 blijkt dat GBA een belangrijke basisregistratie is. Vele partijen maken gebruik van de in de GBA vastgelegde persoonsgegevens. Binnen het stelsel van basisadministraties vormt de GBA een essentiële schakel.

5.2. Verbeterpunten en Aanbevelingen Zoals uit de inleiding van deze scriptie blijkt is het de bedoeling van deze scriptie om verbeterpunten te onderkennen die zien op de praktische toepassing van de Gateway Review methode. Vanuit de nadelen van de Gateway Review methode, de zwaktes binnen de methode en de nadere beschouwingen die plaatsgevonden hebben over onafhankelijkheid en vertrouwelijkheid zijn een aantal verbeterpunten te onderkennen.

Een adequaat kwaliteitsborgingsysteem is noodzakelijk om er voor te zorgen dat Gateway Reviews van voldoende niveau zijn. Daarbij is het binnen het kwaliteitsborgingsysteem van groot belang om vast te stellen dat men elkaar niet gaat sparen bij de uitvoering van een Gateway Review. Een ander argument voor een kwaliteitsborging systeem vormen adviezen die reviewteams geven aan de opdrachtgever. Geïnterviewden gaven aan dat, volgens hen, in twee gevallen verkeerde adviezen zijn gegeven. Omdat de

49

teamleider het reviewdossier na afloop van de review vernietigt, bestaat er geen mogelijkheid om een analyse uit te voeren op de manier waarop het reviewteam tot haar advies gekomen is. Thans bestaat het kwaliteitsborgingsysteem uit de selectie op kwaliteit bij het aannemen van nieuwe Gateway Reviewers en een evaluatie tussen de SRO, de teamleider van het reviewteam en de Gatewayorganisatie enige weken nadat de review plaatsgevonden heeft. Als onderdeel van een kwaliteitsborgingsysteem stel ik voor om een jaar na de review te kijken naar het uiteindelijke resultaat van de door het reviewteam gegeven adviezen. Vorenstaande kan input vormen voor de Gateway-organisatie om de review methodiek aan te passen en de input kan de Gateway-organisatie ook gebruiken bij de scholing van reviewers.

Om de kracht van de Gateway Review methode te behouden is het noodzakelijk om in Nederland een keuze te maken voor het al dan niet openbaar maken van de reviewrapporten. De huidige situatie, waarbij de keuze voor openbaarmaking bij de opdrachtgever ligt zorgt voor onduidelijkheid. Deze onduidelijkheid kan zich vertalen naar minder open gesprekken tussen geïnterviewden en de Gateway Reviewers, waardoor een stuk van de kracht van de methode verloren gaat.

Een, in mijn ogen, belangrijke verbeterpunt betreft de definiëring van het begrip onafhankelijkheid. Het OGC heeft niet gedefinieerd wat zij onder onafhankelijkheid verstaat in het kader van het uitvoeren van een Gateway Review. Ik adviseer de Nederlandse Gateway-organisatie om onafhankelijkheid te definiëren. Uit de definitie van onafhankelijkheid kunnen vervolgens criteria worden afgeleid om, voorafgaand aan een review, te bepalen welke personen wel en niet kunnen optreden als Gateway Reviewer. Dit voorkomt achteraf moeilijkheden over het feit of een persoon, uit oogpunt van onafhankelijkheid, al dan niet een review mocht uitvoeren.

Bovengenoemde verbeterpunten komen voort uit de kern van de Gateway Review methode die bestaat uit onafhankelijkheid, vertrouwelijkheid en kwaliteit bij de reviewers. Hierop voortbordurend is het van belang dat daar waar een reviewteam een review uitvoert volgens de Gateway Review methode, de regels (zoals opgesteld door OGC) die gelden voor Gateway Reviews strikt na geleefd worden. Dit om de toegevoegde waarde van Gateway Review methode te handhaven. Het PINO (Prince In Name Only) effect zoals dat bij Prince2 ontstaan is, heeft schadelijke gevolgen voor het vertrouwen dat betrokken partijen in de Gateway Review methode hebben. Vorenstaande maakt duidelijk dat omzichtigheid geboden is met betrekking tot de de kern van de Gateway Review methode en de toepassing van de regels, gebeurt dit niet dan bestaat het reële risico dat de methode muteert van een methode die een wezenlijke bijdrage kan leveren aan de opdrachtgever tot een methode die bekend staat als administratieve last zonder toegevoegde waarde.

Publicaties over de enorme besparingen die door de Gateway Review methode zijn gerealiseerd in Engeland en waarop in bepaalde gevallen schoorvoetend teruggekomen moest worden, vormen de bron van een andere aanbeveling. Ik adviseer om bij een Gateway Review (veel) aandacht te besteden aan het vertrouwen welke betrokken partijen, waaronder de opdrachtgever, hebben in de Gateway Review methode. Hierbij is het van belang om aan de opdrachtgever aan te geven op welke aspecten de Gateway Review niet ziet. Dit is noodzakelijk om te voorkomen dat de Gateway Review methode meer vertrouwen wekt dan de methode daadwerkelijk kan waarmaken.

50

Een aanbeveling die ook van toepassing is op programma’s en projecten welke niet de Gateway Review methode toepassen gaat over de ‘Risk Potential Assessment’ die OGC beschikbaar stelt op haar internetpagina. Deze gestructureerde risicoanalyse heeft ook toegevoegde waarde voor projecten waarbij de opdrachtgever de Gateway Review methode niet toepast. De opdrachtgever vergroot het inzicht in het project en de daarbij behorende risico’s door de Risk Potential Assesment toe te passen. Voorzover opdrachtgevers geen risicoanalyse uitvoeren op programma’s en projecten, adviseer ik om het gratis ter beschikking gestelde model van OGC te gebruiken.

Uit de hoeveelheid audits, contra-expertises, reviews en adviesopdrachten komt een meer algemene aanbeveling voort. Ik adviseer opdrachtgevers en programmamanagers die zekerheden willen verkrijgen door het laten uitvoeren van audits, contra-expertises, reviews en adviesopdrachten goed te onderzoeken waarover zij zekerheid willen verkrijgen. Om vervolgens zorgvuldig een afweging te maken welk middel hiertoe het best geëigend is. Dit behoedt de opdrachtgever voor een wirwar aan audits, contra-expertises, reviews en adviesopdrachten, waarbij de hoeveelheid verstrekte opdrachten niet noodzakelijkerwijs hoeft te leiden tot meer zekerheid voor de opdrachtgever. Door een zorgvuldige keuze van de opdrachtgever, tussen de in te zetten instrumenten, voorkomt hij dat projecten en programma’s gebukt gaan onder grote administratieve lasten en tijdsdruk.

Om projecten en programma’s succesvol af te ronden adviseer ik om meer continuïteit in acht te nemen bij het vervullen van sleutelposities binnen projecten en programma’s. Onder sleutelposities versta ik opdrachtgevers, programmamanagers, projectleiders en belangrijke personen in de diverse overlegverbanden binnen programma’s en projecten. Uit de interviews die gehouden zijn in het kader van de toepassing van de Gateway Review methode op het GMV en het mGBA programma is naar voren gekomen dat er een (groot) aantal wisselingen hebben plaatsgevonden op sleutelposities binnen beide programma’s. Het is, zoals ook terug te vinden in de Gateway Review methode, van belang voor het slagen van programma’s en projecten dat er continuïteit aanwezig is op sleutelposities binnen projecten en programma’s.

Onverwacht en opvallend is het feit dat er een aantal programma’s en projecten van start gaan zonder dat er een kwalitatief goede business case aanwezig is. Gezien de mogelijkheid om op de business case te sturen, adviseer ik de overheid om niet langer toe te staan dat middelgrote- en grote overheid ICTprogramma’s en projecten van start gaan zonder business case en te waarborgen dat er een periodieke herijking van het project en de business case plaatsvindt. In het nieuwe rapportage model voor grote ICT projecten zullen er regels opgenomen worden die moeten afdwingen dat grote ICT-projecten (dat wil zeggen projecten met een begroting van boven de € 20 miljoen) verplicht zijn om een business case te hebben. Daarnaast blijkt dat BZK druk doende is een Rijksbrede handreiking uit te geven voor business cases. Oplevering van de handreiking is naar verwachting medio 2010.

51

Literatuur •

Algemene Rekenkamer, Lessen uit ICT-projecten bij de overheid, Deel A , 29 november 2007.

•

Algemene Rekenkamer, Lessen uit ICT-projecten bij de overheid, Deel B , 1 juli 2008.

•

Beckum van J., G. Vlasveld, Contractmanagement voor ICT op basis van CATS CM, Van Haren Publishing, 2008.

•

Bestenbreur T., Toetsen kost ook (heel veel) geld, BinnenlandsBestuur, 27 maart 2009.

•

Blankena F., Collegiale klap op ICT-project, F. Blankena, digitaal bestuur, 27 februari 2009.

•

Collins, T., Exlusive: Computer Weekly publishes 'secret' gateway review, www.computerweekly.com, 23 Feb 2009.

•

Dekker, V., Overheid smijt met geld voor gebrekkige automatisering, Trouw, 4 juni 2007.

•

Dekker, V., Automatiseringsramp lijkt onvermijdelijk, Trouw, 4 juni 2007.

•

During, J.R., e-overheid: Bouw mee aan een betere dienstverlening, , www.egemiteams.nl/impressie-presentaties21 januari 2009.

•

Fijneman R., E. Roos Lindgreen, P. Veltman, Grondslagen IT-auditing, Sdu uitgeverij, 4e druk, bladzijde 81, september 2008.

•

Glas A., A. Bloembergen, C.L. Wauters, Voor alle zekerheid – Over adviezen, audits en contraexpertises: een gids voor ICT-opdrachtgevers in de publieke sector, HEC, maart 2007.

•

H M Treasury Cabinet Office, Efficiency in Civil Government Procurement, www.hmtreasury.gov.uk, juli 1998.

•

Gershon, P. Releasing resources to the front line, Independent Review of Public Sector Efficiency, www.hm-treasury.gov.uk, 2004.

•

Gershon, P. Review of Civil Procurement in Central Government, www.hm-treasury.gov.uk, april 1999.

•

Gremmen, P., Geld verspilling bij ICT-projecten van de overheid door gebrek aan doelgerichtheid, Twynstra Gudde, www.twynstragudde.nl, 3 januari 2008.

•

HEC flyer: Het OGC Gateway proces, Gateway reviews: De weg naar success, 2007.

•

Kocks C., Twintig over Internal/Operational Auditing, ‘auditing, audit, auditor, wat moeten we er ermee?’, Vera/Eurac, 2003.

•

Leih G. Ga verder dan Gateway, Digitaal Bestuur, 19 maart 2009.

•

Matthijsse, R.P.H.M., Regiebesturing bij informatisering in de publieke sector, Kluwer, Alphen aan de Rijn, 2003.

•

Minister van Binnenlandse Zaken en Koninkrijk relaties, Informatie- en communicatietechnologie, kamerstuk 2007-2008, 26643, nr. 128 Tweede Kamer, 26 juni 2008.

•

Minister van Binnenlandse Zaken en Koninkrijk relaties, Informatie- en communicatietechnologie, kamerstuk 2008-2009, 26643, nr. 135 Tweede Kamer, 19 december 2008.

•

Minister van Binnenlandse Zaken en Koninkrijk relaties, mGBA Rapport Gateway Review 0– Strategisch Assesment, versie nummer: Concept 0.96, www.ikregeer.nl/document/BLG19206

•

Minister van Binnenlandse Zaken en Koninkrijk relaties, Informatie- en communicatietechnologie, kamerstuk 2009-2010, 26643, nr. 144 Tweede Kamer, 30 september 2009.

•

Minister van Binnenlandse Zaken en Koninkrijk relaties, Informatie- en communicatietechnologie,

52

kamerstuk 2008-2009, 26643, nr. 141 Brief van de werkgroep ICT-projecten bij de overheid, parlis.nl/pdf/kamerstukken/KST133336.pdf, 24 juni 2009. •

Nuiten E., Stoelinga M., R. Vrij, Definitie studie mGBA Versie 2.0, De moderne GBA mogelijk gemaakt…, 28 april 2009, Capgemini,www.bzk.nl/actueel/publicaties/@118680/definitiestudiemgba, 28 april 2009.

•

OGC Best Practice-Gateway to success, Review 0: strategic assessment, www.ogc.gov.uk, 2007.

•

OGC Best Practice-Gateway to success, Review 1: Business justification, www.ogc.gov.uk, 2007.

•

OGC Best Practice-Gateway to success, Review 2: delivery Strategy, www.ogc.gov.uk, 2007.

•

OGC Best Practice-Gateway to success, Review 3: Investment decision, www.ogc.uk, 2007.

•

OGC Best Practice-Gateway to success, Review 4: Readiness for service, www.ogc.uk, 2007.

•

OGC Best Practice-Gateway to success, Review 5: Operations review and benefits realisation, www.ogc.uk, 2007.

•

OGC, Office of Government Commerce Open for Business, Press Release, www.ogc.gov.uk, april 2000.

•

OGC, Gateway Process Review 5: Operantions reviews & benefits realisation, version 4.0, www.ogc.gov.uk, june 2008.

•

OGC, The Procurement Toolkit –Best Practice Guides, 16 Project Management & OGC Gateway Review, www.ogc.gov.uk

•

Onna van M., A. Koning, De Kleine Prince 2 ’gids voor projectmanagement’, Educational Services, vijfde editie, bladzijde 88, 2007.

•

Pels Rijcken. C, Programma mGBA: kiezen voor een nieuwe start, programmaplan, Versie 0.92, www.parlis.nl/pdf/bijlagen/BLG19202.pdf, 25 februari 2009.

•

Renoir, e-overheid: bouw mee aan betere dienstverlening, Basisinformatie GMV, versie 1.1, , www.egem-iteams.nl augustus 2009.

•

Sedee R., C. Wauters, Gateway naar success, de EDP-Auditor, nummer 1, 2007.

•

Spoelman, E.J., S.Ph. Nordhausen, C.A.E. Moor en C.A.M. de Wit, business case modernisering GBA, Capgemini N.V. , 21 december 2008.

•

Tak van der T., G. Wijnen, Programmamanagement Sturen op samenhang, Kluwer, 2e druk, 2006

•

Wanna J., J. Buting, Improving Implementation: Organisational Change and Project Management, Chapter 16. Governments Can deliver: Better Practice in Project and Program Delivery, ANZOG/ANU, epress.anu.edu.au/anzog/imp/mobile_devices/, 2006.

53

Geïnterviewden •

Berg RE, G. van den, Senior Auditor, Ministerie van Financiën, Rijksauditdienst

•

Bouten RA, M.P.J., plaatsvervangend directeur ICTU

•

Bronkhorst mr., G., Hoofd cluster Informatiebeleid Basisvoorzieningen Overheid, Directie Dienstverlening, Regeldruk en Informatiebeleid, Ministerie Binnenlandse Zaken en Koninkrijk relaties

•

Buyne, H., Projectleider Bureau Gateway, Ministerie Binnenlandse Zaken en Koninkrijk relaties

•

During, R., Programma manager ICTU

•

Elswijk, M van, kwaliteitsbewaker binnen het programma mGBA

•

Frijns dr., P., Kwartiermaker Rijksbrede Vernieuwingen

•

Graaf, M., de adviseur en auditor van HEC

•

Moelker mr. MPA , J.J., programmamanager Modernisering GBA, Directoraat-generaal Bestuur en Koninkrijksrelaties, Ministerie Binnenlandse Zaken en Koninkrijk relaties

•

Mollema RE RA, R.J., senior consultant HEC

•

Roos, EMIA RO, de M., IT auditor en adviseur van HEC

•

Stolwijk drs., W.A.B., directeur PIANOo, Expertisecentrum Aanbesteden van het Ministerie van Economische Zaken

54

Bijlagen Bijlage 1. Voorbeeld van een aanbeveling met bijbehorende classificatie bij Gateway Review 0 Als voorbeeld, van hoe de aanbevelingen met de daarbijbehorende kwalificaties eruit zien, refereer ik aan de daadwerkelijk uitgevoerde Gateway Review 0 bij de ‘Modernisering van de GBA’. Enkele aanbeveling met kwalificaties zagen er bij de ‘Modernisering van de GBA’ review als volgt uit73: Nr. Aanbeveling Kritiek/Essentieel/Tip 1. Houdt doelstellingen en scope opnieuw tegen het licht en stel ze dan Kritiek vast, overleg met alle partijen, 2. Ontwikkel, vanuit een integraal en up-to-date architectuurconcept, in Essentieel hapklare brokken: kortcyclisch, sturen op zelfstandige werkende resultaten 3. Kijk naar Best Practices bij andere programma’s Tip

Bijlage 2. De ontwikkeling van de Gateway Review methode in Engeland In november 1998 werd Peter Gershon, directeur van GEC Marconi, door de Engelse regering gevraagd om aanbestedingen van de Engelse Rijksoverheid te beoordelen. Dit in het licht van doelstellingen die de Engelse overheid had met betrekking tot efficiency, modernisering en concurrentie74. Deze opdracht vloeide voort uit een studie75 die het Engelse Ministerie van overheidsbestedingen in januari 1998 uitzette. Onderwerp van betreffende studie vormden efficiency vraagstukken aangaande aanbestedingen door de Engelse overheid. Eén van de adviezen uit het in januari 1998 gestart onderzoek betrof de doorlichting van de centrale overheid over de manier waarop de diverse ministeries het uitbesteden vormgeven. Het belang van uitbesteding voor de Engelse overheid blijkt uit de omvang van de bestedingen die er met de uitbesteding gemoeid gaan. Exclusief het Ministerie van defensie, besteedden de diverse Engelse ministeries in 1998 al 12 miljard pond aan uitbestedingen. Het Ministerie van Defensie wel meegerekend, dan is er in 1998 voor 20 miljard pond uitbesteed door de Engelse ministeries. In zijn onderzoek heeft Gershon de term aanbesteding breed opgevat. Het onderzoek ziet op de verwerving van diensten, goederen en bouwprojecten. Hierbij heeft Gershon gekeken naar de hele levenscyclus van het initiële concept, het definiëren van de business case tot het eind van de levenscyclus van een bedrijfsmiddel of een service contract. Gershon kwam in zijn onderzoek tot de bevinding dat er geen goed gedefinieerd proces is voor het managen van aanbestedingen die groot, complex en niet standaard zijn (of een combinatie van vorengenoemde criteria zijn). Dit brengt met zich mee dat ministeries bij belangrijke verwervingen van goederen, diensten of bouwprojecten onnodige risico’s lopen op het proces van het strategisch ‘in control’ zijn bij aanbestedingen gedurende de gehele levenscyclus. Vanuit zijn bevinding geeft Gershon de aanbeveling om een goed gedefinieerd proces te ontwikkelen voor het strategisch management op aanbestedingen die groot, complex en niet standaard zijn. Dit proces zou gebaseerd moeten zijn op de volgende principes: • Projecten hebben fasen in hun levenscyclus. • De zogenaamde ‘Gates’ tussen de fasen kunnen worden gekarakteriseerd aan de hand van een aantal producten (bijvoorbeeld eisen aan de specificatie, aanbestedingsplan, project management plan, risk management plan). • De opgeleverde producten76 dienen te worden beoordeeld door deskundige personen die onafhankelijk van het project zijn. • Belangrijke ‘Gates’ kunnen alleen gepasseerd worden als het oordeel van de deskundige personen positief is.

73 Het betreft hier slechts enkele van een groter aantal aanbevelingen dat gedaan is in het mGBA Rapport Gateway Review 0 – Strategisch Assessment, Versie nummer: Concept 0.96, Datum van oplevering aan SRO: 4 november 2008. 74 Peter Gershon, Review of Civil Procurement in Central Government, april 1999. 75 H M Treasury Cabinet Office, Efficiency in Civil Government Procurement, juli 1998. 76 In het kader van deze scriptie is het begrip product breed gedefinieerd, een product kan tastbaar zijn zoals hardware, software en servicediensten, maar ook minder tastbaar zoals bijvoorbeeld een cultuurverandering.

55

Wanneer bij een review door deskundige personen gebreken geconstateerd zijn, dient de leider van het reviewteam de Directeur Generaal van het betreffende Ministerie op de hoogte te brengen van de constateringen. Ten aanzien van de organisatie en de structuur, welke er binnen de diverse ministeries was met betrekking tot aanbestedingen, kwam Gershon tot de conclusie dat er sprake was van fragmentatie en gebrek aan coördinatie van de aanbestedingsactiviteiten. Dit mede veroorzaakt door het aantal (onderdelen van) ministeries, dat betrokken was bij een gemiddelde aanbesteding. In het onderzoek bleek duidelijk een behoefte te onderkennen voor een centraal orgaan dat zorgt voor consistent aanbestedingsbeleid, dat voorkomt dat ‘wielen’ diverse keren opnieuw worden uitgevonden en die zogenaamde ‘best practices’ promoot. Naar aanleiding van genoemde bevinding stelde Gershon één centrale organisatie voor die de decentrale activiteiten naar zich toehaalt en deze gaat uitvoeren. Deze nieuwe centrale organisatie heeft Gershon de naam gegeven van ‘Office of Government Commerce’ (hierna: OGC). Binnen de OGC zou ook het beschreven strategisch management proces, dat gericht is op het ‘in control’ zijn bij grote projecten, een plaats moeten krijgen. Het Engelse Ministerie van Financiën heeft de aanbeveling, met betrekking tot het centraliseren van activiteiten die verband houden met aanbesteding, van Gershon overgenomen. Vorenstaande heeft ertoe geleid dat het Ministerie op 22 juli 1999 aankondigde dat het OGC vanaf 3 april 2000 gaat functioneren als ‘centre of excellence’ bij aanbestedingen77. De door het Engelse Ministerie van Financiën aangestelde directeur, de heer Gershon, definieerde ondermeer de volgende doelen voor het OGC: • Zorgen voor de beste kwaliteit en waarde krijgen voor het betaalde geld aan leveranciers. • Het identificeren van ‘best practices’ en het ondersteunen van ministeries en andere overheidsorganisaties bij het implementeren van de ‘best practices’. • Het opstellen van meetinstrumenten die moeten bijdragen om inzicht te krijgen in de hoeveelheid geld die ministeries besteden aan aanbestedingen. Met betrekking tot bovenstaande doelen geldt ‘waarde voor het betaalde geld’ krijgen als basis voor iedere aanbesteding waarbij het geld van belastingbetalers betrokken is. De aanbeveling, zoals deze uit het onderzoek van Gershon voortkwam, om een goed gedefinieerd proces te ontwikkelen voor het strategisch management op grote, complexe en niet standaard aanbestedingen, werd opgepakt door het OGC. Dit resulteerde in de ontwikkeling van het Gateway Review Process, welke OGC in Engeland in februari 2001 introduceerde. Inmiddels is de toepassing van de Gateway Review Process in Engeland voor de centrale overheid onder meer verplicht gesteld bij programma’s en projecten waar ICT een cruciale rol speelt.

Bijlage 3. Beschrijving van de eisen aan reviews volgens het rapportage model grote ICT projecten Het Rapportage model grote ICT projecten bij de overheid kent voorwaarden waaraan reviews moeten voldoen. Deze voorwaarden zien op de vier verplicht uit te voeren reviews bij grote ICT projecten. Onderstaand volgt een nadere beschrijving van de voorwaarden per review. Project start, volgens het rapportage model de eerste review, verricht het reviewteam na de opstartfase voorafgaand aan de start van de projectuitvoering. Bij deze review vindt er een inhoudelijke toetsing plaats aan de hand van vastleggingen in het projectplan, zoals rechtvaardiging, scope, uitgangspunten, kostenbatenanalyse, risico’s en planning van het project. De eerste review dient te leiden naar een oordeel over het project. Kan het project naar de volgende fase en is de planning realistisch, zijn vragen waarop het reviewteam door middel van haar oordeel antwoord op geeft. Bij de tweede review, review projectuitvoering en –voortgang, eist de Minister van BZK een inhoudelijk oordeel over de projectvoortgang en het opdracht- en projectmanagement. Waarbij de toetspunten de kosten-batenanalyse, risico’s, mijlpalen en de planning van het project zijn. Review twee dient in de realisatiefase plaats te vinden en is gekoppeld aan de faseringen binnen het project en de tijdens de planning vastgelegde mijlpalen. Het doel van review twee is het tijdig onderkennen van problemen om vervolgens te kunnen bijsturen op het project. Voorafgaand aan de implementatie van het product, dat door middel van het project gerealiseerd is, verlangt het rapportage model voor ICT-projecten dat de derde review, review realisatie, zijn beslag krijgt. Deze review dient uit te monden in een oordeel over de mate waarin de projectresultaten voldoen aan de gestelde eisen zoals deze voor het project zijn benoemd. Daarbij stelt het reviewteam ook vast of het project gereed is voor implementatie. De toetspunten van de derde review zijn gelijk aan de toetspunten van de tweede review.

77 OGC, Office of Government Commerce Open for Business, Press Release april 2000.

56

Afsluitend dient een laatste review plaats te vinden, waarin het reviewteam een oordeel geeft of het project het beoogd projectresultaat heeft opgeleverd en in beheer is genomen. Het beoogd projectresultaat, waaraan de reviewers toetsten, is bij de start van het project vastgelegd in het projectplan. Review 4 geschiedt voorafgaand aan het verlenen van décharge over het project. Onderstaand schema is overgenomen uit het rapportagemodel grote ICT-projecten78:

Bijlage 4. Uitgangspunten die gelden bij de Gateway Review methode De 14 uitgangspunten van OGC zijn verdeeld in drie groepen te weten toewijding en leiderschap, verwerving en ‘Best Practice’ en stijl. Ten aanzien van toewijding en leiderschap heeft OGC 3 uitgangspunten geformuleerd, te weten79: 1. De hoogste leiding van de opdrachtgever ondersteunt OGC Gateway en het merk. 2. De SRO waar onder het programma of project valt is een klant van OGC Gateway Review en is verantwoordelijk voor het effectief doorvoeren van de uit de Gateway Reviews voortvloeiende aanbevelingen. 3. Gateway Reviews maken onderdeel uit van een gepland en geïntegreerd systeem om zekerheid te verkrijgen, ter ondersteuning van effectieve uitvoering van programma’s en projecten. Met betrekking tot de verwerving en ‘Best Practice’ zijn er 8 uitgangspunten beschreven door OGC. Deze 8 uitgangspunten zijn: 4. Gateway Reviews worden geprioriteerd en voorzien van middelen (samenstelling van het reviewteam) aan de hand van het inherent risico, complexiteit en het belang van een project. 5. Gedurende de levensduur van programma’s en projecten voert een reviewteam op aangewezen punten Gateway Reviews uit. 6. De Gateway Review methode is geschikt om reviews voor te bereiden en uit te voeren. 7. Lessen uit de Gateway Reviews dienen gedeeld te worden met het programma en project management netwerk op nationaal en regionaal niveau. 8. Het reviewteam moet onafhankelijk zijn van het programma of het project, de projectorganisatie en de daaraan verwante organisaties. De inhoud van het review rapport valt onder de verantwoordelijkheid van het reviewteam. 9. Een team van geaccrediteerde deskundigen voeren Gateway Reviews uit, met de benodigde vaardigheden, kennis en ervaring. Deze deskundigen komen uit een ‘pool’ met reviewers. 10. De review zal kort zijn, gericht op de toekomst, waarbij op de laatste dag van de review het reviewteam het reviewrapport oplevert aan de SRO. 11. Aanbevelingen van het reviewteam zijn onbevangen en praktisch, gebaseerd op ‘Best Practice’ waarbij het reviewteam de urgentie van de uitvoering van het project in ogenschouw neemt. Als laatste heeft OGC 3 uitgangspunten gedefinieerd over de stijl waarbinnen het reviewteam de Gateway Review methode uitvoert. Deze betreffen: 12. Bij de uitvoering van Gateway Reviews krijgt het reviewteam toegang tot alle belanghebbenden en documentatie. 13. Het reviewteam verricht de Gateway Reviews op een vertrouwelijke manier dat resulteert in een rapport waarbij de inhoud niet te herleiden is naar individuen. 14. Bij de collegiale toetsing door de Gateway Reviews, zal het reviewteam een coachende stijl richting de SRO hanteren. Waarbij het reviewteam een ‘no surprises’ benadering toepast.

78 Voor een meer uitgebreide beschrijving van de criteria van het rapportage model verwijs ik naar: Rapportagemodel grote ICT-projecten, www.ikregeer.nl/document/BLG18302. 79 De uitgangspunten zijn ontleend aan (en vertaald uit) een niet openbaar stuk dat voor deze scriptie ter beschikking gesteld is door het OGC.

57

Bijlage 5. Voorbeeld van een doelstelling van een Gateway Review 0 In het reviewverslag bij mGBA is de doelstelling van de review verwoord als:”Met deze Gateway peerreview 0 ‘Strategic Assessment’ wordt beoogd om voor de ‘Senior Responsible Owner’: • de doelstellingen en de beoogde uitkomsten van het programma (en de samenhang daarin) te reviewen, • te beoordelen of de noodzakelijke bijdrage wordt geleverd aan de ‘overall’-strategie van de Staatssecretaris en de bestuurlijke partners, • vast te stellen of de voorbereidingen voldoende zijn voor besluitvorming over een herstart, • aanbevelingen te geven voor het vervolg, in termen van aanpak en inhoud van het programma. Deze Gateway Review is niet bedoeld om een keuze uit de scenario’s aan de opdrachtgever en het Bestuurlijk Overleg voor te houden.”

Bijlage 6. Voorbeeld van vragen waarop het reviewteam antwoord dient te geven met het daarbij behorende verwachte bewijsmateriaal Ten aanzien van Gateway Review 0 staat in het handboek van OGC onder de hoofdcategorie ‘huidige stand van zake’ onderstaande vraag en het verwachte bewijsmateriaal:

Bijlage 7. Onderwerpen welke een business case moet bevatten Een beschrijving van de ‘business case’ bevat minimaal volgende onderwerpen80: • Redenen die ten grondslag liggen aan het project (waarom dit project?) en de zienswijze hoe het project bij de organisatie past. • De verschillende alternatieven die voor het project zijn afgewogen. Hierbij wordt per alternatief aangegeven wat de voor- en nadelen van het alternatief zijn. Om een goed overzicht te krijgen van de alternatieven is het ook van belang om de nuloptie op te nemen als alternatief. • Beschrijving van de meetbare baten, ten opzichte van de huidige situatie, die het project oplevert voor de organisatie. Onder de baten vallen ook de negatieve opbrengsten uit het project. • Een opsomming van alle belangrijke risico’s die aan het project verbonden zijn. • Een overzicht van kosten die de projectorganisatie maakt om het project te kunnen uitvoeren. Hierbij bevat het overzicht ook een tijdpad van wanneer welke kosten zich voor zullen doen. • Een beoordeling van het totale project, door de verwachte baten af te zetten tegen de te verwachten kosten, waarbij het reviewteam ook de belangrijke risico’s in de afweging meeneemt. Ingeval van een complexe ‘business cases’ is het mogelijk om in de ‘business case’ meerdere scenario’s uit te werken om te kijken wat het effect op het project zal zijn.

Bijlage 8. Onderwerpen waarover het reviewteam bij Gateway Review 1 zekerheid wil verkrijgen De in hoofdlijnen beschreven doelen bij Gateway Review 1, zijn bij de Gateway Review methode vertaald naar onderwerpen waarover het reviewteam zekerheid wil verkrijgen, deze onderwerpen betreffen ondermeer81:

80 Ontleend aan ‘De Kleine Prince 2’ gids voor projectmanagement, M. van Onna en A. Koning, Educational Services, vijfde editie, 2007, bladzijde 88.

58

• • • • • • • • • • • •

de robuustheid van de ‘business case’; het gebruik maken van expertise om de mogelijkheden om de projectdoelen te realiseren te onderkennen, te onderzoeken en in kaart te brengen; de aanwezigheid en kwaliteit van het haalbaarheidsonderzoek; de interesse vanuit marktpartijen voor het project; de aanwezigheid van interne en externe steun voor het project op hoog niveau; het onderkennen en identificeren van risico’s rond het project en de systematiek van de projectorganisatie over hoe met de risico’s om te gaan; de mate waarin de reikwijdte en de gestelde eisen aan het project realistisch en ondubbelzinnig zijn; de mate waarin verwacht wordt dat het project de gestelde project uikomsten gaat halen de plannen voor de volgende fase; in hoeverre de aannames die gedaan zijn in de planning van het project reëel blijken te zijn; de mate waarin het project in lijn ligt met de doelen, de gewenste uitkomsten van het programma en de organisatie strategie; de evaluatie van de implementatie van de in eerder stadia gedane aanbevelingen.

Bijlage 9. Onderwerpen waarover het reviewteam bij Gateway Review 2 zekerheid wil verkrijgen Om zekerheid aan de opdrachtgever te kunnen verstrekken of een project al dan niet klaar is voor de volgende projectfase, dient het reviewteam bij Gateway Review 2 antwoord te verkrijgen op een aantal vragen, zoals82: • Voldoet de ‘business case’ nog steeds, nu het project gedefinieerd is? • Zijn de doelen en gewenste uitkomsten van het project nog steeds in lijn met het programma waaronder het project valt? • Is de verwervings c.q. veranderstrategie robuust en geschikt voor het onderhavige project? • Is het projectplan voldoende gedetailleerd en realistisch? • Is er een controle mechanisme voor het project ingericht dat ziet op ondermeer de bewaking van de financiële budgetten? • Is er voldoende budget beschikbaar om het project te realiseren? • Zijn de ontwikkel en veranderstrategie nog steeds van toepassing en te managen? • Gaat er binnen de ontwikkeling van het project gezorgd worden voor goede klant/leverancier relaties? • Is er een geschikt aanbestedingsplan welke voldoet aan lokale- en EU wetgeving en welke de vertraging door de aanbesteding tot een minimum beperkt? • Worden geschikte meetinstrumenten gebruikt om de project prestaties te meten? • Zijn er plannen ontwikkeld op het gebied van risicomanagement? • Zijn er procedures gebruikt welke de kwaliteit binnen het project moeten waarborgen? • Wordt er bij IT gedreven projecten voldaan aan het in compliance zijn met IT eisen, informatie beveiligingseisen en IT standaards? • Zijn er voor de volgende fase van het project voldoende interne middelen (deskundigheid, vaardigheid en ervaring) binnen de projectorganisatie om deze fase te kunnen realiseren? • Ondersteunen de belanghebbenden het project nog steeds? • Zijn de aanbevelingen uit de eerdere review(s) doorgevoerd?

Bijlage 10. Onderwerpen waarover het reviewteam bij Gateway Review 3 zekerheid wil verkrijgen Om zekerheid aan de opdrachtgever te kunnen verstrekken of een project al dan niet klaar is voor de volgende projectfase, dient het reviewteam bij Gateway Review 3 zekerheid te verkrijgen over83: • De geldigheid van de verder uitgewerkte en bijgestelde business case, nu de relevante informatie van potentiële dienstverleners en partners aanwezig is.

81 OGC Best Practice-Gateway to success, Review 1: Business justification, 2007, bladzijde 7. 82 OGC Best Practice-Gateway to success, Review 2: delivery Strategy, 2007, bladzijde 7. 83 OGC Best Practice-Gateway to success, Review 3: Investment decision, 2007, bladzijde 7.

59

• • • • • • • • • • •

In hoeverre de doelen en nagestreefde uitkomsten van het project nog steeds in de lijn liggen van het programma, waartoe het project een bijdrage levert, en de bredere strategische doelen van de overheid. Het voldoen van wet- en regelgeving, als ook interne procedures op het gebied van aanbesteding. De mate waarin de beoogde aanbieder van diensten op tijd, binnen het budget en “waarde voor het geld” kan leveren. Of er voldoende managementcontrols zijn ingericht om project door alle fasen te managen tot en met de voltooiing van het project. De aanwezigheid van doorlopende ondersteuning voor het project. Het volgen van het goedgekeurde verwervings- c.q. veranderstrategie. De mate waarin de ontwikkel en implementatieplannen van de aanbieder en de projectorganisatie degelijk en uitvoerbaar zijn. De gereedheid van de klant om de uitkomsten van het project te implementeren. Plannen voor risk management en changemanagement en in hoeverre de dienstverleners bij deze plannen betrokken zijn. De toewijzing van informatiebeveiliging en (verandering in) e-government frameworks aan functionarissen. De opvolging van de aanbevelingen uit de aan Gateway Review 3 voorafgaande reviews

Bijlage 11. Onderwerpen waarover het reviewteam bij Gateway Review 4 zekerheid wil verkrijgen Om zekerheid aan de opdrachtgever te kunnen verstrekken of een project al dan niet klaar is voor de 84 volgende projectfase, dient het reviewteam bij Gateway Review 4 zekerheid te verkrijgen over : • Is het uitbestedingscontract correct uitgevoerd door de dienstaanbieder, waarbij de werkzaamheden voldoende zijn beschreven? • Zijn de lopende uitbestedingscontracten up-to-date? • Is de business case nog steeds geldig, of is hij ingehaald door interne en externe ontwikkelingen? • Worden de beschreven projectdoelen gehaald? • Zijn er processen en procedures ontwikkeld die er voor zorgen dat het project in de operationele fase succesvol kan blijven? • Zijn alle benodigde en door de klant gewenste tests naar tevredenheid uitgevoerd? • Is de klant klaar om tot implementatie van het project over te gaan? • Zijn er geteste calamiteiten- en uitwijkplannen? • Worden de onderkende risico’s effectief gemanaged en zijn ze niet bedreigend voor de implementatie? • Zijn de risico’s welke voortkomen uit de implementatie van het project geëvalueerd? • Hebben de klant en de aanbieder werkende implementatieplannen? • Is de interne beheersing ingericht om het project te kunnen sturen bij het implementeren in de operationele fase? • Zijn er contractmanagement overeenkomsten om het project te begeleiden in de operationele fase van het project? • Zijn er procedures en contracten welke zien op de overgang van het project van de SRO naar de uiteindelijke klantorganisatie? • Zijn de betrokken partijen plannen overeengekomen met betrekking tot trainingen, communicatie, het in productie nemen en het onderhouden van het geïmplementeerde product? • Hebben alle betrokken partijen (goedgekeurde) plannen die zien op het afdekken van management risico’s? • Heeft de klantorganisatie plannen gemaakt om na de implementatie van het nieuwe product rapportages mechanismen in te richten, dan wel aan te passen op de verschillende niveaus binnen de organisatie om te komen tot een werkend product binnen de operationele fase, waarbij snelle bijsturing mogelijk is?

84 OGC Best Practice-Gateway to success, Review 4: Readiness for service, 2007, bladzijde 7.

60

• • •

Is de vertrouwelijkheid en betrouwbaarheid van de informatie in voldoende mate gewaarborgd? Worden er lessen getrokken uit dit project die een bijdrage kunnen leveren voor volgende projecten? Zijn de adviezen uit de voorafgaande Gateway Reviews opgevolgd?

Bijlage 12. Werkzaamheden die het reviewteam bij Gateway Review 5 uitvoert Concrete werkzaamheden bij Gateway Review 5 zijn85: • Evaluatie van de rechtvaardiging van de business case met betrekking tot het moment dat de investering (Gateway Review 3) gedaan werd. • Vaststellen dat er nog steeds een zakelijke noodzaak is voor de investeringen die gedaan worden. • Evaluatie of de verwachte opbrengsten van deze fase ook daadwerkelijk gerealiseerd worden. • Evaluatie van de effectiviteit van het doorlopen contractmanagement proces. • Vaststellen dat de klant voldoende middelen heeft om het contract met succes af te wikkelen. • Vaststellen dat er continuïteit is met betrekking tot medewerkers welke sleutelfuncties vervullen binnen het project. • Vaststellen dat overeengekomen wijzigingen binnen het project geen negatieve invloed hebben gehad op de beoogde uitkomsten. • Evaluatie van de doorlopende eisen aan het contract om te voldoen aan de ‘business’ benodigdheden. Hierbij dient het reviewteam vast te stellen dat wijzigingen in omstandigheden hun weerslag vinden in het contract. • Vaststellen dat de producteigenaar de contracten doorlopend beoordeelt en aanpast om te komen tot ‘waarde voor geld’. • Vaststellen dat er plannen zijn die zien op de ontmanteling van het product met de bijbehorende beëindiging van de diverse contracten (de exit strategie). • Evaluatie van de implementatie van de in eerdere stadia gedane aanbevelingen.

Bijlage 13. Afkortingenlijst BPR BSN BZK BZK-K CIO DA DigiD EZ GBA GBA-V HEC http GBO.Overheid GBP GMV GUI ICT ICTU IT ITIL LNV LO 4

Agentschap Basisadministratie Persoonsgegevens en Reisdocumenten Burger Service Nummer Ministerie van Binnenlandse Zaken en Koninkrijkrelaties Burgerzakensysteem-kern Chief Information Officer Dienstaanbieder Digitale identiteit Ministerie van Economische Zaken Gemeentelijke Basisadministratie Gemeentelijke Basisadministratie Verstrekkingen Het Expertise Centrum Hyper Text Transfer Protocol Gemeenschappelijke Beheerorganisatie Overheid Gemeentelijke Basisregistratie Personen Gemeenschappelijk Machtings- en Vertegenwoordigingsvoorziening Grafische User Interface Informatie en Communicatie Technologie ICT uitvoeringsorganisatie Informatie Technologie Information Technology Infrastructure Library Ministerie Landbouw Natuur en Visserij Logisch Ontwerp 4

85 Best Practice-Gateway to success, Review 5: Operations review and benefits realisation, 2007, bladzijde 7.

61

mGBA MSP NAW NORA OGC OSB PID PINO Prince 2 SAML SOAP SRO SUB UWV VNG WALVIS WOZ XML

Modernisering Gemeentelijke Basisadministratie Managing Successful Programmes Naam, Adres en Woonplaats Nederlandse Overheid Referentie Architectuur Office of Government Commerce Overheidservicebus Project Initiatie Document Prince in name only PRojects IN Controlled Environment 2 Security Assertion Markup Language Simple Object Access Protocol Senior Responsible owner Samenwerking UWV Belastingdienst Uitvoeringsinstituut Werknemersverzekeringen Vereniging van Nederlandse Gemeenten Wet administratieve lastenverlichting en vereenvoudiging in sociale verzekeringswetten Waardering onroerende zaken Extensible Markup Language

62