Het verschaffen van zekerheden met de Gateway Review methode

Transcriptie

1 Het verschaffen van zekerheden met de Gateway Review methode Studentnaam: drs. L.H. Kwak MSc. RA Opleiding: Postgraduate IT Audit Opleiding van de Vrije Universiteit Amsterdam Begeleider: dr. R.P.H.M. Matthijsse RE Studentnummer: Datum:

2 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

3 Inhoudsopgave 1. INLEIDING INLEIDING FALENDE ICT-PROJECTEN BIJ DE OVERHEID HET ANTWOORD OP DE PROBLEMATIEK ROND FALENDE ICT PROJECTEN BIJ DE OVERHEID CENTRALE VRAAGSTELLING METHODOLOGIE EN ONDERZOEKAANPAK LEESWIJZER GATEWAY REVIEW METHODE DOEL EN INHOUD VAN DE GATEWAY REVIEW METHODE ONTWIKKELING EN UITGANGSPUNTEN VAN DE GATEWAY REVIEW METHODE De ontwikkeling van de Gateway Review methode in Nederland Uitgangspunten Gateway Review BESCHRIJVING VAN DE VERSCHILLENDE GATEWAY REVIEWS Gateway 0: Strategische doorlichting Gateway 1: Zakelijke rechtvaardiging Gateway 2: Verwerving- c.q. veranderstrategie Gateway 3: Investeringsbeslissing Gateway 4: Gereedheid voor dienstverlening Gateway 5: Evaluatie van behaalde resultaten CONCLUSIE Gateway Review versus reguliere audit Voor en nadelen van de Gateway Review methode Effectiviteit in te zetten Gateway Review s BESCHRIJVING OVERHEIDS IT-PROJECTEN GEMEENSCHAPPELIJKE MACHTIGING- EN VERTEGENWOORDIGINGSVOORZIENING Doel, beschrijving en voortgang van de GMV Het GMV proces Organisatie op het GMV project MODERNISERING GEMEENTELIJKE BASISADMINISTRATIE (MGBA) Doel, beschrijving en voortgang mgba Organisatie op het mgba programma Omgeving mgba programma BEVINDINGEN EN ANALYSE VAN HET PRAKTIJKONDERZOEK GATEWAY REVIEW METHODE Onafhankelijkheid Vertrouwelijkheid Gateway Review en project auditing Andere aspecten met betrekking tot de Gateway Review methode BEHEERSING OP HET GMV PROGRAMMA IN RELATIE TOT DE GATEWAY REVIEW METHODE DE GATEWAY REVIEW METHODE BIJ HET MGBA PROGRAMMA CONCLUSIE EN AANBEVELINGEN CONCLUSIE VERBETERPUNTEN EN AANBEVELINGEN LITERATUUR GEÏNTERVIEWDEN

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

5 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 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 overheidsmiddelen 1 van 4 tot 5 miljard 2. 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 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

6 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 diversiteit 4 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 De geplande opleverdatum van het project toeslagen was 1 januari 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 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

7 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 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 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 Commerce 5 (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-projecten 6. 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

8 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, betreffen 7 : 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

9 Dat wijzigingen in de op te leveren producten voor een project een basis kunnen vormen voor project falen wordt ook in de literatuur 8 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 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 is 9. 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

10 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 tot en met ). 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 ). Ook beschrijf ik in de conclusie de voor- en nadelen van de Gateway Review methode (paragraaf ), zoals genoemd in de literatuur. Hoofdstuk 3 gaat nader in op het programma Gemeenschappelijke Machtigings- en Vertegenwoordigingsvoorziening 10 (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 en ). 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

11 In hoofdstuk 4 kom ik tevens terug op de relatie tussen de Gateway Review methode en de reguliere audit (paragraaf ). Dit doe ik aan de hand van wat de geïnterviewden verteld hebben over het onderwerp 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 auditing 11, 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 auditing 12? 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 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 Met betrekking tot de gehouden interviews is er met de geïnterviewden een hoor en wederhoor procedure toegepast 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 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

12 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 ). Uitgangspunten van de Gateway Review methode zijn vastgelegd door OGC en in deze scriptie toegelicht in paragraaf 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 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 samenstellen 14. 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

13 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 door 15 : 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 projectteams 16. Een uitgevoerde Gateway Review resulteert in een status 17 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 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

14 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 plaatsen 18 : 18 Dit model is overgenomen uit de HEC flyer: Het OGC Gateway proces, Gateway reviews: De weg naar success,

15 2.2. Ontwikkeling en uitgangspunten van de Gateway Review methode 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 Centrum 19 (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 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 Hillenaar 20, 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-projecten 21. 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 brieven 22 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 adopteren 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 Kamerstuk , 26643, nr. 128 en Kamerstuk , 26643, nr 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 ( 15

16 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 eindverslag 24 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 reactie 25 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 model 26 dat geldt voor grote ICT-projecten 27. 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 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/kst pdf. 25 Overgenomen uit brief van de Minister van Binnenlandse Zaken en Koninkrijksrelatie, Kamerstuk , 26643, nr. 144, 30 september Voor een meer uitgebreide beschrijving van de criteria van het rapportage model verwijs ik naar: Rapportagemodel grote ICT-projecten, 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

17 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 tot en met 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 Beschrijving van de verschillende Gateway Reviews 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 als 28 : een verzameling van tijdelijke, samenhangende en dynamische doelen, inspanningen en middelen. OCG 29 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 programma 30. 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 Best Practice-Gateway to success, Review 0: strategic assessment, 2007, bladzijde OGC Best Practice-Gateway to success, Review 0: strategic assessment, 2007, bladzijde 8. 17

18 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 mgba 31. 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 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 1 32 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 OGC Best Practice-Gateway to success, Review 1: Business justification, 2007, bladzijde 8. 18

19 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 onderwerpen 33 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 e- government 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 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 reviewteam 34 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 projectfase 35, 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 OGC Best Practice-Gateway to success, Review 2: delivery Strategy, 2007, bladzijde OGC Best Practice-Gateway to success, Review 2: delivery Strategy, 2007, bladzijde 7. 19

20 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 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 3 36 is, om vast te stellen dat de door de projectorganisatie aanbevolen investeringsbeslissing 37 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 vragen 38. 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 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

21 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 voeren 39. 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 vragen 40 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 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 OGC Best Practice-Gateway to success, Review 4: Readiness for service, 2007, bladzijde OGC Best Practice-Gateway to success, Review 4: Readiness for service, 2007, bladzijde 7. 21

22 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 model 41 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 contractmanagement 42 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 werkzaamheden 43 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 Conclusie 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 audit 44 : 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 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 Overgenomen uit: Twintig over Internal/Operational Auditing, auditing, audit, auditor, wat moeten we er ermee?, C. Kocks, 2003, Vera/Eurac, bladzijde 4. 22

23 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 uitvoeren 45. 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

24 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 assurance 46 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 Review 47 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 Best Practice-Gateway to success, Review 0: strategic assessment, 2007, bladzijde 4 en 5. 24

25 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 zijn 48 : 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 project 49. 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 projectorganisatie 50. De kosten van de reviews moeten eerst worden terugverdiend om te kunnen spreken van een geldelijk voordelig saldo 51 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 Ontleend aan, Ga verder dan Gateway, G Leih, Digitaal Bestuur, 19 maart Zie ook: Toetsen kost ook (heel veel) geld, T. Bestenbreur, BinnenlandsBestuur, 27 maart 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

26 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 Andere aspecten met betrekking tot de Gateway Review methode waar voor- en nadelen van de methode vanuit de praktijk aan de orde komen 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 weergegeven 52 : 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,

27 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 ). Vervolgens komt in paragraaf het GMV proces aanbod. Waarna paragraaf 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 ). Daarna komt de organisatie op het mgba aan de orde (paragraaf ) om als laatste nader in te gaan op de omgeving van het mgba programma (paragraaf ). 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 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 DigiD 53, 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 27

28 Concrete doelen welke de overheid met de GMV wil bereiken zijn 54 : 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 e- overheidsdiensten. 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 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

29 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 XML 55 (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 OSB 56 (Overheidservicebus) standaarden te bereiken zijn. Het (architectuur)schema van GMV ziet er als volgt uit 57 : BURGER BURGER DA frontoffice KOPPELING DA processen KOPPELING DA gegevens KOPPELING BEDRIJF aanvragen activeren wijzigen intrekken ontkoppelen raadplegen KOPPELING GMV frontoffice KOPPELING machtiging verifiëren GMV processen KOPPELING GMV gegevens KOPPELING basisregistraties 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 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