Financiële sturing van IT-projecten. Scriptie ter afronding van de postgraduate IT-audit opleiding aan de Vrije Universiteit

Financiële sturing van IT-projecten Scriptie ter afronding van de postgraduate IT-audit opleiding aan de Vrije Universiteit

Auteur: Studentnummer: Organisatie: VU begeleider (extern): Bedrijfscoach (intern): Afstudeerdatum:

Rogier Alarm 2036878 Countus Accountants + Adviseurs B.V. dr. René Matthijsse RE Mark Spijker RA juli 2015

Voorwoord

Deze scriptie is een presentatie van mijn onderzoeksproject voor de Executive master of IT Auditing aan de Vrije Universiteit van Amsterdam. De scriptie heeft als titel ‘Financiële sturing van IT-projecten’. De kranten staan er vol mee. Weer een IT-project wat jaren geleden al klaar had moeten zijn, is vandaag opgeleverd. De tijdsplanning is bij lange na niet gehaald, om nog maar niet te spreken over de begroting. Jaarlijks worden organisaties hiermee geconfronteerd. Er wordt een project gedefinieerd om de toekomstige doelstellingen van de organisatie te kunnen behalen. Maar tussentijds worden er wijzigingen voorgedragen en doorgevoerd waardoor de planning en begroting niet meer gehaald kunnen worden. Het doel van dit onderzoek is om een bijdrage te leveren aan het vakgebied IT Auditing door inzichtelijk te maken welke struikelblokken er aanwezig zijn bij projecten en op welke manier de ITauditors zekerheid kunnen verschaffen over de opgestelde begrotingen. Hiervoor kan bijvoorbeeld een audit instrument gehanteerd worden. Naast een literatuuronderzoek is een praktijk onderzoek uitgevoerd aan de hand van interviews met medewerkers van het Ministerie van Binnenlandse Zaken en Koninkrijkrelaties. Zij hebben inzicht gegeven in de werkwijze die de overheid hanteert voor het sturen en beheersen van IT-projecten. Het afronden van mijn IT audit opleiding in combinatie met mijn werkzaamheden als senior assistent accountant en IT auditor bij Countus Accountants + Adviseurs B.V. is een zeer goede manier geweest om mijn verkregen theoretische kennis met de audit praktijk te combineren. Ten eerste wil ik de heer René Matthijsse bedanken voor de deskundige begeleiding van dit onderzoek. Als afstudeerbegeleider heeft hij op kritische wijze het onderzoek gevolgd en gestuurd. Daarnaast wil ik mijn collega’s van Countus Accountants + Adviseurs B.V. bedanken voor de serieuze interesse in mijn werk en het verschaffen van relevante documentatie en feedback. Deze interesse en hulpvaardigheid hebben mijn scriptie op vele manieren verbeterd. Ook wil ik de medewerkers van het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties bedanken voor het geven van inzichten met betrekking tot projectsturing bij de overheid. Meppel, juli 2015 Rogier Alarm

2

Inhoudsopgave Voorwoord ....................................................................................................................................................... 2 Inhoudsopgave................................................................................................................................................. 3 1

Omgevingsraming en projectieraamwerk ................................................................................................ 5 1.1

Aanleiding en vraagstelling .............................................................................................................. 5

1.2 Probleemstelling .............................................................................................................................. 8 1.2.1 Doelstelling .................................................................................................................................. 8 1.2.2 Centrale vraagstelling................................................................................................................... 8 1.2.3 Deelvragen .................................................................................................................................. 9 1.3 2

Plan van aanpak............................................................................................................................... 9

De portfoliobenadering voor het aansturen van IT-projecten ................................................................ 10 2.1 De portfoliobenadering voor het aansturen van IT-projecten........................................................... 10 2.1.1 IT-projectportfolio definitie, samenstelling en kenmerken .................................................... 10 2.1.2 IT-projectportfoliomanagement .............................................................................................. 12 2.2 IT-projectportfolio beheersing ..................................................................................................... 14 2.2.1 Definitie en kenmerken ........................................................................................................... 14 2.2.2 Risicogebieden ........................................................................................................................ 14 2.3 Faalfactoren bij projecten ............................................................................................................... 16 2.3.1 Welke elementen zorgen dat een project faalt? ......................................................................... 17 2.3.2 Overschrijding van de begrote kosten ........................................................................................ 18 2.3.3 Succesfactoren........................................................................................................................... 20

3

Instrumenten voor project auditing ....................................................................................................... 23 3.1

Voordelen van het hanteren van een auditinstrument ..................................................................... 23

3.2 Meest gehanteerde projectmanagementmethoden ........................................................................ 24 3.2.1 Prince2 ...................................................................................................................................... 26 3.2.2 Managing Succesful Programmes (MSP) ..................................................................................... 29 3.2.3 Gateway review ......................................................................................................................... 32 4

Financiële sturing van ICT projecten ...................................................................................................... 37 4.1

Gemiddelde boekhoudkundige rentabiliteit..................................................................................... 37

4.2

Terugverdienperiode ...................................................................................................................... 38

4.3

Netto contante waarde .................................................................................................................. 39

4.4

Interne rentabiliteit ........................................................................................................................ 42

4.5

Verschillen netto contante waarde en interne rentabiliteit .............................................................. 43

4.6

Onderzoeken naar gekozen methode .............................................................................................. 45

4.7

Mogelijkheden tijdens de uitvoering van een project....................................................................... 45

3

5

Praktijkonderzoek.................................................................................................................................. 48 5.1

Onderzoeksaanpak......................................................................................................................... 48

5.2 Projectbeschrijving mGBA............................................................................................................... 49 5.2.1 Achtergrond............................................................................................................................... 49 5.2.2 Projectresultaten en maatschappelijke effecten ......................................................................... 49 5.2.3 Gebruikers en afnemers ............................................................................................................. 50 5.2.4 Gehanteerde projectportfoliomethodes ..................................................................................... 51 5.3 Gehanteerde financiële sturingsmethode o.b.v. rapportage Capgemini ........................................... 51 5.3.1 Baten- en kostengebieden per stakeholder ................................................................................ 57 5.3.2 Resultaten en conclusies business case ...................................................................................... 61 5.3.3 Conclusie ................................................................................................................................... 64 5.4

Gekozen methodiek op basis van rapportage Capgemini................................................................. 64

5.5

Bijstelling Business Case mGBA....................................................................................................... 64

5.6

Evaluatie mGBA door Gartner in 2013 ............................................................................................ 66

5.7 Bevindingen ................................................................................................................................... 67 5.7.1 Terugblik op de scenario’s van 2009 ........................................................................................... 67 5.7.2 Bijstelling van scenario 2 in 2011 ................................................................................................ 69 5.7.3 Aanpassing projectaanpak naar aanleiding van onderzoek Gartner 2013 .................................... 69 5.7.4 Analyse gemaakte keuzes........................................................................................................... 70 6

7

Conclusie en synthese............................................................................................................................ 72 6.1

mGBA conclusies ............................................................................................................................ 72

6.2

Weerspiegeling met theorie............................................................................................................ 74

Beantwoording onderzoeksvragen ........................................................................................................ 75 7.1

Deelvragen..................................................................................................................................... 75

7.2

Centrale onderzoeksvraag .............................................................................................................. 78

Literatuurlijst ................................................................................................................................................. 80 Websites ........................................................................................................................................................ 83 Bijlage ............................................................................................................................................................ 84

4

1 Omgevingsraming en projectieraamwerk Dit hoofdstuk beschrijft de aanleiding van het onderzoek naar portfoliomanagement bij de projecten gerelateerd aan IT en de relevantie voor het vakgebied. Vervolgens wordt de vraagstelling beschreven. Ten slotte wordt het onderzoeksmodel uiteengezet welke gebruikt is om de probleemstelling te beantwoorden.

1.1

Aanleiding en vraagstelling

Telegraaf, 26 juni 2013:

Justitie verspeelt miljoenen aan geflopt IT-project AMSTERDAM Het ministerie van Veiligheid en Justitie heeft opnieuw gefaald met de invoering van een groot automatiseringssysteem. De kosten van het bewuste GPS-project vallen met 103 miljoen euro vier keer zo hoog uit als oorspronkelijk gepland.

Foto: Jos Schuurman Dat blijkt uit een interne evaluatie van het ministerie, in handen van Het Financieel Dagblad. Het Geïntegreerd Processysteem Strafrecht (GPS) moest het papieren strafdossier volledig overbodig maken. Aan het project is 10 jaar gewerkt. Door de mislukking moeten rechters en officieren van justitie langer blijven werken met papieren strafdossiers. Naar nu blijkt is het project eind 2011 in stilte stopgezet, terwijl grote delen van het programma ongebruikt blijven. Alleen het Openbaar Ministerie werkt met het systeem, maar slechts voor standaardzaken zoals winkeldiefstallen. De meer complexe zaken worden nog altijd voor een belangrijk deel met papieren dossiers afgehandeld. De Tweede Kamer was in 2009 voor het laatst op de hoogte gesteld van GPS. Artikelen zoals bovenstaande komen steeds vaker voor. Binnen een organisatie dienen veranderingen te worden doorgevoerd. Eén van de aspecten die hierbij komt kijken is de ICT. Er moet een nieuw systeem worden ontwikkeld omdat het huidige systeem niet meer aan de gestelde eisen voldoet. In eerste instantie wordt er een plan opgesteld met hierin de eisen waaraan het nieuwe systeem moet voldoen. Vervolgens worden de kosten inzichtelijk gemaakt en wordt er een tijdsplanning opgesteld. Het managen van deze projecten vindt veelal plaats via portfoliomanagement. Portfoliomanagement is managen van een bewust gekozen, cyclisch veranderend geheel van activiteiten, projecten en programma's om de strategische doelstellingen van een organisatie te bereiken. Wanneer het eenmaal project gestart is wordt het plan gevolgd. Echter tijdens de uitvoering worden er bij het managen van het project zaken geconstateerd en wordt het oorspronkelijke projectplan bijgesteld. Deze bijstelling leidt over het algemeen tot hogere kosten en er is meer tijd benodigd om het project af te ronden. Wanneer het project gereed is wordt deze geëvalueerd. Er blijkt dat het project meer tijd in beslag heeft genomen en dat de kosten aanzienlijk hoger zijn dan op voorhand begroot.

5

Ook is in 2014 het Parlementair onderzoek naar ICT-projecten bij de overheid gepresenteerd. Door de commissie Elias is een onderzoek uitgevoerd naar de ICT-projecten welke zijn gerealiseerd binnen de overheid. Hierbij is door de commissie het volgende vastgesteld (Tweede Kamer der Staten Generaal (2014), Parlementair onderzoek naar ICT-projecten bij de Overheid. Tweede Kamer, vergaderjaar 2014–2015, 33 326, nr. 5): 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

De rijksoverheid heeft haar ICT-projecten niet onder controle. De politiek beseft het niet, maar ICT is overal. De rijksoverheid maakt haar ICT-beleidsambities niet waar. De verantwoordings- en besluitvormingsstructuur bij ICT-projecten is zeer gebrekkig. De rijksoverheid heeft onvoldoende inzicht in de kosten en baten van haar ICT. De ICT-kennis van de rijksoverheid schiet tekort. Het ICT-projectmanagement is zwak. ICT-aanbestedingstrajecten bevatten perverse prikkels. Het contractmanagement bij ICT-projecten is onprofessioneel. Het ontbreekt de rijksoverheid aan lerend vermogen op ICT-gebied.

Ad 1. De rijksoverheid heeft haar ICT-projecten niet onder controle De ambities van de rijksoverheid met ICT zijn groot. Het is daarom extra teleurstellend dat zij de besturing en beheersing van projecten met een belangrijke ICT-component niet op orde heeft. Het geheel van ICT-organisaties bij de rijksoverheid is chaotisch en ondoorzichtig. Taken en verantwoordelijkheden zijn versnipperd en onduidelijk. De belangen van de hoofdrolspelers bij ICTprojecten lopen te veel uiteen. De rijksoverheid heeft haar ICT-projecten vaak niet in de hand voor wat betreft de kosten, de tijd of zelfs het eindresultaat. Bovendien is er niemand die het echt voor het zeggen heeft over ICT-projecten. Omdat een financieel overzicht op overkoepelend rijksniveau sinds 1995 niet meer wordt opgesteld, ontbreekt inzicht in ICT-kosten. Niemand weet hoeveel de Nederlandse overheden aan ICT uitgeven. Daarom ook weet niemand hoeveel geld gemoeid is met mislukkingen. Een veilige schatting op grond van informatie van diverse deskundigen komt neer op 1 à 5 miljard euro verspilling per jaar – naar het oordeel van de commissie in alle gevallen een onaanvaardbaar hoog bedrag. Ad 2. De politiek beseft het niet, maar ICT is overal De Kamer, het kabinet, ‘de politiek’ in het algemeen is te weinig doordrongen van het feit dat elk onderwerp en beleidsterrein tegenwoordig samenhangt met ICT. De Kamer toont zich onvoldoende betrokken bij de start van ICT-projecten. Hierdoor worden vragen gesteld vanuit de Kamer en toezeggingen gedaan door het kabinet die vaak niet door de starttoets van het BIT zouden komen. Een gebrek aan ICT-bewustzijn zorgt ervoor dat het moeilijk is om over ICT-gerelateerde onderwerpen het debat te voeren met de Kamer. Aangezien ICT tegenwoordig overal aanwezig is, raakt dit de kern van de taken van de rijksoverheid. De commissie concludeert dat het ICT-bewustzijn van zowel de Kamer (Kamerleden, fracties, fractieondersteuning en ambtelijke ondersteuning) als het kabinet ernstig tekortschiet. Ad 3. De rijksoverheid maakt haar ICT-beleidsambities niet waar Binnen de rijksoverheid is er te weinig overkoepelend gezag en centrale sturing om de ICTbeleidsambities voor elkaar te krijgen. De commissie stelt vast dat de rijksoverheid haar besluitvorming en verantwoordelijkheden op dit gebied niet goed heeft georganiseerd. Bovendien zijn de kostenbesparingen en maatschappelijke opbrengsten van het algemene ICT-beleid niet zichtbaar. Door deze slechte structuur en gebrek aan inzicht in kosten en besparingen krijgt de rijksoverheid het gewenste resultaat niet voor elkaar. Ad 4. De verantwoordings- en besluitvormingsstructuur bij ICT-projecten is zeer gebrekkig De commissie stelt vast dat de taken, rollen en verantwoordelijkheden bij ICT-projecten van de rijksoverheid te vaak niet vastgelegd, versnipperd en onduidelijk zijn. Bovendien is het onduidelijk wie

6

de leiding heeft in projecten. Deze ‘gedeelde onverantwoordelijkheid’ zorgt ervoor dat de sturing en beheersing van ICT-projecten niet op orde is. Ad 5. De rijksoverheid heeft onvoldoende inzicht in de kosten en baten van haar ICT De commissie constateert dat veel problemen ontstaan aan het begin van ICT-projecten. Veel geplande projecten willen het onmogelijke voor elkaar krijgen. Projecten zijn te groot en te complex, terwijl juist deze grote projecten statistisch gezien vaker mislukken. Bovendien ontbreekt een goede zakelijke rechtvaardiging bij veel ICT-projecten. De rechtvaardiging wordt te veel gezien als een formaliteit – een manier om goedkeuring te krijgen om geld uit te geven, waarna het document in een la verdwijnt. ‘Businesscase, klaar is Kees’, werd een gevleugelde uitdrukking bij de hoorzittingen. Het is juist belangrijk dat ook tijdens de uitvoering van een project de zakelijke rechtvaardiging van tijd tot tijd opnieuw bekeken wordt en vooral ook bijgewerkt. Ad 6. De ICT-kennis van de rijksoverheid schiet tekort De rijksoverheid heeft te weinig kennis in huis om ICT goed te kunnen beheren en grote en risicovolle ICT-projecten te kunnen uitvoeren. Niet voor niets hebben velen gezegd dat hoge ambtenaren ‘onbewust onbekwaam’ zijn. Dit komt voor een deel doordat er op de arbeidsmarkt maar weinig echte ICT-experts zijn. Daarnaast zouden ICT-specialisten de lonen bij de rijksoverheid vaak te laag vinden, althans volgens een aantal gesprekspartners van de commissie. Dit signaal moet verder worden onderzocht, maar de commissie constateert wel dat het in elk geval lastig blijkt om de ICT-kennis op niveau te krijgen en te houden. De rijksoverheid moet bedenken welke ICT-kennis echt essentieel is om in eigen huis te hebben. Ad 7. Het ICT-projectmanagement is zwak De organisatiestructuur en -processen binnen projecten (het projectmanagement) zijn niet op orde. Er wordt te weinig deskundig personeel ingezet en het is onduidelijk wie waarvoor verantwoordelijk is. Vaak wordt er niet genoeg nagedacht over beheers aspecten als tijd, geld, kwaliteit en reikwijdte. Algemeen bekende procedures om projecten te besturen worden wel gebruikt, maar niet goed of alleen gedeeltelijk toegepast. Zo is het risicomanagement bij de rijksoverheid onder de maat en zijn opdrachtgevers onvoldoende betrokken. Bovendien worden de belangen van de eindgebruiker in veel projecten helemaal vergeten. Ad 8. ICT-aanbestedingstrajecten bevatten perverse prikkels Het verbaast de commissie dat er niet al eerder expliciet en diepgaander aandacht is besteed aan ICT-aanbestedingen. Juist in de aanbestedingsfase worden keuzen gemaakt en afspraken vastgelegd die het hele verdere verloop van projecten beïnvloeden. De commissie stelt vast dat de relatie tussen de rijksoverheid en haar leveranciers onvolwassen is en perverse prikkels bevat. De rijksoverheid denkt, ondanks haar gebrek aan ICT-kennis, het vaak beter te weten dan de markt. Zij geeft leveranciers tijdens aanbestedingstrajecten zelden de kans om zelf met ideeën of oplossingen te komen. Er wordt vaak zeer specifiek aanbesteed en aanbestedingstrajecten zijn lang en (voor de leverancier) kostbaar, waarbij er te veel nadruk wordt gelegd op de prijs. Leveranciers zouden opdrachten die onmogelijk zijn moeten weigeren door ofwel geen offerte uit te brengen ofwel de onhaalbaarheid te melden bij de opdrachtgever en het BIT. De aanbestedingstrajecten van de rijksoverheid bevatten daarvoor echter onvoldoende stimulansen. Daardoor gaan belangen die eigenlijk behoren samen te vallen in de aanbesteding- en gunningsfase, juist uiteen lopen. Om bij zulke uiteenlopende belangen te verwachten dat leveranciers handelen in het belang van de rijksoverheid, is zoiets als een vos vragen om op kippen te passen. De commissie is door velen gewezen op de beperkingen die de strikte aanbestedingsregels zouden opleggen aan de rijksoverheid. Zij constateert echter dat er vooral te weinig gebruikgemaakt wordt van de ruimte die de aanbestedingsregels wel degelijk bieden.

7

Ad 9. Het contractmanagement bij ICT-projecten is onprofessioneel Er is nogal wat mis met het contractmanagement bij de ICT-projecten van de rijksoverheid. De commissie stelt vast dat er tijdens het aanbestedingstraject regelmatig weliswaar stevige contracten worden opgesteld en ondertekend, maar dat ze daarna in een la verdwijnen. Meerwerk en ‘uurtjefactuurtje’ komen te vaak voor tijdens de uitvoering van het project. Het management let niet goed op of opdrachtgever en leverancier zich wel houden aan de oorspronkelijk vastgelegde afspraken. Problemen komen bovendien te laat aan het licht. Opdrachtgever en opdrachtnemer overleggen tijdens het project onvoldoende structureel en bovendien niet op de juiste niveaus in de organisaties. Ad 10. Het ontbreekt de rijksoverheid aan lerend vermogen op ICT-gebied Uit bovenstaande conclusies en de onderliggende analyse blijkt dat veel verschillende elementen samen verantwoordelijk zijn voor het mislukken van ICT-projecten. De meeste hiervan zijn ook al eerder benoemd in andere rapporten en onderzoeken. Toch mislukken grote ICT-projecten van de rijksoverheid nog steeds keer op keer. De commissie constateert dan ook dat een van de belangrijkste oorzaken hiervan ligt in een gebrek aan lerend vermogen bij de rijksoverheid. Het meest recente schrijnende voorbeeld hiervan is een groot project van het programma van de Sociale Verzekeringsbank (SVB Tien) dat in september 2014 na acht jaar werd stopgezet, met alle financiële en andere gevolgen van dien. Op bovenstaande tien punten worden door de commissie Elias aanbevelingen gedaan. Ook wordt er gesteld dat als slechts enkele aanbevelingen worden uitgevoerd en de resterende niet, de commissie een herhaling voorziet van zetten uit het verleden en daardoor komt er wéér geen structurele oplossing voor de problemen. Dan blijft de rijksoverheid op dit vlak aanmodderen en belastinggeld verspillen. De commissie zou dat als een gemiste kans zien – niet de eerste op dit terrein.

1.2

Probleemstelling

In deze paragraaf wordt aan de hand van de doelstelling de centrale vraag met bijbehorende deelvragen geïntroduceerd. De onderzoeksvraag wordt middels een specifieke onderzoeksmethode beantwoord. De sub paragraaf ‘deelvragen’ beschrijft de scope van dit onderzoek.

1.2.1

Doelstelling

Het doel van dit onderzoek is om een bijdrage te leveren aan het vakgebied IT Auditing door inzichtelijk te maken welke struikelblokken er aanwezig zijn bij projecten en op welke manier de ITauditors zekerheid kunnen verschaffen over de opgestelde begrotingen. Hiervoor kan bijvoorbeeld een audit instrument gehanteerd worden.

1.2.2

Centrale vraagstelling

Op basis van de onderzoeksdoelstellingen is de centrale vraagstelling als volgt geformuleerd: Op welke wijze kan vanuit het perspectief van IT-auditing enige mate van zekerheid worden verschaft over de financiële sturing van projecten en welke audit instrumenten kunnen hierbij gehanteerd worden?

8

1.2.3

Deelvragen

Ter onderbouwing van de centrale vraagstelling zijn de volgende deelvragen geformuleerd: 1 2 3

1.3

Wat wordt verstaan onder de term portfoliomanagement en welke audit instrumenten gericht op risicobeheersing worden toegepast om zekerheid te verschaffen bij een project? Door welke oorzaken overschrijden complexe projecten de begroting en op welke wijze is dit bij toekomstige projecten te voorkomen door gebruik te maken van een (ander) audit instrument? Op welke wijze kan vanuit het perspectief van IT-auditing zekerheid worden verschaft over de financiële sturing van projecten?

Plan van aanpak

In eerste instantie zal er een literatuuronderzoek plaatsvinden. Hiervoor zal de benodigde literatuur worden verzameld en doorgenomen. Voor het literatuuronderzoek wordt een periode van drie maand gerekend. Vervolgens wordt een casestudy uitgevoerd, dit betreft het onderzoeken van de praktijksituatie. Deze praktijksituatie zal een project van de overheid zijn wat al langere tijd loopt maar nog niet is afgerond. Er zal documentatie over het project worden verzameld en zullen expert interviews worden gehouden met betrokken medewerkers van het project. Ook voor het onderzoeken van de praktijksituatie zal een periode van drie maanden worden aangehouden Als laatste onderdeel zal er documentatie plaatsvinden in de vorm van een scriptie. De verzamelde literatuur zal worden samengevat. Vanuit de casestudy worden de bevindingen en de analyse beschreven. De conclusies en aanbevelingen worden als oordeelsvorming en beschouwing opgenomen.

9

2 De portfoliobenadering voor het aansturen van IT-projecten De portfoliobenadering werd in eerste instantie geïntroduceerd door Markowitz (1952) in het kader van investeringen omtrent beleggingen. Deze benadering is verder doorontwikkeld door Reyck (2005) tot de portfoliotheorie. In de theorie wordt beschreven dat beleggingen als één geheel moeten worden beschouwd voor een optimale balans tussen een zo laag mogelijk risico en een zo hoog mogelijk rendement. Ook wordt er vanuit gegaan dat wanneer er wordt geïnvesteerd in meerdere fondsen, dit een hoger rendement oplevert bij een lager risico dan wanneer er wordt geïnvesteerd in slechts één fonds. Nadat de portfoliobenadering zich heeft bewezen in de beleggingswereld is men deze benadering ook gaan hanteren bij het managen van IT-projecten. McFarlan (1981) kwam met het idee om voor risicoanalyse een portfoliobenadering te hanteren, zodat hiermee het beoogde eindresultaat behaald kon worden. Weill en Vitale (1991) hebben de portfoliowerkwijze geïntroduceerd om bij projecten de probleemgebieden in beeld te krijgen en waardoor het op voorhand al mogelijk is om verbeteringen door te voeren. De inzet van portfoliomanagement voor IT-projecten wordt gezien als de nieuwe manier voor het succesvol afronden van een project (Weill en Broadbent, 1998). Wel kent het hanteren van de portfoliobenadering in de IT een aantal struikelblokken omdat een ITproject niet in alle opzichten te vergelijken is met andere projecten. Een aantal redenen hiervoor zijn:  De investeringen welke worden gedaan betreffen uitgaven aan software en hardware. Deze producten worden niet aangeschaft om te bewerken tot een eindproduct, maar dienen ondersteunend te zijn. Er kunnen zelfs exit kosten aanwezig zijn (Jeffery & Leliveld, 2003; Verhoef & Kersten, 2004).  Normaliter wordt bij portfoliomanagement gekeken naar de opbrengsten welke gerealiseerd zullen worden door het project. Met een IT-project worden geen directe opbrengsten gegenereerd. Er is geen Return On Investment (ROI) aanwezig (Jeffery & Leliveld, 2003).  De impact van een IT-project kan verstrekkende gevolgen hebben voor de gehele bedrijfsvoering (Jeffery & Leliveld, 2003). De opkomst van de portfoliobenadering is mede ontstaan doordat de Verenigde Staten deze aanpak bij wet verplicht heeft gesteld. In Nederland is deze verplichting niet aanwezig. Wel is door de Algemene Rekenkamer (2007, 2008) aangegeven dat het hanteren van een portfoliobenadering leidt tot een beter eindresultaat van IT-projecten bij de overheid.

2.1

De portfoliobenadering voor het aansturen van IT-projecten

Het aansturen van projecten conform de portfoliobenadering wordt ook wel ITprojectportfoliomanagement (ITPPM) genoemd, kortweg portfoliomanagement. Het aan te sturen object betreft een IT-projectportfolio. De eerste fase van een IT-projectportfolio- is het ontwerpen van begrippenkader van de definitie, samenstelling, eigenschappen, relaties en afhankelijkheden van de IT-projectportfolio. In deze paragraaf zullen bovengenoemde zaken worden behandeld.

2.1.1

IT-projectportfolio definitie, samenstelling en kenmerken

Wanneer de literatuur er op wordt nageslagen zijn er veel definities aanwezig als het gaat om een project, programma of projectportfolio. Het Project Management Institute (PMI) heeft voor ieder van deze begrippen definities opgesteld:

10

Definities A project portfolio is a collection of projects or programs and other work that are grouped together to facilitate effective management to meet strategic business objectives (PMI, 2008). A program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside of the scope of the discrete projects in the program (PMI, 2008). A project is a temporary endeavor undertaken to create a unique product or service (PMI, 1996). Uit deze definities valt af te leiden dat een projectportfolio bestaat uit projecten en programma’s. Ook zijn programma’s weer op te delen naar verschillende projecten. Bovenstaande definities geven een samenhang weer tussen de projectportfolio, programma’s en projecten. Echter dient wel opgemerkt te worden dat een programma een tijdsbesteding kan hebben van meerdere jaren en dat projecten meestal een kortere tijdsbesteding hebben. Een projectportfolio is altijd aanwezig in een organisatie. Bestandsdelen van een IT-projectportfolio Een IT-projectportfolio bestaat uit projecten en programma’s welke betrekking hebben op informatietechnologie. In figuur 1 wordt een IT-projectportfolio weergeven welke samengesteld is uit twee IT-programma’s, te weten programma X en programma Y en meerdere IT-projecten, te weten project A tot en met project K.

Figuur 1: Samenstelling van een IT-projectportfolio

Relaties en afhankelijkheden In de literatuur is te lezen dat de IT-projectportfolio nagenoeg altijd bestaat uit meerdere typen van ITportfolio’s. Een IT-portfolio heeft altijd relaties met andere projecten. Het gehele project draagt de naam IT-projectportfolio. Door Weill en Broadbent (1998) wordt een onderverdeling gehanteerd naar een vier typen ITinvesteringen, te weten:  Strategisch;  Informatie;  Transactioneel;  Infrastructuur. Maizlish en Handler (2005) delen de IT-portfolio in naar verschillende soorten levenscycli. Dit leidt tot de volgende drie portfolio’s:  De IT-assetportfolio;  De IT-projectportfolio;  De IT-innovatieportfolio.

11

Kumar, Ajjan en Niu (2008) delen de IT-portfolio in naar de wijze waarop de verschillende onderdelen door de organisatie worden aangestuurd. Zij maken onderscheid in:  De applicatieportfolio;  De infrastructuurportfolio;  De IT-projectportfolio. Bovenstaande onderdelen geven aan dat een IT-projectportfolio relaties kan hebben met meerdere typen IT-portfolio’s. Het is zeer belangrijk dat de relaties tussen de verschillende type IT-portfolio’s in kaart worden gebracht. Wanneer deze relaties niet in beeld zijn gebracht is het onmogelijk om een projectportfolio goed aan te sturen (McFarlan (1981), Benko en McFarlan (2003) en Kumar, Ajjan en Niu (2008). Het model van Kumar, Ajjan en Niu (2008) laat zien dat een IT-projectportfolio relaties heeft met meerdere typen IT-portfolio’s (figuur 2).

Figuur 2: IT-portfolio (Kumar, Ajjan & Niu, 2008)

Dit model onderkent zowel relaties en afhankelijkheden binnen iedere portfolio als tussen de portfolio’s. De IT-projectportfolio als systeem Door verschillende personen wordt de IT-projectportfolio gezien vanuit een open systeemtheorie. Een aantal voorbeelden van deze personen zijn Sanchez, Robert en Pellerin (2008) en Harpum (2007). Bij deze theorie wordt een projectportfolio gezien als systeem waaraan een wijziging moet worden aangebracht om een einddoel te behalen. Met de term ‘open’ wordt aangegeven dat de wijzigingen die doorgevoerd moeten worden, invloed hebben op de gehele omgeving en andersom. Eén van de kenmerken van de open systeemtheorie is dat er altijd wordt gestreefd naar een hoger doel wat voordelen oplevert voor de gehele organisatie. In figuur 3 wordt een IT-projectportfolio weergegeven als open systeem met hierbij een evaluatie om vast te stellen of het einddoel is gerealiseerd.

Figuur 3: IT-projectportfolio als systeem (Sanchez, Robert en Pellerin, 2008).

2.1.2

IT-projectportfoliomanagement

Het doel van IT-portfoliomanagement betreft het realiseren van één of meer strategische bedrijfsdoelen, waarbij een zo’n groot mogelijke waard creatie plaatsvindt tegen zo laag mogelijk of door de organisatie geaccepteerde risico’s. Het doel van project- en programmamanagement is het behalen van het beoogde eindresultaat. Bij IT-projectportfoliomanagement gaat het om het uitvoeren

12

van projecten welke voor de organisatie het meeste waarde creëren. Dit blijkt uit een studie van Morris & Jamieson (2004) en Reyck et al. (2005). Door onder andere Cooper, Edgett en Kleinschmidt (1999), Elonen en Artto (2003) en Reyck et al. (2005) zijn een drietal doelen geformuleerd met betrekking tot IT-projectportfoliomanagement:  Project alignement met de korte termijn en lange termijn strategische doelstellingen;  Portfolio voor de maximalisatie van waard creatie;  Portfolio balanceren en optimaliseren op bedrijfswaarde tegen acceptabel risiconiveau. Vanuit de literatuur is de volgende definitie van IT-projectportfoliomanagement geformuleerd: IT-portfoliomanagement is managen van een bewust gekozen, cyclisch veranderend geheel van activiteiten, projecten en programma's om de strategische doelstellingen van een organisatie te bereiken. De doelstelling van IT-portfoliomanagement is het vaststellen van de optimale balans tussen het belang van de activiteiten en het gebruik van de schaarse resources, het rekening houden met de risico’s en kansen die de omgevingsfactoren bieden en het bereiken van de strategische doelstellingen van de organisatie. Organisaties denken (idealiter) vanuit een strategie. Om de strategie te doen slagen zal de organisatie iets moeten doen, een unieke verandering moeten doormaken. Hiervoor staan schaarse middelen ter beschikking. IT-portfoliomanagement is de discipline die ervoor zorgt dat de strategie op een beheerste wijze wordt gerealiseerd IT-projectportfoliomanagement wordt beschreven in processen en activiteiten. Er zijn in de literatuur veel verschillen op te merken wanneer het gaat om IT-projectportfoliomanagement, echter er zijn een aantal kernfuncties welke nagenoeg overal worden opgenomen:  Alignment. Hierbij gaat het om het selecteren, plannen en stellen van prioriteit wanneer het gaat om nieuwe projecten om strategische bedrijfsdoelstellingen te realiseren;  Bewaken en controleren. Dit bestaat uit controleren, bijsturen en evaluatie van projecten. Er wordt gekeken of de beoogde doelstellingen zijn behaald binnen de gedefinieerde eisen zoals tijdsbesteding en budget.

13

2.2

IT-projectportfolio beheersing

Wanneer er een project wordt uitgevoerd zijn hier altijd risico’s aan verbonden. Met een risico wordt bedoeld dat er altijd onzekerheden aanwezig zijn welke zich in de toekomst gaan voordoen. Het beheersen van risico’s met betrekking tot IT-projectportfolio is gericht op het voorkomen, tijdig mitigeren of accepteren van de oorzaak. Ook het verlagen van de impact hoort bij het beheersen. Hierdoor wordt ‘de gezondheid’ van de IT-projectportfolio verbetert en is de kans groter dat het beoogde einddoel van de IT-portfolio wordt gerealiseerd (Benko & McFarlan, 2003; Drake & Byrd, 2006; Sanchez, Robert & Pellerin, 2008).

2.2.1

Definitie en kenmerken

Door Heemstra en Kusters (2002) wordt de volgende definitie gegeven aan de risico’s met betrekking tot IT-projectportfolio: De kans dat een bepaalde gebeurtenis optreedt en het (meestal negatieve) effect op het projectportfolioresultaat. Tevens worden er twee elementen van een risico geformuleerd door Heemstra & Kusters (2002): 1. De mate van onzekerheid van het optreden van een gebeurtenis. Dit wordt uitgedrukt in een kans of een waarschijnlijkheid. Is de kans 100% dan is er geen sprake meer van een risico maar van een probleem. 2. Het (negatieve) effect van het optreden van de gebeurtenis. De risico-impact is het effect van het optreden van een gebeurtenis op bedoeld resultaat. Wanneer een risico wordt geconstateerd is van belang om eerst de oorsprong te identificeren van het risico om de gepaste maatregelen te nemen om het risico te mitigeren. Dit wordt door Heemstra & Kusters (2002) risicobronnen genoemd. Wanneer inzichtelijk is gemaakt het risico is en wat de risicobronnen zijn kan er tijdig worden bijgestuurd om het risico te mitigeren danwel de impact te verkleinen.

2.2.2

Risicogebieden

In deze paragraaf wordt een opsomming gegeven van de risico’s zoals deze blijken uit de bestudeerde literatuur. Hiervoor zijn in de literatuur zoektermen gebruikt zoals risico’s, risicofactoren, problemen, succesfactoren, best practices en dergelijke. De gevonden risico’s zijn onderverdeeld in zes categorieën, te weten:      

Risico’s vanuit de organisatie, haar governance en omgeving. Risico’s vanuit personele capaciteit en competenties. Risico’s vanuit processen en de uitvoering van IT-projectportfoliomanagement. Risico’s vanuit de samenstelling van de IT-projectportfolio als geheel. Risico’s vanuit de individuele IT-projectportfoliocomponenten. Risico’s vanuit afhankelijkheden en relaties van de IT-projectportfoliocomponenten.

Risico’s vanuit de organisatie, haar governance en omgeving Risico’s welke betrekking hebben op de organisatie zelf hebben vooral betrekking op beschikbaarheid en de juiste skills en ervaring van de teamleden. Maar ook governance, een duidelijke verdeling van taken, verantwoordelijkheden en bevoegdheden, ervaring bij de uitvoering van projecten en het kunnen omgaan met veranderingen (Elonen & Artto, 2003; Reyck et al., 2005; Jonas, 2010; Frey & Buxmann, 2012). Ook moet er te allen tijde rekening worden gehouden met de invloed welke de

14

politiek kan uitoefenen door het wijzigen van aan wet- en regelgeving of het niet tijdig nakomen van (politieke) doelstellingen(Algemene Rekenkamer, 2007; ISACA, 2009). Risico’s vanuit personele capaciteit en competenties Als risico wordt genoemd dat er onvoldoende inzetbare en vakbekwame medewerkers en de stabiliteit van de personele bezetting aanwezig is. Wanneer er tijdens het project vaak wisselingen plaatsvinden van teamleden betreft dit een risico voor het succesvol afronden van het project (McFarlan, Elonen (1981) & Artto, Jeffry & Leliveld (2004)). Risico’s vanuit processen en uitvoering van IT-projectportfoliomanagement Er zijn door diverse onderzoeken problemen geconstateerd als gevolg van ineffectief ITprojectportfoliomanagement:   De verkeerde projecten. Projecten die geen meerwaarde hebben voor de organisatie of niet overeenkomen met de strategie of toekomstplannen;  Een te groot aantal actieve projecten. Door de diversiteit van projecten in type, omvang en doelstellingen is het voor het management lastig om overzicht te houden op welke projecten er actief zijn en wat hiervan de status is;  Geen duidelijke balans in de projectportfolio en resourceallocatie: o Te veel nadruk op ontwikkeling en te weinig op onderzoek. o Te veel nadruk op korte termijn. o Te veel riskante projecten. o Te veel beslag op en concurrentie om essentiële resources.  Alleen aandacht voor enkele belangrijke projecten, waarbij geen rekening wordt gehouden met het geheel;  Projecten waardoor er verschillen ontstaan tussen projectdoelen;  Vanuit de business leiding te weinig draagvlak. Risico’s vanuit de samenstelling van de IT-projectportfolio Er is sprake van risico vanuit de IT-projectportfolio als geheel wanneer de samenstelling ervan niet voldoet aan de eisen die gesteld worden aan een gezonde portfolio. Een gezonde IT-projectportfolio draagt met bij aan de doelen welke door een organisatie op lange termijn worden gesteld. Enkele kenmerken van een gezonde IT-projectportfolio zijn: 1. In lijn met de organisatiestrategie. De beoogde einddoelen liggen in lijn met de ITprojectportfolio met de strategie van de organisatie of de toekomstige plannen; 2. Maximale waard creatie uit IT-investeringen. De financiële resources van organisaties zijn over het algemeen beperkt. Er kan niet te veel geld in een project worden gestoken omdat het terugverdientijd over meerdere jaren wordt verspreid. Een belangrijke drijfveer voor organisaties is het maximale resultaat te behalen met zo weinig mogelijk middelen en geld; 3. Gebalanceerd. Een portfolio is goed in balans wanneer de kenmerken genoemd bij één en twee aanwezig zijn zonder een organisatie bloot te stellen aan risico’s welke niet worden geaccepteerd. Bij de uitvoering van IT-projecten zijn altijd risico’s verbonden. Door het vinden van de juiste balans tussen de bedrijfswaarde en bedrijfsrisico kan een optimale balans worden gevonden tussen toekomstige meerwaarde in geldmiddelen en risico’s; 4. Zowel korte termijn als lange termijn visie. IT-projecten hebben over het algemeen betrekking op een langere termijn. Via deze investeringen kan een organisaties zowel aan hun huidige als toekomstige behoefte voorzien. De IT-projectportfolio moet dan zowel op korte als op langere termijn voldoen aan strategische doelen van een organisatie.

15

Risico’s vanuit de individuele IT-projectportfoliocomponenten Risico’s vanuit de individuele IT-projectportfoliocomponenten betreffen het falen van individuele ITprojecten of IT-programma’s door het niet opleveren van resultaten binnen de gestelde tijd, budget en kwaliteit (Drake en Byrd (2006), Jeffery en Leliveld (2004), Benko en McFarlan (2003) en Kumar, Ajjan en Niu (2008). Risico’s vanuit afhankelijkheden en relaties van de IT-projectportfoliocomponenten Er is sprake van afhankelijkheid wanneer meerdere aspecten van projecten zoals kosten en baten, of resources samenhangen met andere projecten welke worden uitgevoerd of staan gepland. Door de samenhang tussen deze projecten kan dit het succes of falen van andere projecten beïnvloeden en daarmee het algehele portfolioresultaat. Dit houdt in dat het falen van één project of programmaonderdeel vervolgfalen kan hebben voor alle projecten welke worden uitgevoerd en dus uiteindelijk op de gehele IT-portfolio.

2.3

Faalfactoren bij projecten

Uit onderzoek is gebleken dat de meeste bedrijven een beperkte effectiviteit hebben in het managen van projecten (Cicmil, 1999). 75%-80% van de gestarte projecten mislukt (Rosacker en Olson, 2008; Ward et al., 2007; Boersma et al., 2007; Ives, 2005; Drummond en Hodgson, 2003; Cozijnsen et al., 2000; Prakken, 1997). De vraag is waarom deze projecten mislukken. Om deze vraag te kunnen beantwoorden zal eerst moeten worden aangegeven wat de eisen zijn waaraan een geslaagd project moet voldoen. De manier waarop wordt getoetst of een project geslaagd is, is een lastig punt. Is een project succesvol afgerond wanneer deze binnen de gestelde eisen is opgeleverd of is een project geslaagd wanneer een klant zijn goedkeuring geeft (Anantatmula, 2008; Drummond en Hodgson, 2003; Cicmil, 1997; Belassi en Tukel, 1996; Matthijssen, 1998. Bij het doorlezen van diverse artikelen wordt er op deze vraag geen duidelijk antwoord gegeven. Uit onderzoek onder nagenoeg duizend projectmanagers zijn een aantal factoren naar voren gekomen wanneer een project kan worden beschouwd als succesvol (White en Fortune, 2002):       

voldoet aan de gebruikerseisen; is afgerond binnen de gestelde tijd; is afgerond binnen het beschikbare budget; voldoet aan de organisatiedoelen; heeft toegevoegde waarde voor de organisatie; heeft minimale bedrijfsverstoringen opgeleverd; voldoet aan kwaliteitsstandaarden.

Toch geeft het uitgevoerde onderzoek geen goed beeld van de werkelijke weergave. Wanneer er wordt gekeken naar de ondervraagde personen betreft het in alle gevallen een projectmanager. Er is dus bijvoorbeeld niet gekeken naar de eindgebruikers en naar de leiding van de organisatie. Zij kunnen hele andere opvattingen hebben over dat het project wel of niet succesvol is uitgevoerd. Een organisatie welke uitgebreid onderzoek doet naar het slagen en mislukken van projecten met betrekking tot IT is de Standish Group. Deze organisatie houdt zich al sinds 1985 bezig met dit type onderzoeken. Uit het onderzoek wat de Standish Group heeft verricht in 2012 is gebleken dat 39% van alle projecten succesvol is afgerond. Dit houdt in dat het project tijdig is opgeleverd, binnen budget is gerealiseerd en alle functionaliteiten heeft zoals vereist. 43% van de projecten zijn afgerond, echter niet binnen de

16

gestelde tijd, het budget of er ontbreken functionaliteiten. De projecten behorende bij de laatste 18% zijn gefaald. Deze cijfers vertegenwoordigen een stijging in de succespercentages van de vorige onderzoeken, en een daling van het aantal mislukkingen. Het dieptepunt in de laatste vijf onderzoeken was 2004, waarin slechts 29% van de projecten succesvol waren. In onderstaand figuur zijn de onderzoeken van de afgelopen jaren opgenomen. Hierin is een stijgende lijn te zijn van de projecten wat succesvol slaagt.

Ook is inzichtelijk gemaakt op welk vlak de projecten worden overschreden. Het bepalen van de relatie van projectoverschrijdingen tot geleverde functies is een analytisch proces. Uit de cijfers van 2012 blijkt een lichte stijging van zowel de overschrijdingen met betrekking tot de kosten en tijd. Kostenoverschrijdingen zijn gestegen van 56% in 2004 naar 59% in 2012. Tijdsoverschrijdingen zijn ook gestegen, namelijk van 71% in 2010 naar 74% in 2012. Het hoogtepunt in de overschrijdingen met betrekking tot tijd was in 2004 (84%). Ontwikkelde functies welke op voorhand vereist waren daalden van 74% in 2010 tot 69% in 2012.

2.3.1

Welke elementen zorgen dat een project faalt?

De huidige bedrijfsomgeving is complex, onzeker en veranderlijk. Hierdoor zullen in toenemende mate wijzigingen worden doorgevoerd aan de bestaande organisaties door middel van het uitvoeren van projecten (Ives, 2005). Wanneer een organisatie wijzigingen wil gaan doorvoeren wordt hier normaliter een project voor aangemaakt om op een gestructureerde manier het einddoel te behalen. Projecten worden gestart om een vooraf gedefinieerd doel te behalen. Deze projecten zijn ontworpen op basis van aannames met betrekking tot menselijk, organisatorisch en technisch gedrag. Het tussentijds aanpassen van het project kan als gevolg hebben dat planningen en budgetten niet worden gehaald, maar erger nog dat het gehele project faalt. Projectfalen is meestal niet terug te leiden naar een enkele faalfactor, maar naar een combinatie van factoren die, verspreid in de tijd, projectfalen tot gevolg hebben (Ives, 2005; Ivory en Alderman, 2005; Drummond en Hodgson, 2003).

17

Een recent voorbeeld van projectfalen betreft het bekende British Braodcasting Company (BBC). In 2008 zijn zij gestart met het project genaamd Digital Media Initiative. Dit project heeft als doel een tool te ontwikkelen voor het bewerken van video en geluid tot een eindproduct wat uitgezonden kan worden. Dit project is uitbesteed aan Siemens, met een vaste prijsafspraak van £ 82 miljoen. In juli 2009 is het contract met Siemens beëindigd voor het uitvoeren van dit project omdat zij niet met de gewenste resultaten kwamen. Er is voor gekozen om DMI intern verder te ontwikkelen. Naarmate het werk vorderde kwamen er steeds meer problemen naar voren. In mei 2013 is er voor gekozen om te stoppen met het project. De werkelijke kosten van het project bedroegen inmiddels £ 100 miljoen. De volgende oorzaken voor het falen van dit project zijn afgegeven aan de pers:  onderschatting van de complexiteit;  ineffectieve governance structuur;  hiërarchische organisatiestructuur waardoor informatiestromen werden geblokkeerd;  gebrekkige procedure met betrekking tot het selecteren van een leverancier;  gebrekkig toezicht op de leverancier. Bovenstaande oorzaken worden ook in de onderzochte literatuur genoemd voor het falen van projecten. Een aantal andere oorzaken zijn:  projecten zijn te groot;  niet voldoende kennis van nieuwe technieken;  onvoldoende kennis van projectleden;  slechte monitoring en sturing;  projectleden hebben geen binding met het project of de organisatie;  wijzigingen van wet en regelgeving;  planning is niet reëel;  slechte bewaking van de planning;  gebrek aan communicatie tussen projectleden en externe partijen;  doelstellingen zijn niet duidelijk geformuleerd;  projectleden krijgen niet voldoende ruimte in de planning voor het uitvoeren van het project. (Ernst & Young, 2008; Algemene Rekenkamer, 2007; Martijnse en Noordam, 2007; Ives, 2005; Drummond en Hodgson, 2003; Tesh et al., 2003; Kuruppuarachchi et al., 2002; Dey, 2002; The Standish Group, 2001, 1999, 1995; Cicmil, 1997; Prakken, 1997).

2.3.2

Overschrijding van de begrote kosten

Door de Algemene rekenkamer is in 2007 een onderzoek uitgevoerd waarbij is gekeken naar het verloop van diverse IT-projecten binnen de overheid welke in de problemen zijn geraakt. Er is hier expliciet aandacht aan besteed omdat deze projecten worden gefinancierd met publiek geld. In dit onderzoek is naar voren gekomen dat projecten meer tijd kosten dan begroot en dat de kosten worden overschreden. Door de onderzoekscommissie zijn een vijftal projecten onderzocht. In onderstaande tabel zijn de projecten aangegeven met hierbij de begrote en vervolgens de werkelijke kosten in miljoenen euro’s. N.B. de gegevens in de tabel en tekstuele toelichting hebben betrekking op de periode waarin het onderzoek is uitgevoerd, te weten 2007.

18

Project

Raming

Realisatie of prognose

C2000 Walvis NVIS SUB Toeslagen

598 360 12 129 77

793 (2 jaar later) 367 (realisatiedatum nog niet bekend) 24 (2,5 jaar later) 202 (realisatiedatum nog niet bekend) 275 (2 jaar)

Tabel 1: Raming en (geplande) realisatie projectkosten (bedragen x € 1 miljoen)

Uit de bovenstaande tabel is af te lezen dat alle projecten het budget al (ruim) hebben overschreden. Wel dient opgemerkt te worden dat slechts één project reeds is afgesloten (C2000). Ook zijn er tijdens de projecten extra eisen en wensen toegevoegd welke niet van oorsprong zijn opgenomen in de kostenraming. Hierdoor zijn de kosten niet in alle gevallen consequent bijgehouden. Onderstaand wordt een verklaring gegeven voor de kostenoverschrijding per project. C2000 C2000 is het landelijke communicatiesysteem voor de hulpverleningsdiensten in Nederland. Het wordt 24 uur per dag, zeven dagen in de week gebruikt door vooral politie, brandweer, ambulancediensten en bepaalde onderdelen van het ministerie van Defensie zoals de Koninklijke Marechaussee. Het systeem C2000 is tijdens de uitvoering van het project op meerdere vlakken gewijzigd ten opzichte van de oorspronkelijke plannen: van een aantal oorspronkelijke uitgangspunten is afscheid genomen, waardoor kosten uit de projectbegroting zijn geschrapt. Daarnaast is de verdeling van de kosten aangepast. Er heeft een verschuiving plaatsgevonden tussen de kosten welke in rekening zijn gebracht bij het Rijk en de kosten welke zijn toegerekend aan de regio’s. Het Rijk heeft uiteindelijk een veel groter deel van de kosten voor haar rekening genomen. Ook bleek dat een aantal kostenposten niet waren opgenomen in de projectbegroting. Een kostenbesparing tijdens het project bleken de kosten voor randapparatuur. De kosten hiervoor kwamen veel lager uit dan begroot. Walvis ‘Walvis’ – wet administratieve lastenverlichting en vereenvoudiging in sociale zekerheidswetgeving had als doel het stroomlijnen van het loonbegrip. Werkgevers zouden niet langer salarisgegevens aan het UWV hoeven te leveren voor de premieheffing, maar uitsluitend aan de Belastingdienst Een onderdeel van de begrote projectkosten hebben betrekking op het sociaal plan. Omdat er taken van het UWV komen te vervallen is er een sociaal plan opgesteld voor de medewerkers die boventallig zullen worden verklaard. De kosten voor de uitstroom van medewerkers door het sociaal plan zijn geraamd op € 145 miljoen. Hierbij zijn de kosten voor werkloosheidsuitkeringen en pensioenregelingen (€ 79 miljoen) nog niet meegenomen. Door het UWV is een verwachting afgegeven dat de uiteindelijke kosten lager zullen uitvallen, namelijk € 83 miljoen in plaats van de begrote € 145 miljoen. De kosten met betrekking tot ICT-middelen zullen echter hoger uit vallen dan opgenomen in de projectbegroting. De kosten zijn met een bedrag van € 54 miljoen toegenomen tot een bedrag van € 212 miljoen. UWV gaat er vanuit aan € 367 miljoen genoeg te hebben om Walvis te voltooien. Eind 2007 was hiervan € 269 miljoen reeds uitgegeven. NVIS Nieuw Visum Informatie Systeem (NVIS) is in het leven geroepen om het proces van visumverlening efficiënt, effectief en rechtmatig te laten verlopen. Net als C2000 zijn bij NVIS gedurende de uitvoering van het project functionaliteiten aangepast. In eerste instantie was biometrie niet opgenomen in het project, na verloop van tijd is dit toegevoegd. Een ander aspect wat de kosten van dit project heeft beïnvloed zijn de uren. In de projectbegroting zijn uren maal een tarief opgenomen. In de realisatie zijn deze kosten buiten beschouwing gelaten. Het Ministerie van Buitenlandse Zaken wilde wel inzicht hebben in de kosten die de inzet van het eigen personeel met zich meebracht.

19

SUB Het project SUB (Samenwerking UWV Belastingdienst) heeft de verantwoordelijkheid om een deel van de administratieve verwerking voor de UWV te realiseren. De stijging van de kosten van het project SUB zijn nagenoeg geheel ontstaan door een stijging van de kosten met betrekking tot ICT. De kosten zijn nagenoeg verdubbeld van € 84 miljoen naar een bedrag van € 150 miljoen. De oorzaken die worden genoemd voor deze verdubbeling zijn een ondeugdelijke raming, politieke druk en het onderschatten van de organisatorische en technische complexiteit. Toeslagen De cijfers welke zijn opgenomen in de tabel zijn voor zowel het eerste project als het tweede project Toeslagen. Het eerste, oorspronkelijke, project was gericht op een systeem voor de huur- en zorgtoeslag. Met het tweede project wil de Belastingdienst ‘één generiek, integraal en flexibel systeem’ neerzetten. Hieronder wordt verstaan het inrichten en met een nieuw ICT-systeem ondersteunen van een geheel nieuw bedrijfsproces. Bij het project Toeslagen zijn de verbouwingen van een kantoorpand en de inrichting van callcenters niet opgenomen in de begroting. De kosten voor deze verbouwing en inrichting zijn wel opgenomen in de kolom realisatie in de tabel. De totale kosten worden door het Ministerie van geschat op totaal € 275 miljoen.

2.3.3

Succesfactoren

Het is interessant om te onderzoeken wat de redenen zijn waarom IT-projecten mislukken. Dit roept meteen een andere vraag op: Waarom slagen IT-projecten? Misschien is dat de belangrijkste vraag. Om die reden is het niet genoeg om alleen de redenen voor het falen van een IT- project te onderzoeken, maar ook wat gedaan kan worden om de kans op succes voor de toekomstige projecten te verbeteren. Bij de herziening van literatuur over projectmanagement komen een aantal factoren naar voren die van invloed zijn voor het succes of falen van een:  Project management (54%): Het definiëren van de activiteiten en het beheersen van het ITproject;  Zakelijk aspect (21%): Aspecten van het project welke te maken hebben met de financiering van projecten, het intern rendement en bedrijfsgegevens:  Mensen (14%): Het team dat het IT-project uitvoert;  Methode (8%): De dimensie met betrekking tot de aanpak, procedures en instrumenten;  Technisch (3%): Aspecten van het project met betrekking tot hardware en software, het testen en interfaces tussen componenten. Project management maakt al vele jaren deel uit van de IT. Dus waarom zijn er zoveel problemen die nog rechtstreeks verbonden zijn met de manier waarop een project wordt gemanaged? Deze problemen komen vaak neer op zeven belangrijkste redenen voor het mislukken van IT-project. Door dieper te graven en het identificeren van de mogelijke valkuilen, kan worden bekeken waardoor deze misstappen in de toekomst kunnen worden vermeden en waardoor de kans op succes verbetert. 1. Projectplanning en -sturing Verbetering van projectplanning en -sturing is een van de belangrijkste factoren in het succes van een IT-project. Dit vereist een methode die bestaat uit regels, processen en tools voor projectplanning en management, ondersteund door een software tool. Een essentieel onderdeel van de planning is om de juiste mensen toe te wijzen aan de juiste taak en duidelijke afspraken te maken met de teamleden, met hierbij gedefinieerde doelen en verantwoordelijkheden. Wanneer afspraken niet blijken te werken, moeten rollen aangepast worden.

20

2. Communicatie Objectieve voortgangsrapportages, regelmatig contact met teamleden en eindgebruikers en de betrokkenheid van externe partijen zoals de hardware leverancier zijn cruciaal voor het vermijden van de miscommunicatie wat kan leiden tot het ontsporen van IT-projecten. Eenvoudige handelingen, zoals georganiseerde agenda's, notulen, actiepunten en het delen van informatie via e-mails kunnen bijdragen aan een goede communicatie. Agenda's dwingen de projectmanager om vergaderingen in te plannen en te zorgen dat alle teamleden hiervoor tijd beschikbaar hebben. Ook dient er voorbereidende documentatie te worden verstrekt wat besproken kan worden tijdens de vergaderingen. Het bedenken en het treffen van de voorbereiding van de agenda is belangrijker dan de agenda zelf. Ook de manier waarop het bericht wordt gecommuniceerd is belangrijk, vooral voor uitvoerende beoordelingen. Het hanteren van dezelfde manier van presenteren van informatie kan een efficiënte methode zijn, maar het kan ook leiden tot het ontbreken van interesse in het verhaal achter de voortgang bij teamleden. 3. Effectief management en sturing Voorkomen van deze valkuil kan behaald worden door proactief managen van bijgestelde objecten, doelen en risico’s, het coördineren van de inspanningen tussen de technologie en financiële afdelingen en het meten van prestaties. Implementeer een eenvoudig change-managementproces met inschattingen en stappen met goedkeuring door de diverse teamleden. Dit moet een eenvoudig proces zijn, maar wel een proces waarbij het management begrijpt wat de impact is van de veranderingen. Maak gebruik van een risicomanagementtool om risico's die tijdens en na het project ontstaan te mitigeren. Formaliseer een business case en koppel hieraan het de financiële impact. Ten slotte stel een planning op wanneer doelen binnen de business case gerealiseerd moeten zijn, zoals geplande en werkelijke start van taken en wanneer deze voltooid moeten zijn en neem deze op in de voortgangsrapportages. 4. Het uitlijnen met de achterban en belanghebbenden Het opbouwen van begrip en vertrouwen met eindgebruikers en belanghebbenden is essentieel voor een succesvol resultaat, in het bijzonder wanneer deze partijen werkzaam zijn bij verschillende organisaties en verschillende motivaties hebben voor het uitvoeren van het project. Benoem voor een betere betrokkenheid specifieke initiatieven om samenwerking en communicatie met belanghebbenden te creëren. Dit kan gerealiseerd worden door middel van het verzamelen van input voor vergaderingen en met regelmaat versturen van informatie naar alle betrokkenen. In de beginfase van het IT-project is het handig om face-to-face ontmoetingen te hebben met de belangrijkste belanghebbenden en teamleden. Een goed geplande kick-off meeting, waar relaties worden ontwikkeld, zal het project ondersteunen in latere maanden. 5. Effectieve betrokkenheid van het uitvoerend management De deelname van een senior medewerker van de stuurgroep in de belangrijkste operationele werksessies is van cruciaal belang om prioriteiten te stellen. Project kick-off is de beste eerste bijeenkomst, maar hier eindigt het niet. Betrokkenheid van iemand van de stuurgroep op hoog niveau binnen de organisatie moet gericht zijn op specifieke bijeenkomsten om voortgang van het project monitoren, vooral in de bijeenkomsten waar go / no-go beslissingen moeten worden genomen. 6. Aandacht voor soft skills of het aanpassingsvermogen Om een situatie te voorkomen waarin teamleden niet over de nodige vaardigheden voor het project beschikken, is het raadzaam om gebruik te maken van een mentoring aanpak voor minder ervaren medewerkers. Ook is het raadzaam om vereiste trainingen op te nemen in de totale projectplanning. Actief werven van gekwalificeerd personeel is benodigd voor een goed eindresultaat van het project.

21

7. Effectieve methodologie en auditinstrumenten Succesvolle projecten zijn gebaseerd op een methodologie of raamwerk dat project - management tools omvat. Deze aanpak helpt de nauwkeurigheid te vergroten en tijd besparen door het automatiseren van activiteiten.

22

3 Instrumenten voor project auditing Zoals aangegeven kan een organisatie er voor kiezen om een auditinstrument te hanteren. In de literatuur wordt veelal de term projectmanagementmethode gehanteerd. In de literatuur worden verschillende definities genoemd voor de projectmanagementmethode: Lehtonen en Martinsuo, 2006 “Een projectmanagementmethode is de manier waarop een organisatie gedurende het project stuurt en besluiten neemt”. Baardman et al., 2006 “Het is een systematische, weldoordachte wijze van handelen om een resultaat te bereiken dat bijdraagt aan een doel”. Neering et al., 2005 “Het is een vanuit een bepaalde aanbevolen aanpak voor het beheersbaar uitvoeren van een bepaalde scope aan activiteiten binnen een project. Deze aanpak adviseert de gebruiker over de op te leveren producten en de (mogelijk) te gebruiken technieken en hulpmiddelen bij het doorlopen van de activiteiten”.

3.1

Voordelen van het hanteren van een auditinstrument

Niet iedereen heeft dezelfde denkwijze wanneer het gaat om het hanteren van projectmanagementmethoden (Lehtonen en Martinsuo, 2006). Er wordt standaard van uitgegaan dat projectmanagementmethoden altijd zullen leiden tot meer succesvolle projecten. Er wordt hierbij veelal geen onderscheid gemaakt in het type project en de projectmanagementmethode welke hierbij wordt gehanteerd (Dvir et al., 2006). Tientallen jaren onderzoek heeft inmiddels aangetoond dat het hanteren van een projectmanagementmethode geen aantoonbare meerwaarde heeft. Organisaties zijn te veel gericht op de implementatie van het project zelf waardoor er te weinig aandacht wordt gegeven aan de organisatorische veranderingen (Ward et al., 2007). Onderzoek van methoden voor projectmanagement in een periode van tien jaar (1996-2006) laat zien dat er een toename is van 28% van het hanteren van een projectmanagementmethode door organisaties. Wanneer er wordt gekeken naar de succesfactor van deze projecten komt naar voren dat slechts 1% van de projecten succesvoller is afgerond (Ward et al. 2007). Uit andere onderzoeken blijkt dat het hanteren van een projectmanagementmethode in beperkte mate bijdraagt aan een kostenverlaging en een verkorte doorlooptijd van een project. Dit wordt door organisaties wel gezien als belangrijkste redenen voor het gebruiken van een projectmanagementmethode. Het verloop van het project zelf gaat wel op een gestructureerde manier en het eindresultaat ligt dichter bij de op voorhand aangegeven eisen (Neering et al., 2005). Er is door meerdere onderzoeken vastgesteld dat het hanteren van een projectmanagementmethode bijdraagt aan een hoger slagingspercentage van projecten. Een voorbeeld hiervan is het onderzoek van Lehtonen en Martinsuo (2006). Ook in de top 10 van de Standish Group staat al jaren het gebruik van projectmanagementmethoden als kritische succesfactor voor het afronden van een project wat aan de juiste vereisten voldoet. Door Ernst & Young is in 2010 een onderzoek uitgevoerd met betrekking tot ICT-projecten. Van de ondervraagde organisaties maakt 22% gebruik van portfoliomanagement. Dit is minder dan in 2009, toen was dit 31%. Uit het onderzoek blijkt dat het aantal succesvolle projecten met 10% is gestegen

23

t.o.v. voorgaand jaar. De tevredenheid daalt echt wel met 47%. De projectmanagers waren minder tevreden met de uitkomsten van het project. In 2009 lag dit percentage op 42%. Binnen het onderzoek is gekeken naar verschillende soorten projecten. In onderstaande figuur is weergegeven per soort project in welke mate de implementatie succesvol is geweest.

Figuur 4: In welke mate zijn ICT-projecten succesvol?

Ook heeft er onderzoek plaatsgevonden naar de reden waarom een project niet succesvol is afgerond. In figuur 5 is aangegeven welke redenen er zijn en welke het hoogste scoort.

Figuur 5: Waarom is de invoering van het project niet (helemaal) succesvol?

Wanneer een organisatie in staat is om op bovenstaande punten in te spelen, wordt de kans verhoogd dat een project met meer succes wordt afgerond en beter beheersbaar wordt.

3.2

Meest gehanteerde projectmanagementmethoden

In 2002 is door White en Fortune een onderzoek uitgevoerd. Hierbij is onderzocht hoeveel organisaties een auditinstrument gebruiken bij het uitvoeren van een project. Hierbij is geconstateerd dat van de 240 onderzochte organisaties 72% een auditinstrument hanteert. In 2012 is door KPMG een soortgelijk onderzoek uitgevoerd. Hierbij is vastgesteld dat 85% van de ondervraagde organisaties een auditinstrument hanteert. Tevens blijkt uit dit onderzoek dat de meest gehanteerde auditinstrument PRINCE2 betreft. In ca. 50% wordt er een zelfontwikkelde methode gehanteerd, welke wel vaak op een bestaande methode is gebaseerd.

24

Figuur 6: Onderzoek KPMG (2012) naar gehanteerde methodiek

Door onder andere Neering et al. (2005) en Baardman et al. (2006) is onderzoek gedaan naar de meest gebuikte methodes van auditinstrumenten in Nederland. In onderstaande tabel zijn deze instrumenten weergegeven: Nr. 1 2 3 4 5 6 7 8 9 10 11 12 13

Auditinstrument A4 projectmanagement New Product Development PMBOK, Project Management Body of Knowledge Prince2, PRojects IN Controlled Environments Procesmanagement Projectmatig creëren Projectmatig werken System Management Scrum PROPS Project Management method Doeltreffend Projectmanagement Managing the implementation of the Total Project

In de gehanteerde literatuur komen: ‘Project Management, Body of Knowledge’ (PMBOK) en Prince2 het meeste voor in citaten en worden het vaakst gehanteerd door organisaties. PMBOK komt van oorsprong uit de Verenigde Staten, Prince2 (Projects in controlled environments) daarentegen is ontwikkeld in het Verenigd Koninkrijk. Dit blijkt ook uit de literatuur. Wanneer er een artikel wordt gevonden wat is geschreven door Amerikanen wordt meestal Prince2 genoemd, wordt het artikel geschreven door iemand uit het Verenigd Koninkrijk, dan wordt veelal PMBOK genoemd. Prince2 is ook het meest gehanteerde auditinstrument in Europa. Dit geldt ook voor Nederland, uit onderzoek blijkt dat Prince2 hier voornamelijk wordt gehanteerd bij de uitvoering van een project (Martijnse en Noordam, 2007; Ward et al., 2007; Neering et al., 2005, KPMG 2012). Ook organisaties die voorheen nooit een auditinstrument hebben gehanteerd bij de uitvoering van een project overwegen om Prince2 aan te schaffen om meer structuur aan te brengen in de uit te voeren projecten (Neering et al., 2005).

25

3.2.1

Prince2

Definitie project Een project is een tijdelijke organisatie die in het leven is geroepen met als doel de oplevering van één of meer producten op grond van een overeengekomen business case. Historie PRINCE, afkorting van Projects IN Controlled Environment, is in 1989 ontworpen door het toenmalige Central Computer and Telecommunication Agency (CCTA) van de Britse overheid. De methode was aanvankelijk gericht op ICT-projecten. In 1996 is PRINCE2 geïntroduceerd als generieke standaard voor alle typen projecten. PRINCE2 richt zich op een procesmatige aanpak van projectmanagement en is gebaseerd op de jarenlange praktijkervaring van vele projecten, projectmanagers en projectteams. De methode wordt regelmatig aangevuld met nieuwe inzichten. Scope PRINCE2 is zowel gericht op het managen van een project als op het managen van de inzet van mensen en middelen in een project. De methode is niet bedoeld om alle aspecten van projectmanagement af te dekken. Er zijn drie brede gebieden die opzettelijk buiten de scope van PRINCE2 worden gehouden: specialistisch werk, technieken en leiderschapskwaliteiten. Dat is tegelijkertijd ook de kracht van de methode. Het succes staat of valt met het aanpassen van de methode aan de organisatie en aan het belang, de omvang, de doorlooptijd en de kosten van het project. Uitgangspunten PRINCE2 is gebaseerd op de volgende aannames:  Projecten worden uitgevoerd in een beheerste omgeving.  Een project is pas succesvol als alle betrokken partijen tevreden zijn met het projectresultaat (en daarbij hebben vaak de gebruikers de meeste invloed op de mening van de andere partijen).  Succesvolle projecten zijn ‘business driven’.  Samenwerking tussen alle bij het project betrokken partijen leidt tot meer succesvolle projecten.  Wat werkt wordt bepaald door de praktijk.

Figuur 7: De hoofdstructuur van PRINCE2

26

Vanuit de uitgangspunten van PRINCE2 zijn de volgende principes benoemd:  Voortdurende zakelijke rechtvaardiging.  Leren van ervaringen.  Gedefinieerde rollen en verantwoordelijkheden.  Managen per fase.  Management by exception.  Productgerichte aanpak.  Op maat maken voor de projectomgeving. Deze principes worden uitgewerkt in zeven thema's en zeven processen. Thema's De PRINCE2-thema's beschrijven aspecten van projectmanagement waaraan voortdurend aandacht moet worden besteed:  Businesscase: het project begint met een idee waarvan wordt gedacht dat het potentiële waarde heeft voor de betreffende organisatie. Dit thema gaat over hoe het idee wordt ontwikkeld tot een levensvatbaar investeringsvoorstel voor de organisatie en hoe het projectmanagement gedurende het hele project gericht blijft op de doelstellingen van de organisatie.  Organisatie: de organisatie die het project sponsort moet het werk toewijzen aan managers die ervoor verantwoordelijk zullen zijn en het richting afronding kunnen sturen. Projecten zijn multidisciplinair. Daarom zijn de normale lijnfunctiestructuren niet geschikt. Dit thema beschrijft de rollen en verantwoordelijkheden in het tijdelijke PRINCE2-projectmanagementteam die vereist zijn om het project effectief te managen.  Kwaliteit: het initiële idee kan alleen worden gezien als een schets op hoofdlijnen. Dit thema verklaart hoe de hoofdlijnen verder worden ontwikkeld, zodat alle deelnemers zicht krijgen op de kwaliteitskenmerken van de op te leveren producten, en vervolgens hoe het projectmanagement waarborgt dat aan deze eisen wordt voldaan.  Plannen: PRINCE2-projecten gaan te werk op basis van een reeks goedgekeurde plannen. Dit thema vult het thema 'kwaliteit' aan door de stappen te beschrijven die vereist zijn voor het ontwikkelen van de plannen. Bovendien worden de toe te passen PRINCE2technieken beschreven. Bij PRINCE2 worden de plannen in overeenstemming gebracht met de behoeften van de medewerkers op diverse niveaus in de organisatie. Zij zijn gedurende het gehele project het brandpunt voor de communicatie en beheersing.  Risico: projecten lopen gewoonlijk meer risico dan stabiele operationele activiteiten. Dit thema gaat over hoe projectmanagement de onzekerheden in de eigen plannen en in de bredere projectomgeving managed.  Wijziging: dit thema beschrijft hoe het projectmanagement issues met een potentiële impact op de baseline-aspecten van het project (de plannen of afgeronde producten) beoordeelt en daarop actie onderneemt. Bij issues kan het gaan om onverwachte algemene problemen, wijzigingsverzoeken of kwaliteitsgebreken.  Voortgang: dit thema gaat over de voortdurende levensvatbaarheid van de plannen. Het thema legt het besluitvormingsproces voor de goedkeuring van plannen uit, het monitoren van de werkelijke prestaties en het escalatieproces als de zaken niet volgens plan gaan. Uiteindelijk bepaalt dit thema of en hoe het project verder moet gaan. De kracht van PRINCE2 is gelegen in de manier waarop de zeven thema's worden geïntegreerd.

27

Processen De PRINCE2 kent zeven processen. Deze processen bevatten een verzameling van activiteiten die noodzakelijk zijn voor het succesvol sturen, managen en opleveren van een project. Er worden drie niveaus onderscheiden: sturen (stuurgroep), managen (projectmanager) en opleveren (teammanager).

Figuur 8: De PRINCE2-processen

Het gaat om de volgende processen: 













Opstarten van een project (SU): zorgen dat voldaan is aan de randvoorwaarden voor het initiëren van een project door de vraag te beantwoorden of het project levensvatbaar en lonend is, Sturen van een project (DP): de Project Board in staat stellen eindverantwoordelijk te zijn voor het slagen van het project door het nemen van belangrijke beslissingen en het uitoefenen van beheersing over het geheel, terwijl hij het dagelijks management delegeert aan de projectmanager. Initiëren van een project (IP): het leggen van een stevige basis voor het project, waardoor de organisatie duidelijkheid krijgt over het werk dat moet worden gedaan om de producten van het project op te leveren voordat aanzienlijke uitgaven worden gedaan, Beheersen van een fase (CS): het toewijzen van het werk dat gedaan moet worden, datzelfde werk bewaken, issues behandelen, voortgang rapporteren aan de Project Board en corrigerende maatregelen nemen om te zorgen dat de fase binnen de tolerantie blijft. Managen productoplevering (MP): het beheersen van de schakel tussen de projectmanager en de teammanager(s) door formele eisen te stellen aan het aannemen, uitvoeren en opleveren van projectwerk. Managen faseovergangen (SB): te zorgen dat de Project Board door de projectmanager wordt voorzien van voldoende informatie om het succes van de huidige fase te kunnen reviewen, het volgende faseplan te kunnen goedkeuren, het geactualiseerde projectplan te kunnen reviewen en de voortdurende zakelijke rechtvaardiging en aanvaardbaarheid van risico's te kunnen bevestigen. Afsluiten van een project (CP): zorgen voor een vast punt waarop de acceptatie van het projectproduct wordt bevestigd en wordt vastgesteld dat de doelstellingen die waren vastgelegd in de oorspronkelijke projectinitiatiedocumentatie zijn gerealiseerd (of dat goedgekeurde wijzigingen in de doelstellingen zijn gerealiseerd).

28

3.2.2

Managing Succesful Programmes (MSP)

Een programma wordt opgezet om baten te realiseren. Daarvoor is het nodig dat een werkend resultaat wordt gemaakt, dat in de echte wereld zodanig werkt, dat de gewenste baten inderdaad gerealiseerd worden. Hier is meer voor nodig dan alleen een fasering. Vooral ook het management van allerlei aspectgebieden is van belang, want juist die zijn bepalend voor het echte succes. De aanpak van MSP (Managing Successful Programmes) komt hieraan volledig tegemoet (Harpham, 2002). Naast een projectfasering waarin activiteiten worden geadresseerd, worden ook een negental aspectgebieden (governance themes) onderkend, die gedurende het gehele programma gemanaged moeten worden om daadwerkelijk de baten te realiseren. MSP komt uit dezelfde stal als Prince 2 (de OGC in Groot Brittannië). Hoewel methoden voor programmamanagement nog steeds niet gemeengoed zijn op de Nederlandse markt, is Managing Successful Programmes (MSP) inmiddels een begrip geworden als aanpak voor programmamanagement. De aanpak is afkomstig van de Britse Office of Government Commerce (OGC). Het is beschreven in een oorspronkelijke publicatie uit 1999, aangepast eerst in 2004 en opnieuw in 2007: ‘Managing Successful Programmes’. Het is geen open methode, in de zin dat op de publicatie zelf copyright berust, maar het is wel publiek domein in de zin dat organisaties de methode vrij mogen gebruiken (Winter, M., Smith, C., Morris, P., & Cicmil, S., 2006). Kern van de theorie De methode heeft een zevental principes:  Afgestemd blijven op de bedrijfsstrategie  Leiderschap bij de verandering  Het visualiseren en communiceren van de betere toekomst  Focussen op de baten (‘benefit’) en op de bedreigingen voor die baten  Waarde toevoeging  Ontwerpen, ontwikkelen en opleveren van een coherente vaardigheid ‘capability’  Leren van de ervaringen. Managing Successful Programmes is daardoor een programmamanagement aanpak, waarmee organisaties op een effectieve wijze een beoogde verandering kunnen doorvoeren (Ward, J., & Daniel, E., 2006).

29

Opbouw van de theorie Managing Successful Programmes biedt een set van processen en 'governance themes'.

MSP processen De aanleiding voor het eerste MSP proces Identifying a Programme is een programmamandaat (Programme Mandate), waarin op hoofdlijnen de strategische doelstellingen van het programma beschreven zijn. Vanuit dit mandaat worden de doelstellingen in meer detail ontwikkeld en beschreven in een programmabrief (Programme Brief). Op grond van deze brief wordt formeel bepaald of deze doelstellingen het waard zijn om verder ontwikkeld te worden en of het programma voorbereid dient te worden. Dit proces behoort in een korte periode afgerond te zijn, binnen enkele weken. Deze formele goedkeuring wordt gegeven door de eigenaren van het programma: de sponsorgroep en de Senior Responsible Owner (SRO). De programme brief is (na goedkeuring) de belangrijkste input voor het Defining a Programme proces. In dit proces wordt het programma voorbereid; de brief vormt de basis voor ontwikkeling van de programmadefinitie (Programme Definition): de plannen, de aanpak en de principes voor de programmabesturing. De volgende documenten worden gerealiseerd tijdens dit proces: het visiedocument (Vision Statement), de blauwdruk (Blueprint), het programmaplan (Programme Plan) en de Business Case. Deze documenten vereisen goedkeuring door de sponsorgroep en de SRO, vóórdat het programma formeel van start gaat. De besturingsprincipes van het programma worden bevestigd en de besturing wordt uitgevoerd binnen het proces Managing the Tranches. De programmadefinitie is de basis voor de processen Delivering the Capability en Realising the Benefits. De projecten en de activiteiten worden gegroepeerd in tranches. Elke tranche levert een stapsgewijze verandering in de vaardigheden (Capabilities) van de organisatie. Aan het eind van elke tranche is er een belangrijk evaluatiepunt waarop wordt bepaald of het programma die vooruitgang boekt en die resultaten (Outcomes) bereikt, die verwacht en gewenst is, en of de verwachte baten nog wel gehaald kunnen

30

worden. De activiteiten van Delivering the Capability en Realising the Benefits worden herhaald voor elke tranche. Het proces Closing a Programme wordt uitgevoerd als het programma eindigt, als de vaardigheden uit de blauwdruk gerealiseerd zijn, en de resultaten uit het visiedocument en de business case behaald zijn. Verdere evaluaties kunnen nodig zijn na de programma-afsluiting om de realisatie van de baten te bepalen en te meten. MSP Governance Themes De MSP Governance Themes, zoals Organisation, ondersteunen de MSP processen:



Organisation: Er wordt door MSP een duidelijke organisatiestructuur en een duidelijke set van rollen en verantwoordelijkheden voorgeschreven. Hierdoor wordt een duidelijke en effectieve besluitvorming mogelijk gemaakt. Het geeft de individuen binnen het programma helderheid over de mate van autonomie voor hun eigen acteren. Er is een sponsorgroep van senior management en er is een SRO met de uiteindelijke verantwoordelijkheid.



Vision: MSP hecht veel waarde aan een sterke visie op de betere toekomst. Het is een uitgelezen middel voor het meekrijgen van betrokkenen en voor de motivatie deel te nemen aan het programma. De visie behoort een makkelijk communiceerbaar en verifieerbaar beeld van de toekomstige situatie te zijn.



Leadership and Stakeholder Management: Stakeholder Management is ervoor om te zorgen dat alle belanghebbenden geïdentificeerd worden, hun belangen in het programma begrepen worden en daarnaar geacteerd wordt. Leadership is gekoppeld aan Stakeholder Management, omdat MSP er van uit gaat dat een verandering gestuurd met worden/er moet richting gegeven worden, en het volstaat niet de verandering alleen te regelen/managen.

31



Benefits Realisation Management: In MSP is Benefits Realisation Management een kernactiviteit. Het gaat daarbij om het inventariseren, optimaliseren, plannen, monitoren van en aansturen op de verwachte baten van het programma.



Blueprint Design and Delivery: Waar een visie een gemakkelijk te communiceren beeld van de toekomstige situatie is, is de blauwdruk een nauwkeurige beschrijving van die toekomstige situatie in termen van business modellen, organisatiestructuren, processen, informatiestromen en technologie (ofwel vaardigheden). De blauwdruk wordt aan het begin van het programma ontworpen en gedurende het programma onderhouden.



Planning and Control: Bij Programme Planning and Control is er allereerst het programmaplan als basis voor de besturing van het programma. Aspecten die bij het besturen van het programma van belang zijn, zijn de projectportfolio, de inzet van de schaarse middelen en de identificatie van de tranches.



Business Case: Business Case Management betreft het definiëren en het beheren van de Business Case als de verantwoording van het programma. De Business Case is de optimale mix van de baten, de risico’s bij het realiseren van die baten, de benodigde kosten en het tijdschema. De Business Case moet antwoord hebben op de vraag: is het programma (nog) betaalbaar, (nog) uitvoerbaar, (nog) conform de gewenste prijs-kwaliteitverhouding en is over alle opties nagedacht.



Risk Management and Issue Resolution: Bij Risk Management and Issue Resolution gaat het erom een strategie te hebben om huidige en mogelijke problemen te beheersen, zowel op programma als op projectniveau en daarnaar te acteren.



Quality Management: Tijdens het volledige programma moet men ervoor zorgen dat de eindproducten van het programma geschikt zijn voor de programmadoelstellingen. Kwaliteitsbewaking omvat vele aspecten: configuratiebeheer, Change Control, Quality Assurance, reviews van en audits op producten, bewaking van de programmaprocessen en programmaprocedures.

3.2.3

Gateway review

Geschiedenis Eind jaren negentig van de vorige eeuw vroeg de Engelse regering aan Peter Gershon, directeur van GEC Marconi, om onderzoek te doen naar aanbestedingen van de Engelse Rijksoverheid. Eén van de uitkomsten van het onderzoek was dat het ontbrak aan een goed proces voor het managen van aanbestedingen die groot, complex en niet standaard zijn. Vanuit deze bevinding heeft het Office of Government Commerce (OGC) de Gateway Review-methode ontwikkeld in 2004. In 2006 heeft de Gateway Review-methode haar intrede in Nederland gedaan. In eerste instantie betrof het een pilot waarbij drie projecten van de Rijksoverheid aan een Gateway Review onderworpen werden. Daartoe aangezet door IT projecten die geheel of gedeeltelijk faalden, zoals het geval was bij de projecten Toeslagen, Samenwerking UWV/Belastingdienst en Wet administratieve lastenverlichting en vereenvoudiging in sociale verzekeringswetten1, heeft ook de minister van Binnenlandse Zaken (BZK) een prominente rol toegekend aan de Gateway Review-methode. Dit is door het ministerie van BZK vormgegeven met de oprichting van Bureau Gateway, onder wiens verantwoordelijkheid de Gateway Reviews worden uitgevoerd.

32

De Gateway Reviewmethode Op basis van het in Engeland uitgevoerde onderzoek naar aanbestedingen kwam OGC tot 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 zoals business case, aanbestedingsplan, project management plan, risk management plan  De opgeleverde producten dienen te worden beoordeeld door deskundige personen die onafhankelijk zijn van het project  Belangrijke Gates kunnen alleen gepasseerd worden als het oordeel van de deskundige personen positief is. In hoofdlijnen zijn er zes verschillende Gateway Reviews te onderscheiden, te weten:  strategische beoordeling (Gateway 0);  zakelijke rechtvaardiging (Gateway 1);  verwerving- c.q. veranderstrategie (Gateway 2);  investeringsbeslissing (Gateway 3);  gereedheid voor dienstverlening (Gateway 4);  evaluatie van de behaalde resultaten (Gateway 5). Werkwijze Een reviewteam voert een Gateway Review uit in opdracht van de Senior Responsible Owner (SRO), oftewel de opdrachtgever. Deze SRO bepaalt de vraag die hij met de Gateway Review-methode bij een bepaalde Gate beantwoord wil hebben. De uitvoering van de Gateway Review-methode vindt plaats door drie à vier deskundigen. Deze deskundigen zijn collega-bestuurders, managers en andere deskundigen die meestal binnen de overheid werkzaam zijn. Na een voorbereiding, die soms enkele weken in beslag kan nemen, is de doorlooptijd van de feitelijke uitvoering van een Gateway Review vier à vijf dagen. Drie dagen besteedt het reviewteam aan het houden van interviews en het doornemen van documentatie. In dag vier en vijf van de review schrijft het reviewteam het rapport, dat vervolgens aan de SRO wordt gepresenteerd. De doorlooptijd is een boeiend element binnen de Gateway Reviewmethode. In de doorlooptijd wordt geen onderscheid gemaakt tussen grote complexe programma’s en kleine relatief eenvoudige programma’s. Grotere programma’s en projecten kennen, ten opzichte van kleinere programma’s en projecten, meestal een andere organisatorische structuur (hierbij kan onder meer gedacht worden aan het al dan niet aanwezig zijn van diverse overlegstructuren zoals opdrachtgever-overleggen, stuurgroepen, bestuurlijke regiegroepen en ambtelijke regiegroepen). Dit biedt het reviewteam bij een Gateway Review de mogelijkheid om bij grote programma’s gebruik te maken van overleg- en beslisstructuren die niet voorhanden zijn bij kleinere programma’s en projecten. Tevens geldt in algemene zin dat grote complexe programma’s meer mogelijkheden hebben om een goed intern beheersingssysteem in te richten, waarop het reviewteam kan steunen bij de uitvoering van een Gateway Review. Status en advies In het reviewrapport geeft het reviewteam het project een status. Met deze status brengt het reviewteam tot uitdrukking of een project gereed is om verder te gaan naar de volgende projectfase. Er is bij de Gateway Review-methode gekozen om de status aan te geven door middel van kleursymbolen. Status ‘groen’ houdt in dat het reviewteam de verwachting heeft dat het project gereed is om naar de volgende projectfase te gaan en dat het project naar verwachting succesvol kan worden

33

afgerond. ‘Rood’ is de meest negatieve status die een project kan krijgen. Bij rood is het succesvol afronden van het project volgens het reviewteam uitgesloten. De SRO dient bij status rood in te grijpen om de noodzakelijke veranderingen aan te brengen om het project weer uitzicht te bieden op succesvolle voltooiing. Van status groen oplopend naar status rood is er een aantal statussen (oranje/groen, oranje en oranje/rood), dat het reviewteam kan toekennen, waarmee het reviewteam aangeeft in hoeverre een bemoeienis van de SRO noodzakelijk is om het project door te kunnen laten gaan naar de volgende projectfase en om succesvolle afronding van het project binnen bereik te houden. Naast de status vormen adviezen een belangrijk onderdeel van een review-rapport. Er zijn drie soorten adviezen te onderscheiden, te weten: kritiek, essentieel en tip. Deze kwalificaties sluiten aan bij de status rood (kritiek), oranje (essentieel) en groen (tip) waarmee een reviewteam aangeeft of een project geschikt is om naar de volgende projectfase te gaan. Adviezen die als kritiek benoemd zijn, resulteren in een status rood en zullen eerst opgevolgd moeten worden voordat het project gereed is om naar de volgende projectfase te gaan. Pijlers van de Gateway Review-methode Een aantal pijlers, belangrijke resultaatbepalende onderdelen van de Gateway Review-methode, zorgt ervoor dat de Gateway Reviewmethode voor de SRO toegevoegde waarde heeft. Belangrijke te onderkennen pijlers zijn: vertrouwelijkheid, onafhankelijkheid en de kwaliteit van het reviewteam. Vertrouwelijkheid Om bij Gateway Reviews open gesprekken te krijgen, waarbij reviewers enerzijds en SRO en andere geïnterviewden anderzijds vrijuit met elkaar kunnen spreken, is vertrouwelijkheid noodzakelijk. Ook is vertrouwelijkheid voor de SRO van belang om te voorkomen dat het Gateway Review-rapport gaat fungeren als een verantwoordingsstuk. Om deze vertrouwelijkheid te waarborgen, geldt het uitgangspunt dat de Gateway Review-rapportages niet openbaar gemaakt worden. Met betrekking tot de confidentialiteit van Gateway Review-rapportage doet Bureau Gateway een beroep op artikel 11 van de Wet openbaarheid van bestuur. Artikel 11, lid 1 biedt de mogelijkheid om openbaarmaking van opgestelde documenten met persoonlijke beleidsopvattingen ten behoeve van intern beraad te voorkomen. Een tweede maatregel om de vertrouwelijkheid te garanderen, vormt de wijze van vastlegging van interviews. De Gateway Review-methode werkt met aantekeningen die niet te herleiden zijn naar individuele personen (in plaats van een gespreksverslag). In het verlengde hiervan geldt ook dat de inhoud van de Gateway Review-rapportage niet te herleiden mag zijn naar individuen. En ten slotte is er in het kader van de vertrouwelijkheid de maatregel dat de reviewteamleider na afloop van de review het reviewdossier vernietigt. Onafhankelijkheid Voor elke Gateway Review maakt OGC een risico-inschatting van een IT-project. Afhankelijk van deze risico-inschatting stelt OGC het reviewteam samen. Hierbij is het mogelijk, daar waar het risico van een IT-project niet als hoog wordt ingeschat, dat medewerkers van het departement onder wiens verantwoordelijkheid het project wordt uitgevoerd, deelnemen in het Gateway Reviewteam. Van deze voor een Nederlandse IT-auditor ongebruikelijke invulling van onafhankelijkheid, is in Nederland al snel afgestapt. Thans zijn Gateway reviewers deskundigen binnen de overheid, die op een gelijkwaardige positie functioneren als de SRO. Daarnaast zijn er ook enkele personen met een wetenschappelijke achtergrond benaderd om als reviewer op te treden. Een heikel punt blijft het al dan niet benaderen van medewerkers van IT-marktpartijen om op te treden als reviewer. Allereerst zijn grote marktpartijen meestal op de een of andere manier betrokken bij de grote IT-projecten van de overheid. Ook 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. Een mogelijke oplossing voor tegenstrijdige belangen kan zijn om tenderpartijen uit te sluiten van deelname aan de review.

34

Op een hoger niveau is er een ander onafhankelijkheidsvraagstuk. Bureau Gateway is door BZK opgericht en als zodanig ondergebracht in een werkmaatschappij van BZK. De ICT Uitvoeringsorganisatie (ICTU), die opgericht is door BZK en VNG, is de hoofduitvoerder van vele programma’s en projecten. BZK treedt zelf bij vele programma’s als opdrachtgever op. Binnen de driehoek van Bureau Gateway (reviewer), ICTU (uitvoerder) en BZK (opdrachtgever) kan, gezien de gelieerdheid, snel de schijn van mogelijke belangenverstrengeling ontstaan. Uit interviews met betrokkenen, bij genoemde partijen, komt naar voren dat de gelieerdheid geen rol van betekenis speelt. Kwaliteit De kwaliteit van het reviewteam is een belangrijke pijler voor de Gateway Review-methode. Het review team speelt een centrale rol bij de Gateway Review-methode. Doordat de Gateway Reviewmethode niet werkt met expliciete kwaliteitseisen en de daaruit voortvloeiende normen, maar gebruik maakt van Best Practice-handboeken wordt een groot beroep gedaan op de ervaring en expertise van het reviewteam. Het feit dat de reviewteamleider het reviewdossier aan het eind van de review vernietigt, brengt met zich mee dat de kwaliteit van het reviewteam na afloop van een review op basis van een evaluatie van het reviewdossier niet mogelijk is. Dit vormt een ontbrekende schakel in het kwaliteitsborgingssysteem. Hierbij kiest de Gateway Review-methodiek bewust voor vertrouwelijkheid boven kwaliteitsborging. Thans bestaat het kwaliteitsborgingsysteem uit een aantal elementen. Allereerst kan iemand slechts Gateway- reviewer worden indien hij voldoet aan de door Bureau Gateway gestelde (kwaliteits)eisen (zoals ervaring, deskundigheid en een inschaling bij de overheid boven salarisschaal 14). Ook vindt er een evaluatie plaats tussen het reviewteam en Bureau Gateway, enige weken nadat de review is afgerond. Ondanks het kwaliteitsborgingsysteem bevestigen geïnterviewden dat er in het verleden enkele aanwijsbaar foute adviezen zijn gegeven in de Gateway Reviewrapportages. Voor- en nadelen van de Gateway Review-methode Voordelen van de Gateway Reviewmethode zijn:  De Gateway Review-methode is eenvoudig en doelgericht;  De zekerheid die de methode de SRO biedt dat het project door kan naar de volgende projectfase en dat de kans toeneemt dat de projectorganisatie de doelen haalt met betrekking tot de tijdsplanning en begrote kosten;  De SRO is beter op de hoogte van de toestand van een project en in welke fase een project zich bevindt. Of andere belanghebbenden ook inzicht krijgen in de status van het project is afhankelijk van de openbaarheid van het rapport;  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. Ook brengt de methode partijen dichter bij elkaar en zorgt het voor het kweken van gezamenlijk begrip;  De medewerkers van het projectteam hoeven niet terughoudend te zijn, de SRO en andere betrokkenen gebruiken de reviewrapportage 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 rapportage krijgt meer draagvlak bij de SRO, door een reviewteam zo samen te stellen dat één of meerdere teamleden voor wat betreft achtergrond en professionele ervaring gelijkwaardig zijn aan de SRO;  De deelnemers in het reviewteam doen kennis en ervaring op die ze elders binnen de overheid bij andere projecten in de rol als medewerker van een projectorganisatie, SRO of reviewer kunnen gebruiken. Naast een groot aantal voordelen kent de Gateway Review-methode ook enkele nadelen:

35

  

Tussen twee Gateway Reviews kunnen soms maanden voorbij gaan, dit houdt in dat bijsturing soms (te) lang op zich laat wachten; 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 Gateway Review-methode gaat voorbij aan het (beoordelen van het) voldoen aan wet- en regelgeving en aan de kwaliteitsaspecten beschikbaarheid, integriteit van gegevens en vertrouwelijkheid.

Een praktisch probleem bij de toepassing van de Gateway Review-methode vormt het moment waarop de Gateway Review ingezet moet worden. In theorie is het punt wanneer de SRO de Gateway Review-methode inzet duidelijk. De werkelijkheid is weerbarstiger, een SRO dient een Gateway Review ver voor de afronding van een projectfase al te plannen. Zo kunnen alle reviewers hun agenda voor één week vrij maken en dit is moeilijk ad hoc te realiseren. Ook kan het in werkelijkheid moeilijk zijn om duidelijke projectfases te onderkennen binnen een project (Kwak H. 2011). Vanuit het artikel “Manieren om zekerheden te verschaffen bij overheids-ICT-projecten” in het vakblad I Bestuur worden door René Matthijsse (2012) een aantal conclusies getrokken met betrekking tot Gateway reviews:  De Gateway review bevindt zich op een ander vlak dan IT auditing en bewandelt een ander pad. Zij verschaft slechts zekerheid aan de opdrachtgever over de mate waarin een programma of project gereed is om naar de volgende fase te gaan. Deze zekerheid kwalificeert zich echter niet als zekerheid zoals deze bedoeld wordt vanuit IT auditing;  Opvallend is het feit dat veel programma’s en projecten van start gaan bij de overheid zonder dat er een goede businesscase aanwezig is. Hierdoor is er dus ook geen basis voor een zorgvuldige oordeelsvorming;  De reviews kunnen natuurlijk niet in de plaats treden van een deugdelijk ‘governance framework’.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.

36

4 Financiële sturing van ICT projecten De wijze van financiële sturing van ICT projecten is complex omdat er twee soorten sturing zijn die elkaar kunnen beïnvloeden. De eerste soort betreft het reguliere begrotingsproces. Hieronder wordt verstaan dat kosten inzichtelijk worden gemaakt voor de looptijd van het gehele project. Deze kosten moeten worden goedgekeurd door het management. De tweede soort sturing betreft een project of programma waarbij de financiële aspecten nog onzeker zijn in de beginfase van het project of programma. De helderheid in de eerste soort en de onzekerheden in het tweede soort, moeten zo goed mogelijk met elkaar worden samengevoegd. Hierbij dient opgemerkt te worden dat het doel van de sturing anders kan zijn voor verschillende types projecten of programma’s. Het eerste soort begrotingsproces betreft vaak alleen de uitgaven op kasbasis voor de korte termijn terwijl de ramingen voor een project of programma een veel langere termijn zullen betreffen. Een goed ingericht portfoliomanagement is nodig om binnen een organisatie het overzicht te blijven bewaken over alle lopende projecten en programma’s in relatie tot het begrotingsproces. Wanneer er een sprake is van een goed uitgevoerd portfoliomanagement is professionele sturing en opdrachtgeverschap ook eenvoudiger. Vaak wordt gestuurd op grond van de beleving dat wanneer er een portfolio wordt opgesteld het project al volledig duidelijk is. Het besluit wordt vóór de start van het project genomen en de business case wordt daarna niet periodiek geëvalueerd en geactualiseerd. Dat gebeurt wel vaak voor de kosten, omdat deze jaarlijks in een begroting moeten worden vastgesteld, maar niet voor de beoogde baten indien deze aanwezig zijn. Laat staan dat strak wordt gestuurd op realisatie van die baten. Normaliter vindt er alleen sturing plaats op de begrote kosten en op de ingecalculeerde tijd. Er dient opgemerkt te worden dat wanneer de planning niet wordt behaald dit ook vaak een kostenoverschrijding met zich mee brengt. De benodigde mensen moeten namelijk meer tijd besteden om het project of programma te kunnen voltooien. De sturing op het identificeren van de verbetermaatregelen en beheersmaatregelen beperkt zich meestal tot die op het projectalternatief versus de nuloptie. Vaak zijn er echter meer alternatieve mogelijkheden voor handen dan alleen het projectalternatief en zijn ook niet alle pro’s en contra’s van de verschillende mogelijkheden op voorhand duidelijk. Zelfs kunnen gedurende de uitvoering van het project nieuwe mogelijkheden ontstaan. Op basis van deze gronden zou sturing van een project of programma meer een proces van voortschrijdend inzicht en bijsturing moeten zijn dan in het begin een begroting opstellen en vervolgens aan het einde van project kijken of deze ook daadwerkelijk is gerealiseerd. Wat betreft de wijze van sturing in de publieke sector gaat het openbaar bestuur uit van een rationeel proces waarbij kosten en baten goed moeten worden afgewogen, waarbij daarnaast ook politieke doelstellingen duidelijk in beeld komen en de realisatie van baten een valide onderdeel van besluitvorming is.

4.1

Gemiddelde boekhoudkundige rentabiliteit

Bij de gemiddelde boekhoudkundige rentabiliteit (average accounting rate of return) wordt de gemiddelde winst na aftrek van belasting afgezet tegen het gemiddeld geïnvesteerd vermogen. Het project komt in aanmerking voor uitvoering wanneer de gemiddelde boekhoudkundige rentabiliteit hoger is dan de geëiste rentabiliteit. Er kleven enkele nadelen aan de gemiddelde boekhoudkundige rentabiliteit. In eerste instantie wordt bij de gemiddelde boekhoudkundige rentabiliteit uitgegaan van de winst na belastingen en niet van kasstromen. Ook wordt met de tijdwaarde van het geld geen rekening gehouden. Dit houdt in dat een

37

euro nú meer waard is dan een euro over een jaar, omdat deze euro in de tussentijd meer waard kan worden door deze te investeren of uit te lenen tegen rente Er wordt van uit gegaan dat de gemiddelde boekhoudkundige rentabiliteit als selectiemethode bij investeringen ondergeschikt is ten opzichte van andere selectiemethoden. Echter is de gemiddelde boekhoudkundige rentabiliteit vrij populair. Wel dient opgemerkt te worden dat de populariteit terugloopt. Ten eerste is de berekening relatief eenvoudig en ten tweede wordt min of meer de suggestie gewekt dat de gemiddelde boekhoudkundige rentabiliteit het rendement op het project weergeeft. Ook wordt de beoordeling van bedrijfsonderdelen en managers vaak gebaseerd op de gemiddelde boekhoudkundige rentabiliteit. De gemiddelde boekhoudkundige rentabiliteit wordt daarom ook vaak meegenomen bij investeringsbeslissingen.

4.2

Terugverdienperiode

Een van de eenvoudigste beoordelingstechnieken is de terugverdienperiode (pay back period). Hieronder wordt verstaan de tijd die nodig is om de initiële gemaakte kosten voor de investering te dekken (terug te verdienen) met de kasstromen die het project genereert. Als de terugverdienperiode als beoordelingscriterium wordt gebruikt, wordt de gevonden terugverdienperiode afgezet tegen de door de leiding van de organisatie verlangde terugverdienperiode. Bij een terugverdienperiode welke lager is dan de verlangde terugverdienperiode zal het project worden geaccepteerd. Als de leiding van een organisatie een keuze moet maken tussen twee elkaar uitsluitende projecten, zal het project met de kortste terugverdienperiode worden gekozen. De terugverdientijd wordt vaak gehanteerd als een indicator van risico: hoe langer de terugverdientijd, hoe meer risico. Kasstromen zijn immers vaak moeilijk te voorspellen, en hoe verder weg in de toekomst de voorspelde kasstroom, des te onzekerder die voorspelling is. Een korte terugverdientijd geeft dan iets meer zekerheid dat de investering zich ook daadwerkelijk terugverdient. Een groot voordeel van de terugverdienperiode is haar eenvoud. De terugverdienperiode is gemakkelijk te berekenen en eenvoudig te begrijpen. Er wordt een ruwe indicatie gegeven welke projecten wel en welke projecten niet voor uitvoering in aanmerking komen. Ook benadrukt deze methode het belang van liquiditeit. Aan de methode van de terugverdienperiode kleven echter wel enkele nadelen. Een van de grootste nadelen is dat bij deze methode geen rekening wordt gehouden met de kasstromen die na het verstrijken van de terugverdienperiode worden ontvangen. Dit probleem zal aan de hand van een voorbeeld worden toegelicht. Stel dat er twee investeringsprojecten A en B bestaan met de volgende kasstromen: Jaar 0 1 2 3 4 5

Kasstroom A -100.000 34.000 34.000 34.000 34.000 75.000

Kasstroom B -100.000 30.000 30.000 30.000 100.000 100.000

Bij een verlangde terugverdienperiode van drie jaar zal de leiding van een organisatie op grond van bovenstaande informatie voor project A kiezen en wordt project B verworpen. Hierbij wordt echter wel voorbij gegaan aan het feit dat project B in het vierde en vijfde jaar nog zeer grote kasstromen binnenbrengt, dit in tegenstelling tot project A.

38

Een ander bezwaar tegen de terugverdienperiode is dat binnen deze periode geen rekening wordt gehouden met de tijdwaarde van het geld. De twee hierna te bespreken methoden die zijn gebaseerd op disconteringstechnieken hebben de genoemde nadelen niet.

4.3

Netto contante waarde

Bij deze beoordelingstechniek wordt eerst de contante waarde van de toekomstige kasstromen van een investeringsproject berekend, waarvan vervolgens de initiële investering (Io) wordt afgetrokken. De netto contante waarde (net present value) kan ook in een wiskundige vergelijking worden weergegeven. Deze vergelijking ziet er als volgt uit:

waarbij: NCW = netto contante waarde; CW = contante waarde van de toekomstige vrije kasstromen; Ct = kasstroom in periode t; k = disconteringsvoet per periode; = initiële investering; Io n = looptijd van het project. De initiële investering van Project A in het bovenstaande voorbeeld bedroeg € 100.000, de kasstromen voor de eerste vier jaren € 34.000 en de kasstroom van het laatste jaar € 75.000. Stel voorts een disconteringsvoet van 6%. De netto contante waarde van dit project is dan als volgt te berekenen. Jaar 0 1 2 3 4 5

Kasstroom A -100.000 34.000 34.000 34.000 34.000 75.000

x 1/(1+k)t 1,000 0,943 0,890 0.840 0,792 0,747

Contact waarde op t = 0 -100.000 32.062 30.260 28.560 26.928 56.025

Dit leidt tot een netto contante waarde van € 73.835 Als de netto contante waarde-methode als beoordelingscriterium wordt gebruikt, zal een investeringsproject worden geaccepteerd als de netto contante waarde groter is dan nul. Is daarentegen de netto contante waarde kleiner dan nul, dan zal het project niet worden geaccepteerd. Als een selectie moet worden gemaakt uit twee elkaar uitsluitende projecten en beide projecten hebben een positieve netto contante waarde, zal het project met de hoogste netto contante waarde de voorkeur hebben. Een groot voordeel van de Netto Contante Waarde -methode is dat bij deze methode van (vrije) kasstromen gebruik wordt gemaakt. Daarnaast wordt met de tijdwaarde van het geld nadrukkelijk rekening gehouden: een kasstroom die vandaag wordt ontvangen verhoogt de Netto Contante Waarde meer dan eenzelfde kasstroom die in de toekomst wordt ontvangen. De uitkomst van de Netto Contante Waarde -methode wordt in absolute geldbedragen weergegeven in plaats van in een percentage. Een dergelijk percentage wordt wel berekend bij de hierna te bespreken interne rentabiliteitsmethode.

39

Wel zijn er bij deze methode meerdere valkuilen, die tijdens het praktijkonderzoek zijn bevestigd door meerdere personen. Rendementseis van de investeerder of van de investering Volgens de gangbare theorie van investeringsanalyse en bedrijfswaardering hangt de te hanteren rendementseis niet samen met de investeerder, maar met de investering. Anders gezegd: met de marktrisico’s die kleven aan de investering. In de praktijk zien we echter regelmatig dat de rendementseis, en dus de gehanteerde disconteringsvoet, zonder enige consideratie wordt afgeleid van de vermogenskosten van de investeerder. In het geval van een investeringsvoorstel wordt dan de gemiddelde vermogenskostenvoet van de organisatie als vertrekpunt genomen voor het contant maken van de verwachte toekomstige kasstromen. Dit is in strijd met het principe dat niet de investeerder, maar de investering centraal moet staan bij het vaststellen van de rendementseis. Het zou dus niet juist zijn om de vermogenskosten van de investeerder als vertrekpunt te nemen voor het bepalen van de disconteringsvoet. Hierbij zijn nog wel een tweetal kanttekeningen te plaatsen. De eerste heeft betrekking op het mogelijke effect van een investering op de bestaande activa in de portfolio. In de traditionele benadering wordt de invloed van een investering op bestaande activa of bestaande bedrijfsonderdelen buiten beschouwing gelaten. De theorie gaat impliciet uit van onafhankelijke investeringsprojecten. Binnen een organisatie staat een voorgenomen investering echter meestal niet volledig los van de bestaande portfolio. Wanneer de voorgenomen investering van invloed is op het marktrisico van een of meer bestaande activa, dan moet dit effect worden meegewogen bij de beoordeling van het nieuwe voorstel. De bestaande portfolio van een investeerder kan dus wel degelijk van invloed zijn op de rendementseis. De stelling dat de rendementseis niet afhangt van de investeerder gaat alleen op bij onafhankelijke investeringen. Bij afhankelijke investeringen kan er sprake zijn van neveneffecten. De tweede kanttekening is dat een organisatie werkt binnen een strategische context. De missie, strategie en rendementsdoelstelling bepalen voor het management in belangrijke mate het speelveld. Het management kijkt dus niet – zoals de financieringstheorie aanneemt – ‘contextvrij’ naar projectvoorstellen en mogelijke alternatieven. Nieuwe investeringen moeten passen binnen de strategie en de rendementsdoelstellingen, anders maken ze minder of geen kans. Een organisatie die haar strategie en rendementsdoelstellingen heeft gecommuniceerd naar de markt, zal niet snel een investering kunnen accepteren die daar niet bij past. Ook niet wanneer het risicoprofiel van het nieuwe project van voldoende laag niveau is om, theoretisch gezien, een significant lager rendement te rechtvaardigen. Anderzijds zal een organisatie soms genoodzaakt zijn om gegeven haar strategie en bestaande portfolio, een investering te accepteren met een duidelijk lager rendement dan de rendementsdoelstellingen. Al was het maar om te voorkomen dat anders een (nieuwe) concurrent langszij komt. Bij investeringsanalyse of bedrijfswaardering moet de netto contante waarde-methode dus verstandig worden ingezet. Een verkeerd gebruik van de methode kan relatief eenvoudig tot andere ‘contante waardes’ en dus tot andere beslissingen leiden. Differentiatie van de rendementseis en scenario-analyse Investeringsvoorstellen worden vaak voorzien van scenario-analyses. De spreiding tussen de uitkomst van de best case en de worst case wordt opgevat als een indicatie voor het risico van het project. De best case bevat dan de cashflow projectie van het project als voorzien onder de meest gunstige omstandigheden en de worst case de projectie onder de meest ongunstige omstandigheden. Voor het berekenen van de netto contante waardes van de verschillende scenario’s moet dan wel een gelijke rendementseis gehanteerd worden, omdat er anders sprake is van een ‘dubbele correctie’. Het feit dat men scenarioanalyse toepast, staat los van het differentiëren van de rendementseis op basis van het marktrisico zoals eerder genoemd. De te hanteren rendementseis is voor ieder scenario gelijk, maar moet wel gecorrigeerd worden voor de marktrisico’s die aan het project kleven. Scenarioanalyse moet eigenlijk aan de basis staan van elke investeringsanalyse waarbij de te hanteren rendementseis

40

risicoafhankelijk is. Dit betekent dat de in de analyse op te nemen cashflowprojectie een gewogen gemiddelde zou moeten zijn van alle mogelijke scenario’s van het project. De verschillen tussen de cashflowprojecties van de scenario’s worden veroorzaakt door projectgebonden factoren (projectrisico’s). De weging van elk onderkend scenario in de uiteindelijke cashflowprojectie voor het project hangt af van de waarschijnlijkheidskans. De gewogen cashflow moet worden gebruikt in de netto contante waarde-berekening. De rendementseis hangt dus niet af van de projectrisico’s, want die zijn al verwerkt in de onderliggende cashflowscenario’s. In de praktijk is te zien dat algemene marktrisico’s en specifieke projectrisico’s door elkaar heen lopen bij het bepalen van de rendementseis en de cashflowprojecties. Dat leidt tot veel varianten waarin soms totaal niet, soms half en soms dubbel gecorrigeerd wordt voor risico. Feitelijk zouden projectrisico’s tot uitdrukking gebracht moeten worden in de cashflowprojecties van de verschillende scenario’s. De gevoeligheid voor algemene (markt)risico’s moet tot uitdrukking gebracht worden in de te hanteren rendementseis. Wat als een investering meerdere en sterk verschillende kasstromen op roept De derde valkuil heeft te maken met het ‘salderen’ van kasstromen. In de netto contante waardemethode wordt de netto kasstroom in enig jaar contant gemaakt naar het heden. Maar wat nu als die netto kasstroom onderliggend bestaat uit verschillende kasstromen, ieder met een eigen risicoprofiel? De netto kasstroom wordt in de netto contante waarde-methode contant gemaakt tegen één disconteringsvoet, Feitelijk veegt de netto contante waarde-methode alle kasstromen bij elkaar alsof ze qua onzekerheid allemaal hetzelfde zijn. In de adjusted present value-methode wordt de netto kasstroom daarom uit elkaar getrokken. De onderliggende kasstromen worden ‘contant’ gemaakt tegen de voor die kasstroom passende disconteringsvoet. De contant gemaakte kasstromen worden vervolgens opgeteld. Hoewel de adjusted present value -methode een verfijning is van de traditionele netto contante waarde-methode, kunnen de uitkomsten van beide methodes sterk uiteenlopen. Dit is bijvoorbeeld het geval wanneer een deel van het project echte innovatie betreft en het andere deel feitelijk niet meer is dan een uitbreiding van bestaande activa of activiteiten. De adjusted present value -methode zal de verschillende kasstromen uitsplitsen. Of wanneer voor een innovatieproject een gegarandeerde ontwikkelingssubsidie door de overheid wordt verstrekt, zal in de adjusted present value -methode de subsidie tegen een lagere disconteringsvoet contant gemaakt worden omdat het risicoprofiel lager is. De netto contante waarde-methode veegt alle kasstromen bij elkaar en hanteert dientengevolge een gemiddeld risicoprofiel. Dat is weliswaar relatief eenvoudig en dus op het oog praktisch aantrekkelijk, maar wanneer onderliggende kasstromen inderdaad significant verschillen is het al snel rekenen met appels en peren. Zeker bij strategische projecten is voorzichtigheid geboden. Bovendien is de huidige economische realiteit dat we maar beter op voorhand rekening kunnen houden met grotere onzekerheden en daarmee gepaarde gaande verhoging van de volatiliteit van de onderliggende kasstromen. De lat ligt in de regel niet bij nul: is niets doen wel een optie Bij toepassing van de netto contante waarde-methode wordt in de praktijk vaak de stelregel gehanteerd, dat wanneer de netto contante waarde groter is dan nul, de investering financieel interessant is. Dit omdat dan het rendement op de voorgenomen investering groter is dan het vereiste rendement. Impliciet doet deze beslissingsregel voorkomen of niets doen geen invloed heeft. De verwachte kasstromen die voortvloeien uit het project worden immers vergeleken met de optie wanneer we het project niet zouden uitvoeren. Maar niets doen is vaak geen optie. De bestaande business kan dan achteruit hollen en er moet dus iets gebeuren, linksom of rechtsom. Het is dan redelijk zinloos de netto contante waarde-berekening uit te voeren met het nulpunt als referentie. Heeft de voorgenomen investering een netto contante waarde die negatief is, maar nog altijd minder negatief dan de mate waarin de bestaande business achteruit zou hollen zonder te investeren, dan kan de additionele investering nog steeds economisch interessant zijn. Bij innovatieprojecten kunnen

41

de klassieke beslissingsregels, bij toepassing van de netto contante waarde-methode, gemakkelijk naar de verkeerde conclusie loodsen. Wat dit laatste betreft, stel bijvoorbeeld dat een investering in een nieuwe technologie wordt overwogen. Bij klanten die overstappen van de oude technologie op de nieuwe technologie is de additionele opbrengst vaak beperkt. Door de beperkte meeropbrengst kan het bedrijf op basis van de netto contante waarde-uitkomsten geneigd zijn te besluiten de investering niet te doen. Nieuwe toetreders in de markt zullen echter geen last hebben van kannibalisatie en hun uitkomsten van de netto contante waarde-berekeningen zullen dus hoger zijn. Een toetreder zou dan veel sneller besluiten om te investeren in de nieuwe technologie. Met een dergelijke financiële analyse plaatst het bedrijf dat al geruime tijd in de betreffende markt opereert zichzelf op een achterstand ten opzichte van eventuele nieuwe toetreders. Het zijn vrijwel altijd nieuwe toetreders of bestaande kleinere concurrenten die een nieuwe ontwikkeling omarmen en zo aan de wieg staan van baanbrekende vernieuwingen. Harvard-professor Clayton Christensen wijt dit voor een belangrijk deel aan de in de praktijk verkeerd toegepaste netto contante waarde-methode. Flexibiliteit kost geld, maar heeft toch zeker ook waarde De vijfde valkuil waardoor de traditionele netto contante waarde-methode tot verkeerde conclusies kan leiden, is erin gelegen dat de methode geen ruimte biedt voor flexibiliteit. De impliciete aanname achter de methodiek is dat wanneer eenmaal wordt begonnen aan een project, het altijd op die manier wordt afgemaakt. Tussentijds ingrijpen door het management is derhalve, volgens de traditionele netto contante waarde-methode, uitgesloten. De werkelijkheid is in de regel anders. Soms wordt de investering versneld, vertraagd, in delen ‘geknipt’ en wordt afhankelijk van de ontwikkelingen in technologie en markt bij-geïnvesteerd. Het management heeft derhalve gaandeweg het project allerlei opties. Voor deze ‘flexibiliteit’ tijdens de uitvoering van een project is in een traditionele netto contante waardeanalyse geen of nauwelijks plek. De netto contante waardemethodiek suggereert dat er altijd wordt doorgegaan met investeren. De waardevolle opties van managers om projecten tussentijds te stoppen, te versnellen of anderzijds te veranderen worden niet meegewogen tijdens de investeringsanalyse. Dat geldt zowel bij investeringsvoorstellen als bij bedrijfswaardering. Vooral bij innovatie kan dit snel tot verkeerde keuzes leiden. Innovatie is een adaptief proces waarin soms verassende wendingen genomen moeten worden. Bij een innovatieproject of bij een organisatie met een innovatiestrategie speelt flexibiliteit dus juist een cruciale rol. Daarom is de traditionele netto contante waarde-methodiek aan de bron een mismatch met innovatie. Wanneer de onzekerheid over bijvoorbeeld ‘technologie’ of ‘markt’ groter wordt, stijgt de waarde van de in het project ingebouwde of de in de organisatie aanwezige (reële) opties. De netto contante waarde-methode beloont het hebben van deze opties evenwel niet. Sterker nog: de kosten van dergelijke opties worden wel (als cash-out), maar de waarde wordt niet meegenomen in de berekening. Het creëren van opties vergt meestal een extra investering. Omdat de netto contante waarde-methode de waarde ervan echter niet meeneemt, zou men kunnen concluderen dat deze ‘extra investering’ niet loont. Risicomanagement wordt zodoende door de traditionele netto contante waarde-methode afgestraft en daar- mee is deze analysemethode aan de basis contraproductief.

4.4

Interne rentabiliteit

De interne rentabiliteit (internal rate of return) geeft het rendement aan dat met het project wordt behaald. De interne rentabiliteit te definiëren als de disconteringsvoet waarbij de som van de contante waarde van de kasstromen van een project gelijk is aan de initiële investeringskosten van datzelfde project. In de vorm van een formule ziet de interne rentabiliteit er als volgt uit:

42

Merk op dat de netto contante waarde van een project, waarbij de kostenvoet gelijk gesteld wordt aan de interne rentabiliteit, gelijk is aan nul. De interne rentabiliteit van het hierboven beschreven Project A is te bepalen door in de volgende vergelijking de disconteringsvoet in te vullen waarbij de linkerkant en de rechterkant van het gelijkteken even groot zijn.

Voor Project A komt dit neer op een interne rentabiliteit van iets meer dan 27%. De berekende interne rentabiliteit wordt afgezet tegen de interne rentabiliteit die de leiding van een organisatie met een project wenst te behalen. Vaak zal de kostenvoet van het vermogen, die ook vaak bij de netto contante waarde als disconteringsvoet wordt gebruikt, als grens dienen. De disconteringsvoet voor het berekenen van de netto contante waarde bedroeg in het voorbeeld 6%, zodat volgens de interne rentabiliteit-methode dit project geaccepteerd zal worden. Als een keuze moet worden gemaakt tussen twee elkaar uitsluitende projecten, zal het project met de hoogste interne rentabiliteit worden gekozen. Voordelen van de interne rentabiliteit-methode zijn het gebruik van kasstromen en het feit dat deze methode rekening houdt met de tijdwaarde van geld. Een nadeel van deze methode is dat impliciet wordt verondersteld dat de vrijkomende kasstromen tegen eenzelfde rendement als de interne rentabiliteit kunnen worden belegd. Dit is vrij onrealistisch. Het project in het voorbeeld heeft een interne rentabiliteit van 27%, wat redelijk hoog is. Dit project kan dus als winstgevend worden beschouwd. Elk jaar komen uit het project kasstromen vrij, maar het is de vraag of er dan een of meer projecten voorhanden zijn waarin deze kasstromen kunnen worden geïnvesteerd die ook 27% opleveren. Een ander nadeel van deze methode is dat eenzelfde project tot verschillende interne rentabiliteiten kan leiden. Dit is het geval bij een niet-conventioneel project. Bij een dergelijk project hebben de kasstromen meer dan één verandering van teken. De initiële investering wordt gevolgd door een aantal ingaande kasstromen, welke op hun beurt worden gevolgd door een uitgaande kasstroom.

4.5

Verschillen netto contante waarde en interne rentabiliteit

De netto contante waarde methode en de methode van de interne rentabiliteit zijn gebaseerd op dezelfde gedachte. Gegeven een disconteringsvoet k worden bij de netto contante waarde methode de toekomstige vrije kasstromen contant gemaakt naar tijdstip t = 0 en vergeleken met het investeringsbedrag op dat tijdstip. Is de contante waarde van de toekomstige kasstromen groter dan het investeringsbedrag (netto contante waarde > 0), dan komt het desbetreffende project voor uitvoering in aanmerking. Bij de interne rentabiliteit daarentegen zoekt men juist die disconteringsvoet die de contant gemaakte kasstromen gelijk doet zijn aan het investeringsbedrag. In de volgende vergelijking zijn de kasstromen voor elke periode t en het investeringsbedrag gegeven. Onbekend zijn derhalve de netto contante waarde netto contante waarde en de disconteringsvoet k.

43

Bij de netto contante waarde methode wordt, gegeven een bepaalde disconteringsvoet, de netto contante waarde berekend. Bij de interne rentabiliteit wordt uitgegaan van een netto contante waarde van nul en wordt de daarbij behorende disconteringsvoet bepaald. De netto contante waarde zal afnemen naarmate de disconteringsvoet groter wordt. Immers, een hogere disconteringsvoet leidt tot een lagere contante waarde van de toekomstige kasstromen. In figuur 9 is dit grafisch weergegeven.

Figuur 9: De netto contante waarde als functie van de disconteringsvoet.

Stel dat de disconteringsvoet k gelijk is aan nul. Dit impliceert dat er geen sprake is van tijdvoorkeur, noch van een risico-opslag. De netto contante waarde wordt dan verkregen door de toekomstige kasstromen op te tellen en vervolgens van deze som het investeringsbedrag af te trekken. De netto contante waarde is € 111.000 (= 4 x 34.000 + 75.000 − 100.000). Bij een stijging van k nemen de contante waarden van de toekomstige kasstromen af, waardoor de netto contante waarde eveneens vermindert. De ondergrens van de netto contante waarde is -Io. Bij een zeer grote disconteringsvoet k zijn immers de contante waarden van de toekomstige kasstromen bijna gelijk aan nul. De grafiek van de netto contante waarde als functie van de disconteringsvoet snijdt de horizontale as. Voor de disconteringsvoet behorende bij dat snijpunt geldt dat de netto contante waarde gelijk is aan nul. Dit is precies de definitie van de interne rentabiliteit. Hoewel de netto contante waarde methode en de interne rentabiliteit op dezelfde grondgedachte zijn gebaseerd, kunnen bij de selectie van elkaar uitsluitende projecten tussen deze twee methoden verschillen ontstaan in de voorkeursordening van de desbetreffende projecten. Deze verschillen in voorkeursordening kunnen ontstaan wanneer voor de projecten in kwestie er een ongelijkheid bestaat wat betreft:  investeringsbedrag;  looptijd;  verdeling van de kasstromen.

44

4.6

Onderzoeken naar gekozen methode

Uit onderzoeken in diverse landen blijkt dat organisaties vaak meerdere methoden toepassen bij investeringsselectie. Zie voor de uitkomsten van diverse onderzoeken tabel 2.

TVP IR NCW GBR Overig

Verenigde Staten 59% 52% 28% 13% 44%

Australië

Canada

61% 37% 45% 24% 7%

50% 62% 41% 17% 8%

Ierland 84% 84% 24% -

Japan 52% 4% 6% 36% 5%

Verenigd Koninkrijk 76% 39% 38% 28% 7%

ZuidKorea 75% 75% 60% 68% -

Tabel 2: Investeringsselectiemethoden in de praktijk

Bron: C. T. Horngren, S. M. Datar en G. Foster, Cost Accounting, Eleventh Edition, 2003, p. 727. Uit tabel 2 blijkt dat organisaties in de Verenigde Staten, Australië, Canada, Ierland, Verenigd Koninkrijk en Zuid-Korea als regel twee methoden gebruiken. (De som van alle percentages is meer dan 100%.) Japanse bedrijven gebruiken meestal één methode. De TVP is een populaire methode, vooral in Japan. In de andere landen worden door organisaties veelvuldig de DCF-methoden (IR + NCW) toegepast. Herst, Poirters & Spekreijse (1998) doen verslag van een aan het eind van 1995 en in het eerste halfjaar van 1996 uitgevoerde schriftelijke enquête onder Nederlandse organisaties naar de toepassing van methoden om investeringsvoornemens te evalueren. Zij ontvingen 44 van de 210 verstuurde enquêtes ingevuld retour. Voor een onderzoek van dit type is een dergelijk respons normaal. Uit hun onderzoek blijkt dat als investeringsselectiemethode door 25% van de organisaties de netto contante waarde wordt gehanteerd, door 20% de interne rentabiliteit en door eveneens 20% de terugverdienperiode. Andere selectiecriteria worden door minder organisatie gebruikt. Echter, organisaties baseren hun investeringen doorgaans op meer dan één methode. De combinatie netto contante waarde, interne rentabiliteit en terugverdienperiode wordt door 41% van de onderzochte organisaties gehanteerd.

4.7

Mogelijkheden tijdens de uitvoering van een project

Bij een statische toepassing van de netto contante waarde methode wordt geen rekening gehouden met de eventuele mogelijkheid om tussentijds in te grijpen. Uiteraard heeft deze flexibiliteit voor de organisatie waarde. Afhankelijk van de ontwikkeling van het project zal de directie van deze mogelijkheid gebruik maken. De zogenoemde mogelijkheden kunnen zowel aanwezig zijn op het moment dat de investeringsbeslissing wordt genomen als daarna. Tot de opties die op het moment van een investeringsbeslissing aanwezig (kunnen) zijn, worden gerekend: 1. uitstel van investeringen; 2. seriegewijs investeren; 3. veranderen van de verhouding tussen de gebruikte productiefactoren. Ad 1. Uitstel van investeringen Stel dat het bestuur van een organisatie besluit om een bepaald project uit te voeren. Het bestuur kan deze beslissing echter nog een jaar uitstellen, bijvoorbeeld om gedurende dat jaar nog nader onderzoek te doen naar de toekomstmogelijkheden van het project. Het nadeel van een dergelijk uitstel is dat de voorsprong op de concurrentie kleiner wordt of zelfs geheel verloren gaat.

45

Ad 2. Seriegewijs investeren Indien een organisatie nieuwe applicaties wil introduceren, zijn de risico’s groot. Om de gevolgen van deze risico’s te beperken zal de grootte van de investering in eerste instantie klein zijn. Het is gebruikelijk dat alvorens een applicatie wordt geïntroduceerd, deze applicatie eerst op kleine schaal bij een kleinere doelgroep te introduceren. Uit reacties van deze groep wordt informatie verkregen over de kans op succes bij introductie op ruime schaal. Bovendien is het tijdens deze fase wellicht nog mogelijk om de applicatie enigszins te wijzigen. Ad 3. Veranderen van de verhouding tussen gebruikte applicaties Bij deze optiemogelijkheid moet men niet alleen denken aan de gebruikelijke applicaties, maar ook aan alternatieven. Er kan worden gekozen voor het behouden van een aantal applicaties of modules en eerst de applicaties vervangen welke het meest aan vervanging toe zijn. Er kan dan op een later moment altijd nog worden gekeken of de behouden applicaties vervangen moeten worden of geïntegreerd kunnen worden. Gedurende de looptijd van het project zijn ook andere opties mogelijk. Wij maken daarbij onderscheid in: 4. afstoten van het project; 5. onderbreken van het project; 6. aanpassen van de duur van het project; 7. aanpassen van de grootte van het project. Ad 4. Afstoten van het project Indien tijdens de looptijd van het project de kasstromen sterk tegenvallen, kan het afstoten van het desbetreffende project een reëel alternatief zijn. Onder afstoten wordt in dit geval verstaan het stop zetten van de ontwikkeling en bouw van de applicatie. Eventueel aangeschafte hardware kan worden verkocht aan derden. Op het beslissingsmoment moet het bedrag dat bij de afstoting vrijkomt, worden vergeleken met de contante waarde van de toekomstige kasstromen die bij het in bedrijf houden van de applicatie en hardware naar verwachting zullen worden verkregen. Een dergelijke beslissing kan worden genomen op basis van de netto contante waarde methode. Ad 5. Onderbreken van het project Als blijkt dat tijdens de ontwikkeling en bouw van de applicaties blijkt dat mensen en middelen niet beschikbaar zijn, kan er voor worden gekozen om het project te onderbreken. Het project ligt in lijn met de toekomstvisie van de organisatie en het management wil ook dat de applicatie er komt. Alleen moeten er eerst andere prioriteiten worden gesteld. Hierdoor wordt het project tijdelijk onderbroken, waardoor er mensen en financiële middelen vrij komen. Het project wordt in de ijskast gezet en wanneer mensen en middelen weer aanwezig zijn zal het project doorgang vinden. Een dergelijke beslissing heeft ook nadelen. Het is niet duidelijk of de tijdelijke onderbreking eventueel zal leiden tot een definitieve stopzetting van het project. Bovendien zijn bij de ontwikkeling en bouw mogelijk onderaannemers betrokken. Deze onderaannemers zien een deel van hun afzet wegvallen. Ook voor hen geldt de vraag of op termijn de ontwikkeling en bouw hervat zal worden. Het tijdelijk onderbreken van de ontwikkeling en bouw schept onrust en heeft derhalve negatieve gevolgen op de (verwachte) toekomstige kasstromen. Ad 6. Aanpassen van de duur van het project Indien de kasstromen die uit het project voortkomen sneller afnemen dan verwacht, kan het voordelig zijn om het project eerder af te stoten. Daarnaast is het mogelijk dat wanneer door strengere politieke eisen een negatieve kasstroom aan het eind van de periode nog kleiner wordt, een verlenging van de levensduur van het project waarde creërend kan zijn. Immers, de desbetreffende negatieve kasstroom aan het eind van de looptijd wordt in dat geval naar de toekomst verschoven. Aannemende dat het absolute bedrag niet verandert, impliceert dit dat de contante waarde van deze uitgestelde negatieve kasstroom groter wordt.

46

Ad 7. Aanpassen van de grootte van het project Evenals bij verandering van de looptijd kan ook het aanpassen van de grootte van het project tot waarde creatie leiden. Door te opteren voor uitstel kan de contante waarde van de negatieve kasstroom worden verhoogd.

47

5 Praktijkonderzoek In de voorgaande hoofdstukken is op basis van literatuuronderzoek inzicht gegeven in wat precies wordt verstaan onder portfoliomanagement en zijn een aantal audittools beschreven welke ondersteuning kunnen bieden bij een project. Om de theorie te valideren met de praktijk heeft er onderzoek plaatsgevonden naar een overheidsproject. Het gekozen project betreft de modernisering gemeentelijk basisadministratie (mGBA). In paragraaf 5.1 zal worden beschreven op welke wijze het onderzoek is opgezet en uitgevoerd. In de daarop volgende paragrafen worden de resultaten van het onderzoek beschreven.

5.1

Onderzoeksaanpak

Er zijn diverse onderzoeksmethoden, waaronder de survey, het experiment, de casestudy en het bureauonderzoek. Deze onderzoeksmethoden zijn allen te kwalificeren als empirisch onderzoek met uitzondering van het bureauonderzoek. Bij een empirisch onderzoek dienen de onderzoekers zelf gegevens te verzamelen. Bij de keuze van de onderzoeksstrategie dienen onderstaande drie beslissingen te worden genomen: 1. Een keuze tussen breedte en diepgang van het onderzoek. 2. Bepalen of het onderzoek kwalitatief of kwantitatief van aard is. 3. Keuze tussen een bureauonderzoek of een empirisch onderzoek. Om de theorie te confronteren met de praktijk is een case study uitgevoerd. Door middel van deze strategie wordt namelijk een breed beeld verkregen over de operatie BRP. In eerste instantie is data verzameld met betrekking tot operatie BRP. Doordat dit een groot project is wat ook veel gevolgd is door de media, is er veel data beschikbaar. Deze data bestaan onder andere uit:  Brieven aan de Tweede Kamer, opgesteld door de Minister van Binnenlandse Zaken en Koninkrijksrelaties.  Rapportages opgesteld door externe partijen met betrekking tot operatie BRP.  Gatewayreviews.  Publicaties in de media. Ten tweede is alle verzamelde data bestudeerd op relevantie en bruikbaarheid voor het uitvoeren van de case study. Er heeft een schifting plaatsgevonden om enkel de relevante data over te houden. Hiermee is dus een data-display gecreëerd. Als derde is vanuit het data-display een beschrijving gemaakt van operatie BRP waardoor de lezer van deze scriptie weet wat operatie BRP inhoudt en waardoor er bepaalde keuzes zijn gemaakt in de voortgang het project. Als vierde is er door mij een oordeel gegeven over de gemaakte keuzes. Ik heb de theorie met de praktijk geconfronteerd en heb op basis hiervan aangegeven of ik het eens ben met de gemaakte keuzes van de minister. Als laatste heb ik mijn bevindingen voorgelegd aan medewerkers van operatie BRP om deze data te valideren. Er heeft een gesprek plaatsgevonden met een tweetal medewerkers waarbij in eerste instantie de sturing van het project nader is uitgelegd en uiteindelijk er een toetsing van de bevindingen heeft plaatsgevonden.

48

5.2

5.2.1

Projectbeschrijving mGBA

Achtergrond

De casus mGBA betreft de vervanging van de huidige gemeentelijke basisadministratie persoonsgegevens (GBA) door een Basisregistratie Personen (BRP) waarin persoonsgegevens worden bijgehouden en verstrekt door gemeenten aan andere gemeenten en diverse afnemers. De GBA wordt lokaal bijgehouden door gemeenten. De modernisering van de GBA betreft een centrale database die gekoppeld en gevoed wordt vanuit de verschillende bestaande databases bij gemeenten. De modernisering moet ertoe leiden dat gebruikers altijd kunnen beschikken over actuele en betrouwbare gegevens, het beheer en onderhoud van het GBA-stelsel flexibeler en goedkoper wordt en past binnen de e-overheid. De GBA ondersteunt gemeentelijke samenwerking en plaat onafhankelijke dienstverlening. De functionaliteiten van een gemoderniseerde GBA bestaan daarmee enerzijds uit het kunnen verstrekken van persoonsgegevens aan gemeenten en andere afnemers en anderzijds uit het uniform kunnen bijhouden (beheer en opslag) van persoonsgegevens door alle gemeenten. Deze functionaliteiten worden mogelijk gemaakt door de ontwikkeling van aparte software applicaties en interfaces op centraal (Rijk) en decentraal niveau (gemeenten). Het ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK) voert samen met de Nederlandse gemeenten (via de Vereniging Nederlandse Gemeenten (VNG) en Nederlandse Vereniging voor Burgerzaken (NVVB)) de regie over het programma mGBA. De minister van BZK is verantwoordelijk voor het centrale GBA en BRP stelsel. Gemeenten zijn verantwoordelijk voor de ontwikkeling en aanpassingen van hun lokale ICT-systemen (decentrale systemen). In een apart parallel wetstraject wordt de wet GBA vervangen door de wet BRP. De wet BRP vormt de juridische vertaling van de technische modernisering van de basisregistratie en de bijbehorende doelstellingen. De casus mGBA is een bestuurlijk complex project met een grote verscheidenheid aan stakeholders en belangen. Belangrijke gebruikersgroepen zijn gemeenten, afnemers (zoals opsporings-, inspectie en veiligheidsdiensten, belastingdienst, verzekeraars, waterschappen) en de beoogde beheerder van de gemoderniseerde GBA, het Agentschap BRP (onderdeel van het ministerie van BZK). Daarnaast zijn leveranciers en het Kwaliteitsinstituut Nederlandse Gemeenten (KING) als stakeholders betrokken bij de ontwikkeling, implementatie en beheer van de mGBA. De casus mGBA betreft een lopend project. De casus is gestart in 2001 en de beoogde einddatum is juli 2016. In 2008 wordt het programma door de staatsecretaris van BZK stilgezet omdat duidelijk werd dat het additioneel toegekend budget wederom zou worden overschreden. Een heroriëntatie vond plaats, waarbij een nieuwe business case, herijking van de definitiestudie en een Gateway Review heeft plaatsgevonden om de richting en beoogde uitkomsten van het programma te onderzoeken. In 2009 werd een Bestuurlijk Akkoord gesloten tussen BZK en de VNG over de herstart voor het programma mGBA. De casus mGBA betreft een omvangrijk, bestuurlijk complex, en langdurig programma, die qua wijze van plannen (veel parallel) risicovol is, waarbij onderschatting van complexiteit en afhankelijkheden zich direct zullen vertalen in effecten op de basiselementen tijd, geld en kwaliteit.

5.2.2

Projectresultaten en maatschappelijke effecten

De mate waarin de casus mGBA wordt beschouwd als succesvol wordt bepaald aan de hand van criteria zoals de mate waarin:

49

1. 2. 3. 4. 5.

doelstellingen (inclusief maatschappelijke effecten) zijn behaald; het project binnen de planning en het budget is gerealiseerd; stakeholders tevreden zijn en de technische systemen met voldoende kwaliteit en met aandacht voor privacy en beveiliging zijn gerealiseerd.

Aangezien de casus mGBA een lopende casus betreft, is het op verschillende punten moeilijk om een oordeel te vormen over de resultaten en het succes van de casus of het ontbreken daarvan. Wel zijn diverse keren de doelstellingen van het programma geherformuleerd en bestaan verschillende herijkingen van de verwachte maatschappelijke kosten en baten. De casus mGBA wordt tevens gekenmerkt door zowel substantiële vertragingen als herhaaldelijke budgetoverschrijdingen. Waar oorspronkelijk werd uitgegaan van een afgeronde implementatie per juli 2007, wordt tot medio 2013 uitgegaan van juli 2016 en bestaan er bovendien nog altijd zorgen over verdere vertraging. Op basis van de huidige inschatting van de totaal verwachte kosten tot en met 2016, gaat het project bijna drie keer over budget: de oorspronkelijke raming ging uit van € 25,6 miljoen (exclusief programmaorganisatie). Inmiddels wordt het totale budget ingeschat op € 76 miljoen. Het project was niet onder controle, waardoor in 2008 sprake was van opschorting en noodzaak voor heroriëntatie voor de modernisering van het GBA. Sinds de herstart heeft het programma mGBA wederom te maken met berichten van vertragingen en overschrijdingen van het budget. Het technisch ontwerp van de mGBA wordt gekenmerkt door diverse fundamentele wijzigingen waarin nieuwe technische oplossingen werden voorgesteld als gevolg van voortschrijdend inzicht. Zo wordt in 2011 nieuwbouw van het BRP-systeem geadviseerd boven doorontwikkeling van de twee voorheen bedachte losstaande centrale systemen en wordt het ontwerp (nogmaals) gewijzigd. Een aandachtspunt is de betrokkenheid en afstemming met gemeenten, de belangrijkste stakeholders van het project. Sinds de herstart van het project zijn verbeteringen aangedragen om de betrokkenheid van gemeenten te vergroten in de realisatie van de mGBA. De berichtgeving over verdere vertraging bij de ontwikkeling van de centrale BRP medio 2013 leidde tot zorgen bij de VNG en gemeenten. Sinds de herstart van het programma mGBA zijn er verschillende audits en adviezen uitgebracht. Uit de evaluaties komt onder andere naar voren dat de omvang, duur en complexiteit van het project mGBA risicovol is, en dat onderschatting van de complexiteit zich direct zal vertalen in effecten op tijd, geld en kwaliteit. Geconcludeerd wordt dat – hoewel het project nog in uitvoering is – toekomstige budgetoverschrijdingen en vertragingen waarschijnlijk zijn en dat de betrokkenheid van de belangrijkste stakeholders, de gemeenten, een aandachtspunt vormt (voor de komende jaren).

5.2.3

Gebruikers en afnemers

De gebruikers binnen het project Implementatie mGBA zijn de gemeenten en afnemers. Gemeenten

In totaal zijn er 418 gemeenten (per 01-01-2011). Naar omvang is de volgende verdeling te maken: Type Kleine gemeente Middelgroot Groot 100+ G4

Aantal inwoners Tot 20.000 20 – 50.000 50 – 100.000 100 – 250.000 Meer dan 250.000

Aantal gemeenten 156 191 45 22 4

50

Gemeenten hebben vanuit verschillende rollen te maken met de aansluiting op de centrale voorzieningen van de BRP:  Gemeente als bronhouder (gegevensbeheerder) voor het bijhouden van persoonsgegevens.  Gemeente als afnemer voor zowel buiten gemeentelijke als binnengemeentelijke verstrekkingen. Gemeenten blijven wel verantwoordelijk voor de binnengemeentelijke distributie.  Gemeenten als verstrekker. Gemeenten zijn nu dienstverleners van de verstrekkingen. Dit takenpakket gaat afnemen door de ontwikkeling van de centrale voorziening voor verstrekkingen. Gemeenten in hun rol als bijhouder krijgen te maken met centrale voorzieningen voor de basisregistratie personen. De huidige lokale systemen voor bijhouden van persoonsgegevens worden vervangen door Burgerzakenmodules en de centrale voorzieningen. Gemeenten blijven verantwoordelijk voor het bijhouden van de gegevens van de eigen ingezetenen. Afnemers Een afnemer is een organisatie die op basis van een autorisatiebesluit gegevens verstrekt krijgt uit de Basisregistratie Personen. De organisatie moet aantonen dat deze gegevens noodzakelijk zijn voor de uitoefening van zijn taak.

5.2.4

Gehanteerde projectportfoliomethodes

Voor de sturing van het programma is de stuurgroep Modernisering GBA (mGBA) in het leven geroepen die onder voorzitterschap van de waarnemend directeur-generaal is samengesteld uit vertegenwoordigers van de VNG, NVVB, gemeenten, afnemers en BZK. De stuurgroep wordt geadviseerd door een ambtelijke voorbereidingsgroep, programmabegeleidingsgroep. Modernisering GBA is een programma, waarvoor conform de methodiek van MSP een programmaplan is opgesteld. Voor de projecten binnen het programma worden conform de methodiek van Prince II, projectindicatiedocumenten opgesteld die ter goedkeuring zijn aangeboden aan de Stuurgroep Modernisering GBA.

5.3

Gehanteerde financiële sturingsmethode o.b.v. rapportage Capgemini

Inleiding In december 2008 is er een rapportage uitgebracht betreffende de business case van het project modernisering GBA, uitgevoerd door Capgemini N.V. Hierin worden een aantal alternatieve benaderingen voor het voortzetten van de modernisering GBA voor persoonsgegevens geanalyseerd en doorgerekend. Het programma Modernisering GBA heeft drie scenario’s geformuleerd die zijn opgebouwd uit vier componenten.

Scenario’s Kort samengevat kunnen de componenten van de modernisering als volgt worden beschreven: 1. Full Service: De afnemers vragen nu selecties op en ontvangen spontane mutaties vanuit de decentrale systemen van de gemeenten via het GBA-netwerk. GBA-V Full service houdt in dat deze selecties en mutaties voortaan vanuit één punt, namelijk het centrale GBA-V aan de afnemers worden geleverd. Dit scheidt het berichtenverkeer tussen gemeenten onderling en GBA-V enerzijds van het berichtenverkeer naar afnemers anderzijds; 2. Moderne Interfaces: Het bijhouden van de centrale GBA-V kopie, spontane mutaties naar afnemers en intergemeentelijk berichtenverkeer zijn nu niet real time. Moderne interfaces

51

betekent vervanging van het GBA-netwerk door berichtenverkeer volgens de OSB specificaties en maakt real time berichtenverkeer mogelijk. Hiertoe dienen de gemeentelijke burgerzaken systemen te worden aangepast of vervangen en dient GBA-V te worden uitgebreid met een berichtenmakelaar; 3. Burgerzakensysteem-kern: De implementatie van een BZS-K houdt in dat alle gemeenten een centraal ontwikkelde uniforme kernapplicatie gaan toepassen voor het opzoeken, wijzigen en opslaan, van persoonsgegevens t.b.v. burgers en binnengemeentelijke afdelingen in dienstverlenende processen. Deze wordt lokaal geïnstalleerd voor gebruik door de gemeenten. BZS-K omvat alleen de basisfuncties en lokale gegevensopslag en vereist Aanvullende Modules die de gebruikersinterface, workflow en verdere burgerzakenfunctionaliteit omvatten en, geheel onder verantwoordelijkheid van de gemeenten, door marktpartijen geleverd moeten worden. De huidige burgerzakensystemen worden vervangen door een BZS-K met een of meer Aanvullende Modules; 4. Logisch Ontwerp (LO) 4.0: Het LO (Logisch Ontwerp) specificeert o.a. de eisen die worden gesteld aan een gegevens set (gegevenswoordenboek) en het gegevensmodel van het burgerzaken systeem. Momenteel wordt LO3 gebruikt waarop via wijzigingsprocedures steeds aanvullingen worden gedaan. LO4 impliceert de vervanging van LO3 door een geheel nieuw gegevensmodel. De scenario’s zijn opgebouwd uit combinaties van deze vier componenten, zoals in onderstaande figuur wordt weergegeven:

Figuur 10: de drie scenario’s

Scenario’s uitgedrukt in financiële waarden Voor de drie scenario’s zijn de Netto Contante waarde (NCW) en de terugverdientijd berekend. Hieronder zijn de uitkomsten opgenomen:

Totaal

NCW in duizenden euro’s

Terugverdientijd

Scenario 1

149.178

3,0 jaar

Scenario 2 Scenario 3

169.319 -25.362

6,0 jaar -

De financiële waarden van scenario 1 en 2 zijn positief. Scenario 3 daarentegen geeft een negatieve NCW. Dit betekent dat investeren in scenario 1 en 2 zal leiden tot potentiële waarde creatie voor de maatschappij in zijn totaliteit. Scenario 2 creëert meer waarde dan scenario 1, maar wel met een langere terugverdientijd.

52

Niet voor alle stakeholdergroepen is de waarde van scenario 1 en 2 even groot. De baten zullen voornamelijk ten gunste komen van de gemeenten en in mindere mate van afnemers en het Rijk. De kosten worden daarentegen gedragen door het Rijk en in mindere mate door de gemeenten en afnemers. De hoogte van de financiële waarde van scenario 1 en 2 wordt met name bepaald door grote baten als gevolg van OSB berichtenuitwisselingen met relatief weinig kosten (aangezien organisaties ook zonder uitvoering van het programma Modernisering GBA al overgaan op de OSB) en door het kostenefficiënt uitvoeren van verstrekkingen op centraal niveau. In scenario 2 komt daar nog bij dat op ICT-kosten ook kan worden bespaard vanwege het centraal ontwikkelen van een BZSK, het optreden van meer marktwerking en minder kosten voor koppelvlakken.

Uitgangspunten van de business case Om de business case voldoende te kunnen afbakenen is gebruik gemaakt van criteria, normen en aannames die zijn afgestemd met het agentschap BPR en zijn gevalideerd door de begeleidingscommissie. De volgende uitgangspunten zijn gehanteerd: 1. Kosten en baten gelden ‘vanaf nu’ In het verleden gemaakte kosten en/of behaalde baten bij belanghebbenden worden niet meegerekend in de business case, ook niet als deze mogelijk in directe relatie stonden met de ontwikkeling van het GBA. 2. De oplossingscomponenten zijn uitvoerbaar en worden efficiënt ontwikkeld Ten aanzien van de door het programma mGBA aangedragen oplossingscomponenten zoals in deze business case onderzocht geldt de aanname dat deze realiseerbaar zijn, zowel praktisch (dus uitvoerbaar) als juridisch; er zijn geen juridische bezwaren. De technische achtergrond van de oplossingscomponenten is buiten scope voor de business case en wordt geadresseerd in de definitiestudie. In de business case wordt uitgegaan van een efficiënte ontwikkeling van de componenten. 3. De ICT-investeringscyclus van afnemers en gemeenten wordt gevolgd We gaan er van uit dat het vervangen van systemen door stakeholders, waar van toepassing, zal gebeuren op het moment dat men dit toch al zou doen in het kader van een reguliere vervanging. De systeemvervangingen die samenhangen met de onderkende oplossingscomponenten leiden daarmee niet tot ‘extra’ kosten ten opzichte van de kosten die toch al zouden worden gemaakt in het kader van het normale vervangingspatroon. Voor gemeenten hanteren wij een gemiddeld vervangingsinterval van 5 jaar; voor afnemers hanteren wij een gemiddeld vervangingsinterval van 7 jaar. 4. Toerekening baten en lasten De baten en kosten zijn in deze business case toegerekend daar waar de daadwerkelijke kasstroom optreedt, met uitzondering van die kasstromen waar vooraf verrekenafspraken over zijn gemaakt. Zo geldt onder andere:  BPR financiert ontwerp, bouw en uitrol van de BZS-K en tevens vervangingen van de BZS-K  Alle wijzigingen in het LO conform LO procedure worden via BPR gefinancierd door de kerndepartementen  Lokale beheeractiviteiten rondom de BZS-K worden gefinancierd door de eigen interne organisatie van gemeenten 5. De business case is gebaseerd op een aantal financiële uitgangspunten waaronder:  Een disconteringsvoet van 4.3%  De business case omvat geen afschrijvingen of financieringskosten, alleen nominale kasstromen

53

  

Een evaluatieperiode van 15 jaar is doorgerekend Vrijgespeelde FTE’s zijn gewaardeerd op een gemiddelde loonschaal De Business Case bepaalt de economische waarde (Netto Contante Waarde) van de drie onderkende scenario’s voor de stakeholdergroepen.

De drie scenario’s verder toegelicht Gebaseerd op de hiervoor benoemde componenten zijn drie investeringsscenario’s gedefinieerd door het programma mGBA. Naast het concretiseren van de investeringsscenario’s is het van belang om de uitgangssituatie vast te stellen. De business case is feitelijk een berekening van het verschil tussen ‘niet investeren’ en wél investeren, die dient om vast te stellen of een investering economisch zinvol zal zijn. De situatie zoals die zou zijn bij een beslissing om niet te investeren, noemen we de baseline (scenario).

Baseline scenario Het baseline scenario kan worden vergeleken met de huidige situatie en hoe deze zich in de komende jaren zal ontwikkelen, indien niet wordt gekozen voor één van de investeringsscenario’s. In het baseline scenario wordt dus niet geïnvesteerd in één van de scenario’s, maar zullen wel kosten moeten worden gemaakt voor het in stand houden van de huidige GBA structuur. In het baseline scenario zijn er daarom wel degelijk kosten, maar dit zijn de gebruikelijke exploitatiekosten en minimale investeringen om aan de wetgeving en de huidige geldende kwaliteitseisen te kunnen blijven voldoen. Om goed het verschil te kunnen berekenen tussen investeren en niet investeren is het van belang te bekijken of kosten in het baseline scenario zullen stijgen of dalen als gevolg van andere, niet aan de investeringsscenario’s gekoppelde, ontwikkelingen. De volgende aannames betreffende de baseline van de stakeholdergroepen zijn gemaakt. BPR:   

Het aantal berichten per jaar voor de komende 15 jaar wordt constant geacht en zal niet stijgen of dalen. De totale kosten gemoeid met de netwerken GBA en GBA-V zullen niet stijgen of dalen. De huidige beheerexploitatie zal een forse stijging laten zien. Het huidige beheer van GBA-V is van onvoldoende kwaliteit om de komende jaren te kunnen volstaan. Ongeacht welk scenario wordt gekozen, zal de beheertooling worden aangepast. Daarnaast dienen ook kosten te worden gemaakt voor vervanging van infrastructuur en onderhoud aan de systemen. Deze kostenposten zijn niet opgenomen in de huidige begroting van BPR, maar zijn wel onderdeel van de baseline. Immers, in de nabije toekomst moeten deze kosten worden gemaakt, ongeacht welk scenario wordt gekozen.

Gemeenten:  Het patroon en niveau van beheer- en ontwikkelkosten t.a.v. burgerzakensysteem en backoffice systemen (inclusief koppelingen) blijft stabiel.  Elke vijf jaar vervangt de gemeente haar systemen.  Aansluiting op de OSB uiterlijk in 2010 in verband met het stelsel van basisregistraties. De kosten voor het aansluiten en beheer van de OSB (en eventuele binnengemeentelijke servicebussen) maken onderdeel uit van het baseline scenario. In het bepalen van de investeringen gemoeid met de drie scenario’s, zijn deze kosten derhalve niet meegenomen.  Het niveau van vergoedingen uitgekeerd door BPR aan gemeenten voor LO-wijzigingen blijft stabiel.

54

Afnemers:   

Stabiel patroon en niveau van beheer- en ontwikkelkosten t.a.v. primaire proces systemen; Elke zeven jaar vervangt de afnemer haar systemen; Aansluiting op de OSB uiterlijk in 2010 in verband met het stelsel van basisregistraties. De kosten voor het aansluiten en beheer van de OSB (en eventuele interne servicebussen) maken onderdeel uit van het baseline scenario. In het bepalen van de investeringen gemoeid met de drie scenario’s, zijn deze kosten derhalve niet meegenomen. Overleg met ICTU en ODP heeft aangetoond dat bijna alle afnemers voor meer dan één basisregistratie gebruik zullen gaan maken van de OSB. De aanschafkosten voor de adapters/gateways en onderhoud zijn dan ook geen kosten die aan deze business case kunnen worden toegerekend.

Scenario 1: GBA-V Full service in combinatie met Moderne interfaces

Figuur 11: Uitwerking scenario 1

Scenario 1 houdt in dat de componenten Full Services en Moderne Interfaces worden gerealiseerd. De eindsituatie van scenario 1 houdt in dat systematische verstrekkingen vanuit één punt, namelijk het centrale GBA-V aan afnemers worden geleverd en dat het berichtenverkeer real time via de OSB verloopt. Zoals weergegeven in het schema hierboven, vervalt de taak van het leveren van verstrekkingen aan afnemers door gemeenten. Waar de oude taak bestond uit het bijhouden van gegevens en het verstrekken hiervan, blijft alleen de bijhoudingstaak over. Realisatie van Full Services en Moderne interfaces zal betekenen dat de mutaties die bij de bronhouders (gemeenten) worden doorgevoerd, real time ofwel direct na verwerking beschikbaar zijn in GBA-V. Iedere verstrekking vanuit GBA-V zal daarmee up to date zijn naar de laatste stand van de mutaties bij de gemeenten en direct in vorm van spontane mutaties aan de afnemers die een afnemersindicatie hebben worden doorgestuurd. Omdat in dit scenario, in tegenstelling tot scenario 2 geen BZS-K zal worden ingevoerd, is het daarnaast nodig om de huidige burgerzakensystemen van de gemeenten aan te passen voor aansluiting op de OSB. Naast aansluiting dienen deze systemen zo te worden ingericht dat ze berichten meteen na de verwerking kunnen verzenden en om kunnen gaan met real time intergemeentelijk berichtenverkeer. Extra investeringen in ieder van de 5 verschillende burgerzakensystemen zullen hiervoor benodigd zijn evenals een specificatie van de benodigde wijzigingen in een LO procedure en voorzieningen om het mogelijk te maken dat deel van de gemeenten al over is op moderne interfaces terwijl een ander deel van de gemeenten nog via het huidige GBA-netwerk communiceert.

55

De aanname is dat andere wensen van afnemers ten aanzien van de berichten tegelijk met de invoering van Moderne Interfaces worden gerealiseerd, voor zover deze geen betrekking hebben op de wijziging naar het LO4 gegevensmodel die in dit scenario geen doorgang vindt (althans niet binnen de in de businesscase doorgerekende periode).

Scenario 2: GBA-V Full service i.c.m. Moderne interfaces, BZS-K en LO4

Figuur 12: Uitwerking scenario 2

In scenario 2 worden alle componenten gerealiseerd conform de oorspronkelijke opzet van het programma Modernisering GBA. Evenals in scenario 1 is de eindsituatie dat systematische verstrekkingen vanuit één punt, namelijk het centrale GBA-V aan afnemers worden geleverd en dat het berichtenverkeer real time via de OSB verloopt. Daarnaast vervangen alle gemeenten hun huidige burgerzakensysteem door een uniform BZS-K en een of meer Aanvullende Modules geleverd door marktpartijen. Ten derde is het gegevensmodel na afronding van de migratie zowel in de gemeenten, in GBA-V als in berichtenverkeer naar afnemers gebaseerd op het LO4 gegevensmodel. De figuur toont de verschillen met scenario 1 in de eindsituatie: allereerst verschilt de eindsituatie bij de gemeenten aanzienlijk. In scenario 2 worden de burgerzakensystemen bij de gemeenten geheel vervangen en verdwijnt de bestaande procedure voor het specificeren van wijzigingen in de door marktpartijen geleverde burgerzakensystemen. In plaats daarvan onderhoudt BPR de basisfunctionaliteit in BZS-K en is deze door een open en gestandaardiseerd koppelvlak gescheiden van de Aanvullende Modules die volledig onder verantwoordelijkheid van de gemeenten vallen en niet beïnvloed mogen worden door wijzigingen in BZS-K. Voor deze business case is aangenomen dat de BZS-K direct gebaseerd wordt op het LO4 waarmee een gemeente bij de implementatie van de BZS-K dus ook overgaat op LO4. Omdat niet iedere gemeente op hetzelfde moment over kan gaan op de nieuwe BZS-K, stelt dit scenario wel als eis dat de verstrekkingen vanuit BPR tijdelijk zowel in LO3 als in LO4 beschikbaar zijn. Hiertoe wordt aan de zijde van GBA-V in een veel uitgebreidere conversiemodule voorzien dan in scenario 1 en bovendien zal GBA-V tijdelijk zowel in LO3 als in LO4 de gegevens opslaan. Voor die systemen van afnemers die na de implementatie van het LO4 nog niet geschikt zijn voor de berichtenstructuur van LO4, zal een ‘vertaalmodule’ (conversiemodule) moeten worden behouden tot het natuurlijke moment van vervanging van het back office systeem. Hierbij gaan we er van uit dat nieuwe releases van die systemen conform de reguliere update procedures worden uitgerold en dat deze gebaseerd zullen zijn op, c.q. aangepast zullen zijn aan het LO4. De aanname is dat andere wensen van afnemers ten aanzien van de berichten tegelijk met de invoering van Moderne Interfaces en LO4 worden gerealiseerd.

56

Scenario 3. Invoering LO4 gegevensmodel

Figuur 13: Uitwerking scenario 3

In het derde scenario wordt alleen het LO4 gegevensmodel ingevoerd. Het huidige GBA-netwerk blijft gehandhaafd, evenals de rolverdeling tussen BPR en gemeenten. Gemeenten blijven dus verantwoordelijk voor de spontane mutaties en selecties en zullen rechtstreeks aan de afnemers blijven leveren zonder tussenkomst van de beheerorganisatie BPR. Wel zal de inhoud van de verstrekkingen (berichten) gaan verschillen omdat de gegevensset en het gegevensmodel zoals in LO3 gedefinieerd, zullen veranderen. Dit betekent dat er aan de zijde van de verstrekker (gemeenten) lokaal een conversiemodule nodig is om zowel LO3 als LO4 te kunnen leveren al naar gelang de situatie van de afnemer. Zodra alle afnemers in staat zijn om op LO4 gebaseerde berichten te verwerken kan deze conversiemodule komen te vervallen. Het inmiddels gerealiseerde GBA-V Online blijft in productie en dient eveneens aangepast te worden aan het LO4 gegevensmodel. Te verwachten valt dat GBA-V Online meer gebruikt zal worden en dat het (veel langzamere) stellen van ad hoc vragen via het GBA-netwerk zal afnemen en uiteindelijk verdwijnen.

5.3.1

Baten- en kostengebieden per stakeholder

In dit hoofdstuk worden deze baten- en kostengebieden per stakeholder en per scenario in kaart gebracht. Aangezien de verschillende gebieden in meerdere scenario’s voorkomen, wordt een toelichting gegeven per gebied in plaats van per scenario. In het overzicht is terug te vinden welk baten- en kostengebied in welk scenario optreedt. In de overzichten van baten en kosten per scenario geven de dikgedrukte gebieden een substantiële baten- of kostenpost aan. Dit betekent niet dat door een individuele stakeholder deze post als hoog wordt gekwalificeerd, maar dat op macroniveau in de business case deze post een aanzienlijk effect in het financieel model heeft. Deze dikgedrukte gebieden zullen worden toegelicht.

Overzicht baten en kosten Gemeenten Hieronder volgt een overzicht van de baten en kosten voor gemeenten. Vervolgens wordt hierop een toelichting gegeven.

57

Baten gemeenten Minder kosten verstrekkingen Door het invoeren van GBA-V Full service, wordt de taak van het verzorgen van verstrekkingen c.q. selecties door agentschap BPR overgenomen. Deze taak berust in de huidige situatie bij de gemeenten, die voor afnemers en andere gemeenten de selecties opstellen en versturen. Uitfaseren VOA en Gemnet aansluiting Doordat berichtenuitwisseling via de OSB plaatsvindt, wordt de huidige Verzend en Ontvangstapplicatie Afnemers (VOA) overbodig, evenals de netwerkaansluiting. Dit geldt alleen voor de gemeenten die op dit moment vanuit GBA-V gegevens afnemen. ICT-kosten besparing op koppelvlakken Door het implementeren van BZS-K zal het gemakkelijker worden koppelvlakken naar back office applicaties te bouwen op het burgerzakensysteem, gezien het feit dat er gewerkt kan worden met open source standaarden en eenmaal gebouwde koppelingen gemakkelijker kunnen worden hergebruikt. De respondenten geven aan dat zij aan dit feit een kostenbesparing toeschrijven op de aanschafprijs van koppelvlakken. Minder kosten burgerzaken-systeem Doordat de invoering van de nieuwe BZS-K vanuit BPR zal worden opgepakt, vervallen voor de gemeenten de kosten van dit ‘deel’ van het burgerzakensysteem en hebben zij alleen – in het reguliere vervangingspatroon – kosten voor het aanschaffen van de aanvullende modules. Dit betekent een structurele baat in de aanschafkosten van burgerzakensystemen. Kosten gemeenten Kosten aanpassen Burgerzakensysteem (alleen in scenario 1) Om via moderne interfaces berichten uit te wisselen, dienen de burgerzakensystemen van gemeenten te worden aangepast of opnieuw gebouwd te worden, zodanig dat zij real time verwerking mogelijk kunnen maken en meer SOA-opgebouwd zijn. Deze aanpassing doet de gemeente als zij haar burgerzakensysteem vervangt. De leveranciers dienen dan een aangepast/vernieuwd systeem te ontwikkelen. De ontwikkelingskosten van dit nieuwe/aangepaste burgerzakensysteem zijn hoger dan de gebruikelijke ontwikkelkosten van de leverancier. Aangenomen wordt dat de gemeenten deze extra ontwikkelkosten vergoeden. Wellicht is een lagere vergoeding/andere oplossing mogelijk. NB: De kosten voor het aanpassen van overige gemeentelijke systemen aan het real time verwerken van GBA-gegevens, worden niet als investering in deze business case opgenomen. Aansluiting wordt

58

gezocht bij het investeringsritme van gemeenten, waardoor deze kosten onderdeel zijn van het gebruikelijke budget voor vervanging van software/hardware.

Overzicht baten en kosten Afnemers Hieronder volgt een overzicht van de baten en kosten voor afnemers. Vervolgens wordt hierop een toelichting gegeven. Baten afnemers Minder verwerkingstijd selecties + herstelwerkzaamheden op kwaliteit data De afnemers geven aan dat door het invoeren van met name GBA-V Full service (met centralisatie van verstrekking) het verkrijgen van GBA gegevens minder tijd kost. De voordelen hebben met name betrekking op:  Minder vaak selecties opnieuw moeten plaatsen  Minder tijdbesteding controleren en herstellen (opnieuw plaatsen van selecties) van aangeleverde data door gemeenten  Minder verwerkingstijd als gevolg van niet meer toegezonden krijgen verschillende soorten ‘vaste’ media (1 dvd, i.p.v. meerdere dvd’s, diskettes, etc.) Naar aanleiding van de workshops en aanvullende inventarisatie is vastgesteld dat deze baat zich voordoet bij afnemers, maar gering wordt geacht en verschilt per afnemer. Kosten afnemers Kosten aanschaf en onderhoud conversiemodule Zodra een gemeente over is gegaan op de BZS-K ontvangt en verzendt zij berichten op basis van LO4. De afnemer dient deze berichten te kunnen ontvangen en door te sturen naar haar systemen. Indien deze systemen nog niet aangepast zijn aan het nieuwe bericht, is een tijdelijke conversiemodule nodig. Dit is een relatief eenvoudige conversiemodule.

59

Overzicht baten en kosten BRP / Rijk Hieronder volgt een overzicht van de baten en kosten voor BRP / Het Rijk. Vervolgens wordt hierop een toelichting gegeven. Baten Rijk Minder netwerkkosten door moderne interfaces Op het moment dat alle afnemers en gemeenten via de OSB gegevens uitwisselen, zal het huidige netwerk (met alle services) overbodig worden en kunnen worden uit gefaseerd. Hier tegenover staan nieuwe (maar goedkopere) netwerkkosten. Deze baat levert een positieve kasstroom voor het agentschap BPR op. Kosten Rijk Ontwerp, bouw en testen GBA-V Full Service en aanpassing van de beheertooling op basis van het huidige LO (in scenario 1) en op basis van LO4.0 (in scenario 2) De afbakening van Full Service is gebaseerd op de uitwerking in de inceptionfase ‘GBA-V R5’ die op 16 juni 2008 is opgeleverd. Het gaat hierbij om:  LO3 netwerkdiensten uitbreiden met berichten voor spontane mutaties en selecties en ontvangen van berichten van afnemers inzake selecties, muteren afnemersindicaties etc.  Gegevensverstrekking uitbreiden t.b.v. verzenden spontane mutaties  Realiseren van afnemersindicaties op GBA-V (i.p.v. bij gemeenten)  Selectiefunctionaliteit op GBA-V en leveren op Alternatief Medium en nieuwe vorm van levering middels upload Uitbreiding infrastructuur De uitbreiding van infrastructuur is volgens BPR noodzakelijk. Ontwerp, bouw, testen en implementatie van BZSK o.b.v. LO4 De Burgerzakensysteem- kern wordt centraal ontwikkeld en decentraal geplaatst bij gemeenten. In tegenstelling tot de huidige situatie waar 3 aanbieders en 5 leveranciers actief zijn, zullen voor dit deel van het burgerzakensysteem slechts 1 uniform systeem worden gemaakt. De kosten voor ontwerp, bouw, test en ondersteuning van gemeenten implementatie van deze kern komen voor rekening van BPR. 60

Beheer van BZS-K Onder beheerkosten verstaan we de aanpassing in software en uitlevering daarvan aan gemeenten en hun leveranciers als gevolg van gewijzigde eisen. Deze kosten zijn begroot op 15% van de bouw en test van de applicatie.

5.3.2

Resultaten en conclusies business case

Het vorige hoofdstuk biedt inzicht in de baten- en kostengebieden van ieder scenario voor de verschillende stakeholdergroepen. In het onderzoek zijn, volgend op het vaststellen van deze set van baten en lasten, de baten en lasten gekwantificeerd en verwerkt in een financieel model. De uitkomsten van dit financiële model worden in dit hoofdstuk gepresenteerd. Tevens is een toelichting op de aannames betreffende de baten en kosten per scenario en stakeholdergroep gegeven.

Resultaten per scenario Hieronder wordt voor elk van de scenario’s kort de financiële- en niet gekwantificeerde waarde weergegeven. Met betrekking tot de financiële waarde wordt een overzicht gegeven van de cumulatieve baten en kosten over de gehele evaluatieperiode (15 jaar) voor een bepaalde stakeholdergroep. Vervolgens is ook de Netto Contante Waarde en terugverdientijd weergegeven.

Scenario 1

Financiële waarde De Netto Contante Waarde van scenario 1 is op macroniveau positief, dit betekent dat investeren in dit scenario zal leiden tot potentiële waarde creatie voor de maatschappij in zijn totaliteit. Niet voor alle stakeholdergroepen is de waarde van dit scenario even groot. De baten zullen voornamelijk ten gunste komen van de gemeenten en in mindere mate van afnemers en het agentschap BPR. De kosten worden daarentegen gedragen door gemeenten en het agentschap BPR. De grootste kostenposten zijn het aanpassen van de gemeentelijke GBA-systemen aan real time verwerking ten laste van de gemeenten en het implementeren van Full service door BPR.

61

De hoogte van de financiële waarde wordt in dit scenario bepaald door: 





Grote baten en relatief weinig kosten door de OSB uitwisseling o Door berichtenuitwisseling via de OSB vervallen voor gemeenten en afnemers de kosten voor het gebruik van VOA’s en netwerkaansluitingen ten behoeve van de GBA en tevens (baat voor BPR) kan het oude GBA-netwerk worden uit gefaseerd; o Dit is een grote baat, waar tegenover beperkte investeringen staan, aangezien gemeenten en afnemers gedreven vanuit het stelsel van basisregistraties al gaan aansluiten op de OSB. De kosten voor deze aansluiting zijn niet toe te rekenen aan de modernisering van de GBA. Wel dient het agentschap BPR kosten te maken, zoals de aanschaf van adapters. Kosten efficiënt centraal uitvoeren van verstrekkingen o Het centraal verstrekken van GBA-data aan afnemers is efficiënter dan in de huidige situatie waar dit door 443 gemeenten wordt uitgevoerd; o Hiervoor dient wel een initiële investering in GBA-V Full service te worden gedaan. Actualiteit van GBA-data o Een geringe financiële baat ontstaat doordat actuelere data leidt tot minder herstelwerk ten aanzien van de kwaliteit van data, voornamelijk bij gemeenten; o Relatief grote kosten moeten worden gemaakt door gemeenten voor het real time verwerken van wijzigingen en het aanpassen van de gemeentelijke GBA-systemen en werkprocessen.

Scenario 2

Financiële waarde In scenario 2 wordt veel waarde gecreëerd voor de maatschappij in totaliteit. De netto contante waarde van dit scenario is hoger dan in scenario 1. Wel kent dit scenario een langere terugverdientijd. Ook hier geldt dat de waarde van dit scenario niet voor elke stakeholder even groot is. Voornamelijk gemeenten hebben baat bij dit scenario en het Rijk/ agentschap BPR zal moeten investeren. In scenario 2 geldt net als in scenario 1 dat de waarde creatie wordt bepaalt door het gebruik maken van de OSB, het centraal verstrekken van GBA-gegevens aan afnemers en het real time verwerken van GBA- gegevens.

62

Daarnaast wordt in dit scenario extra waarde gecreëerd door: 



Kostenefficiency ten aanzien van ICT-kosten GBA o Het centraal ontwikkelen en beheren van de BZS-K kent twee grote effecten op de ICT-kosten van gemeenten. Zowel de kosten voor gemeentelijke burgerzakensystemen nemen af als de kosten voor koppelingen. Daarnaast is ook een marginaal voordeel te behalen door meer marktwerking. Voordelen nieuw gegevensmodel als bijeffect bij implementatie BZS-K, maar wel met hoge conversiekosten o De nieuwe BZS-K wordt gebouwd op basis van het nieuwe gegevensmodel. De baten van het nieuwe gegevensmodel worden meegenomen in dit scenario. Daartegenover staan niet de gebruikelijke vergoedingen voor het doorvoeren van een nieuw LO, aangezien alleen de kosten voor een nieuw BZS-K worden gemaakt die vele malen lager liggen dan een grote wijziging van het LO in 5 systemen. o Anderzijds dienen wel grote kosten te worden gemaakt door BPR voor de conversie van LO3 naar LO4.

Scenario 3

In scenario 3 wordt in tegenstelling tot de scenario’s 1 en 2 geen positieve waarde gecreëerd voor de maatschappij in totaliteit. De Netto Contante Waarde is negatief. Ook hier geldt dat de waarde van dit scenario verschilt per stakeholder. De gemeenten hebben als enige stakeholdergroep baat bij dit scenario. Het Rijk/agentschap BPR en de afnemers zullen hun investeringen niet terugverdienen. De negatieve waarde creatie wordt in dit scenario veroorzaakt door hoge conversiekosten en geringe financiële baten. Ook kwalitatieve baten zoals verbeteren van de datakwaliteit zijn als gering aangeduid.

63

5.3.3

Conclusie

De financiële analyse laat zien dat zowel scenario 1 als 2 waarde creëren op macroniveau. In beide scenario’s leveren incidentele investeringen aan de zijde van voornamelijk het rijk en gemeenten, structurele baten bij gemeenten en afnemers.

5.4

Gekozen methodiek op basis van rapportage Capgemini

In de Gateway review van d.d. 23 april 2010, wordt aangegeven dat er is gekozen voor het volledig uitvoeren van het programma. Dit is scenario 2. Wel worden er in de Gateway review een aantal aanbevelingen gedaan:  Vanuit (de aansturing van) het programmateam is er een sterke voorkeur voor het beperkt houden van de focus. Vanuit verschillende invalshoeken is dat begrijpelijk. Beleidsmatig perkt dit het gebied af waarvoor de staatssecretaris de politieke verantwoordelijkheid neemt en is het dus eenvoudiger om te laten zien dat er geleverd is wat er beloofd is;  Er heerst veel onduidelijkheid en weinig bestuurlijke notie bij gemeenten over wat er hun met het mGBA te wachten staat. Verschaf gemeenten z.s.m. meer zicht op de te verwachten kosten van de implementatie en het gebruik van de mGBA;  Lever een bijdrage aan het versterken van de bestuurlijke notie binnen gemeenten over het cruciale belang van voornamelijk het mGBA voor de modernisering van de dienstverlening aan de burger;  Zorg voor meer tweeweg communicatie tussen programma en gemeenten;  Maak het leveren van werkende (deel-)producten volgens planning een topprioriteit.  Zorg ervoor dat de vaart en de focus die het programma nu heeft, gedurende de looptijd behouden blijft. Tevens wordt hierbij aangegeven dat de gekozen methodiek van aanbesteden en modularisatie van mGBA haalbaar lijkt maar ambitieus is. Er wordt geconstateerd dat er in de planning van het bouwtraject geen ‘slack’ is ingebouwd. Dit betekent dat er weinig tot geen rekening in de planning is gehouden met een eventuele uitloop van het bouwtraject.

5.5

Bijstelling Business Case mGBA

In augustus 2011 is er door Capgemini een nieuw rapport uitgebracht met de titel ‘Rapportage Toetsing en bijstelling business case Modernisering GBA’. De doelstelling van de opdracht kan als volgt worden samengevat: Toets op basis van voortschrijdende inzichten de huidige (verhelderde) business case mGBA en stel deze (na overleg met de opdrachtgever) zo nodig bij. Na het bestuurlijk akkoord is gekozen voor het centraal positioneren van de BZS-K systeem met een optie voor gemeenten dit systeem ook lokaal in te richten. Bij het uitwerken van de architectuur is vervolgens gekozen om het toekomstige systeem geheel nieuw te bouwen met één nieuwe centrale LO BRP database en daarbij niet op het bestaande GBA-V systeem door te ontwikkelen (het bestaande GBA-V systeem wordt aangeduid als GBA-V 2008). Het nieuwe BRP systeem zal naast de nieuwe Full Service functionaliteit ook de al bestaande GBA-V 2008 (ad hoc) functionaliteit omvatten, echter wel in de op LO BRP gebaseerde variant. De Basisregistratie personen zal zo worden opgezet dat daarbinnen ook de gegevens worden

64

opgenomen van niet-ingezetenen. Deze gegevens zullen echter in eerste instantie nog in een afzonderlijke registratie van niet-ingezetenen (RNI) worden opgenomen. Het in het vorige scenario genoemde LO4 heet in de huidige situatie LO BRP. Dit LO BRP verschilt van het oorspronkelijke LO4 door de grotere mate waarin dit relationeel opgesteld is. De aanvullende modules heten nu burgerzaken modules. De wijzigingen binnen het programma in de afgelopen periode leiden in feite dus tot een nieuw scenario. Kosten Op het moment van het uitbrengen van het rapport kan de toetsing van de kosten van het Rijk alleen plaatsvinden op basis van de totale kosten in de business case versus de totale kosten in de begrotingen versus het financieel arrangement. Het volgende beeld ontstaat: Voor de kosten voor het Rijk, van het programma mGBA, is in de oorspronkelijke business case € 31,6 miljoen opgenomen. In de meest recente begroting zijn de kosten echter € 38,8 miljoen. Op deze € 38,8 miljoen is in de herziene business case € 262.000,- in mindering gebracht. Dit betreft kosten voor aanpassing van de beheertooling, die reeds vergoed zijn door BPR, waardoor de kosten voor het Rijk van het programma mGBA in de herziene business case uitkomen op € 38,6 miljoen. De kosten voor de gemeenten stijgen niet, maar kunnen mogelijk afnemen. De afnemers kennen alleen baten en geen kosten, dus voor deze stakeholders hebben de aanpassingen in het scenario geen invloed. Baten De stakeholders en experts herkennen nog steeds dezelfde baten als gevolg van de modernisering van de GBA, ook nu gekozen wordt voor BRP. De kwalitatieve baten nemen wellicht verder toe aangezien de mGBA steeds randvoorwaardelijker gesteld wordt. De totale kwantitatieve baten in de business case nemen echter af met € 33,5 miljoen. De baten van de afnemers blijven gelijk, de daling bij de gemeenten is € 16,3 miljoen (-5,7%) en de daling bij het rijk is € 17,2 miljoen (-47,5%). De daling bij de gemeenten wordt met name veroorzaakt doordat het aantal gemeenten is gedaald. Ook de daling in de baten van het Rijk is niet het gevolg van ontwikkelingen binnen het programma, maar doordat sinds de realisatie van de business case autonome ontwikkelingen bij de stakeholders hebben plaatsgevonden, waardoor basisbedragen niet meer actueel zijn. Deze ontwikkelingen hebben met name betrekking op prijsverlagingen door leveranciers, automatisering en invoering van zaaksystemen bij gemeenten en het achterblijven van de realisatie van de Gemma-architectuur. De belangrijkste externe ontwikkelingen rondom het programma zijn:  De ontwikkeling van stelselvoorzieningen en gegeven technische aansluiting van de verschillende basisregistraties;  (Budget)financiering van het stelsel;  De digitalisering/ modernisering burgerlijke stand;  Bezuinigingen bij gemeenten;  De ontwikkelingen in kader van de compacte overheid.

65

5.6

Evaluatie mGBA door Gartner in 2013

Er wordt in het programma mGBA sinds 2011 gebouwd aan nieuwe technische voorzieningen om de persoonsgegevens centraal bij te houden en te verstrekken, de BRP-voorzieningen (BRP). Nadat de eerdergenoemde problemen (die leidden tot uitloop van de planning en overschrijding van het programmabudget) aan het licht waren gekomen heeft Gartner onderzoek naar de modernisering uitgevoerd. Eerst heeft Gartner een review uitgevoerd op de uitloop en de kosten van de bouw. Daarna zijn drie scenario’s voor kostenbeheersing gevalideerd. De twee meest geschikte scenario’s zijn in meer detail uitgewerkt en opnieuw gevalideerd. Uit de conclusies van Gartner blijkt dat uitloop van het programma en overschrijding van het budget aan de orde zijn. Voor dat probleem is een aantal potentiële oplossingsrichtingen, in de vorm van drie scenario’s, geduid en door BKZ nader uitgewerkt. Vervolgens heeft Gartner deze scenario’s getoetst op planning, kosten en risico’s en de mate van het bereiken van de doelstellingen van de modernisering van de GBA. Een eerste scenario dat bekeken is, is te formuleren als doorgaan op de huidige koers bij de bouw van de BRP, maar met meer fasering en meer beheersing. Een tweede scenario (Verbouw) is te typeren als het vermijden van een langdurige periode van twee systemen die naast elkaar gebruikt worden, door het verbouwen van de bestaande technische voorzieningen. Met de nieuwbouw BRP zou in dit scenario worden gestopt. Een derde scenario (Afronden nieuwbouw) vermijdt eveneens het langdurig naast elkaar gebruiken van twee systemen, maar redeneert vanuit het invoegen van de huidige GBA-V in de nieuwe centrale voorzieningen van de basisregistratie personen (BRP). In dit scenario wordt de nieuwbouw van de BRP voortgezet en afgerond, maar met een andere technische oplossing die de periode bekort waarin zowel de oude als de nieuwe voorzieningen gebruikt worden. De uitkomst van de toetsing van deze drie scenario's door Gartner, waarvan vlak voor de zomer 2013 de eerste bevindingen beschikbaar kwamen, laat zien dat het eerste scenario onaanvaardbaar hoge kosten en risico’s met zich mee brengt. Het belangrijkste, technische, risico is gelegen in het langdurig naast elkaar draaien en synchroon houden van de gegevens in de twee systemen GBA-V en BRP. De andere twee scenario’s, «Verbouw» en «Afronden nieuwbouw», reduceren dit risico en bieden bovendien aanknopingspunten om de kosten van het dubbel draaien te beperken. Om een goede, diepgaande vergelijking tussen de scenario’s Verbouw en Afronden nieuwbouw mogelijk te maken, heeft er een verdere uitwerking van deze scenario’s plaatsgevonden. De belangrijkste conclusies uit deze validatie zijn:  Beide scenario’s brengen extra kosten met zich mee ten opzichte van het huidige budget voor de modernisering GBA. De ontwikkelkosten voor Verbouw bedragen € 18 miljoen, de ontwikkelkosten voor Afronden nieuwbouw bedragen € 21 miljoen.  De scenario’s onderscheiden zich ten opzichte van elkaar niet doorslaggevend op het vlak van de kosten.  Beide scenario’s zijn technisch haalbaar, voldoen aan de wet BRP, en kunnen de doelstellingen van de modernisering realiseren.  Het scenario Afronden nieuwbouw leidt op termijn tot een hogere gegevenskwaliteit.  De voorzieningen die het scenario Afronden nieuwbouw oplevert zijn eenvoudiger te onderhouden en tevens flexibeler, wat het doorvoeren van wijzigingen in de toekomst eenvoudiger en goedkoper maakt.  Verbouw gaat uit van twee momenten waarop alle gemeenten gelijktijdig over moeten stappen, bij Afronden nieuwbouw gaan de gemeenten en afnemers in een periode van twee jaar geleidelijk over.

66





5.7

De implementatiestrategie van Verbouw heeft een kritiek pad. De twee gezamenlijke implementatiemomenten worden gezien als risicovol maar genereren tegelijkertijd druk om op een afgesproken moment over te gaan. De implementatiestrategie van Afronden nieuwbouw geeft gemeenten en afnemers meer vrijheid in het te kiezen moment om over te stappen op de nieuwe voorziening en geeft minder inherente druk. De beheerkosten tot en met 2018 zijn voor Verbouw ongeveer € 3 miljoen lager dan Afronden nieuwbouw vanwege voornamelijk het beheer van de migratievoorzieningen (o.a. schaduwdraaien). Naar verwachting zijn toekomstig functionele aanpassingen duurder dan in Afronden nieuwbouw.

Bevindingen

In de brief van 28 oktober 2013 schrijft de Minister van Binnenlandse zaken en Koninkrijksrelaties, de heer R.H.A. Plasterk het volgende: “Uit de resultaten van het onafhankelijke onderzoek van Gartner concludeer ik dat het scenario Afronden nieuwbouw de te verkiezen aanpak biedt om de technische voorzieningen voor de modernisering van de GBA te realiseren. Hierin word ik bevestigd door het advies van de interbestuurlijke stuurgroep mGBA (met vertegenwoordigers van gemeenten en uitvoeringsorganisaties). De stuurgroep adviseert mij namelijk om de modernisering te vervolgen volgens het scenario Afronden nieuwbouw, met migratie van de GBA-V naar de nieuwe BRP. Dit scenario resulteert volgens de stuurgroep ten opzichte van het andere scenario (Verbouw) uiteindelijk in een betere gegevenskwaliteit en de te realiseren voorzieningen zijn later makkelijker aan te passen aan nieuwe eisen. Dat is belangrijk om lopende en toekomstige ontwikkelingen in te kunnen passen zonder dat dit telkens tot lang lopende en kostbare wijzigingsprojecten leidt. Het scenario biedt gebruikers (gemeenten en uitvoeringsorganisaties) tevens grotere flexibiliteit in het tempo waarin zij aansluiten op de nieuwe voorziening (hier wijst Gartner in zijn rapportage ook op). De interbestuurlijke stuurgroep wijst me er in zijn advies verder op dat de kosten die gemaakt moeten worden om de modernisering af te ronden, geen doorslaggevende factor zijn waarop de scenario’s zich van elkaar onderscheiden”.

5.7.1

Terugblik op de scenario’s van 2009

In december 2008 is er een rapportage uitgebracht betreffende de het project modernisering GBA uitgevoerd door Capgemini N.V. Hierin worden een aantal alternatieve benaderingen voor het voortzetten van de modernisering van de Gemeentelijke Basisadministratie voor persoonsgegevens geanalyseerd en doorgerekend. Het programma Modernisering GBA heeft drie scenario’s geformuleerd die zijn opgebouwd uit vier componenten. Kort samengevat kunnen de componenten van de modernisering als volgt worden beschreven: 1. Full Service: De afnemers vragen nu selecties op en ontvangen spontane mutaties vanuit de decentrale systemen van de gemeenten via het GBA-netwerk. GBA-V Full service houdt in dat deze selecties en mutaties voortaan vanuit één punt, namelijk het centrale GBA-V aan de afnemers worden geleverd. Dit scheidt het berichtenverkeer tussen gemeenten onderling en GBA-V enerzijds van het berichtenverkeer naar afnemers anderzijds; 2. Moderne Interfaces: Het bijhouden van de centrale GBA-V kopie, spontane mutaties naar afnemers en intergemeentelijk berichtenverkeer zijn nu niet real time. Moderne interfaces betekent vervanging van het GBA-netwerk door berichtenverkeer volgens de OSB specificaties en maakt real time berichtenverkeer mogelijk. Hiertoe dienen de gemeentelijke burgerzaken systemen te worden aangepast of vervangen en dient GBA-V te worden uitgebreid met een berichtenmakelaar;

67

3. Burgerzakensysteem-kern: De implementatie van een BZS-K houdt in dat alle gemeenten een centraal ontwikkelde uniforme kernapplicatie gaan toepassen voor het opzoeken, wijzigen en opslaan, van persoonsgegevens t.b.v. burgers en binnengemeentelijke afdelingen in dienstverlenende processen. Deze wordt lokaal geïnstalleerd voor gebruik door de gemeenten. BZS-K omvat alleen de basisfuncties en lokale gegevensopslag en vereist Aanvullende Modules die de gebruikersinterface, workflow en verdere burgerzakenfunctionaliteit omvatten en geheel onder verantwoordelijkheid van de gemeenten door marktpartijen geleverd moeten worden. De huidige burgerzakensystemen worden vervangen door een BZS-K met een of meer Aanvullende Modules; 4. Logisch Ontwerp (LO) 4.0: Het LO (Logisch Ontwerp) specificeert o.a. de eisen die worden gesteld aan een gegevensset (gegevenswoordenboek) en het gegevensmodel van het burgerzaken systeem. Momenteel wordt LO3 gebruikt waarop via wijzigingsprocedures steeds aanvullingen worden gedaan. LO4 impliceert de vervanging van LO3 door een geheel nieuw gegevensmodel. De scenario’s zijn opgebouwd uit combinaties van deze vier componenten, zoals in onderstaande figuur wordt weergegeven:

Er is op dat moment besloten door de Minister van Binnenlandse Zaken om te kiezen voor scenario 2 voor de voortgang van het project mGBA. Ik ben het eens met de beslissing die de Minister op dat moment heeft gemaakt en wel om de volgende redenen: Financieel Het kiezen voor scenario 3 is geen optie. Dit scenario heeft een negatieve Netto Contante Waarde en zal dus nooit opbrengsten genereren. Er zullen alleen kosten worden gemaakt zonder dat hierbij uiteindelijk een voordeel behaald zal gaan worden voor de diverse stakeholders. Scenario 1 en 2 zijn beide een optie. Beide hebben een positieve Netto Contante Waarde. Dit houdt in dat beide scenario’s opbrengsten gaan genereren. Het verschil tussen deze twee scenario’s betreft de hoogte van de Netto Contante Waarde en de terugverdientijd. Dit wordt veroorzaakt door het verschil in omvang van beide scenario’s. Scenario 2 is het meest uitgebreide scenario wat beschreven is. Dit scenario heeft ook de hoogste Netto Contante Waarde, te weten € 169.319k. Wel dient hierbij opgemerkt te worden dat de terugverdientijd wel aanzienlijk langer is dan bij scenario 1 (6 i.p.v. 3 jaar). Het zal dus langer duren voordat er opbrengsten worden gegenereerd.

68

Centralisatie Een ander groot voordeel van scenario 2 is dat systematische verstrekkingen vanuit één punt, namelijk het centrale GBA-V aan afnemers worden geleverd en dat het berichtenverkeer real time via de OSB verloopt. Uniformiteit Alle gemeenten aangesloten bij het project vervangen het huidige burgerzakensysteem door een uniform BZS-K. Daarnaast kunnen er door marktpartijen aanvullende modules worden geleverd die communiceren met het uniforme BZS-K. Daarnaast is het gegevensmodel na afronding van de migratie zowel in de gemeenten, in GBA-V als in berichtenverkeer naar afnemers gebaseerd op het LO4 gegevensmodel. Er is dus één format voor de uitwisselingen van informatie.

5.7.2

Bijstelling van scenario 2 in 2011

In augustus 2011 is er door Capgemini een nieuw rapport uitgebracht met betrekking tot de business case Modernisering GBA. De opdracht die hierbij werd meegegeven was het toetsen van het gekozen scenario met voortschrijdende inzichten. Capgemini heeft hierbij het advies gegeven om aanpassingen door te voeren. Het in het vorige scenario genoemde LO4 heet in de huidige situatie LO BRP. Dit LO BRP verschilt van het oorspronkelijke LO4 door de grotere mate waarin dit relationeel opgesteld is. De aanvullende modules heten nu burgerzaken modules. De wijzigingen binnen het programma in de afgelopen periode leiden in feite dus tot een nieuw scenario. Ik ben het eens met het aanpassen van LO4 naar LO BRP. Doordat er steeds meer modules worden bijgevoegd is het aan te raden om één uniforme taal te hebben om mee te communiceren. Dan is het altijd een feit dat de juiste informatie in alle modules en systemen aanwezig is en dat iedereen met deze zelfde informatie werkt.

5.7.3

Aanpassing projectaanpak naar aanleiding van onderzoek Gartner 2013

In 2013 is er door Gartner een evaluatie uitgevoerd naar het programma van mGBA. De aanpassingen welke zijn voorgesteld in 2011 zijn hierbij tegen het licht gehouden. Hierbij is geconstateerd dat er wederom overschrijdingen aanwezig zijn van zowel planning als budget. Als oplossingsrichting zijn er door BZK een drietal scenario’s geschetst en uitgewerkt. Deze zijn uiteindelijk getoetst door Gartner.

  

Doorgaan op huidige koers; Verbouw: het vermijden van een langdurige periode van twee systemen die naast elkaar gebruikt worden, door het verbouwen van de bestaande technische voorzieningen; Afronden nieuwbouw: vermijdt eveneens het langdurig naast elkaar gebruiken van twee systemen, maar redeneert vanuit het invoegen van de huidige GBA-V in de nieuwe centrale voorzieningen van de basisregistratie personen (BRP). In dit scenario wordt de nieuwbouw van de BRP voortgezet en afgerond, maar met een andere technische oplossing die de periode bekort waarin zowel de oude als de nieuwe voorzieningen gebruikt worden.

Op 28 oktober 2013 is door de Minister van Binnenlandse Zaken en Koninkrijksrelaties gekozen voor de hantering van het scenario ‘Afronden nieuwbouw’. Hoewel dit scenario ca. € 3 miljoen meer kosten met zich meebrengt, ben ik het eens met het besluit van de Minister. Scenario ‘Afronden nieuwbouw’ heeft een aantal voordelen, welke richting de toekomst kostenbesparingen met zich mee kunnen brengen en een betere kwaliteit waarborgen.

69

Daarnaast wordt bij scenario ‘Verbouw’ gekozen voor een implementatie op twee momenten voor alle gemeentes tegelijk. Ik voorzie hierbij veel problemen. Bij het scenario ‘Afronden nieuwbouw’ wordt er gekozen voor een geleidelijke implementatie, waarbij alle gemeentes in een tijdvak van twee jaar over moeten zijn gestapt naar de nieuwe situatie. Wanneer er problemen blijken bij gemeentes in de eerste fase van de termijn van twee jaar, kunnen hiervoor oplossingen worden gezocht waardoor de implementatie bij andere gemeentes zonder problemen kan plaatsvinden.

5.7.4

Analyse gemaakte keuzes

Zoals in het hoofdstuk hiervoor is aangegeven is het project Modernisering mGBA gedurende de looptijd op meerdere momenten herijkt. De minister van Binnenlandse Zaken heeft deze beslissingen onder andere genomen naar aanleiding van reviews van externe partijen. Ik ben het eens met de keuzes die de minister heeft gemaakt. De beslissingen die zijn genomen zijn voornamelijk gericht op de toekomst. Door de gemaakte beslissingen wordt er door alle stakeholders met dezelfde informatie gewerkt en zijn er in de toekomst kosten te besparen. De keuzes van de minister zijn door mij met een tweetal medewerkers van het Ministerie van Binnenlandse Zaken besproken. Michael Bosch is adviseur op het vlak van ICT voor het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties en Floris van Meerten is projectcontroller operatie BRP en voert activiteiten uit voor zowel opdrachtgever als opdrachtnemer. Ik heb met hen gesproken over de voortgang van operatie BRP en over de keuzes die op verschillende momenten gemaakt zijn. Deze worden hieronder toegelicht. In hoofdlijnen is een schets gemaakt van de manier waarop de sturing van operatie BRP (voorheen mGBA) plaats vindt. In 2009 is er een doorstart gemaakt van het project mGBA. Aan de hand van een onderzoek van Capgemini is een scenario gekozen voor de uitvoering van het project. Dit scenario leek op het keuzemoment het beste scenario en staat nu nog steeds als het fundament van het project. Op het moment van uitbrengen van de rapportage is dit scenario gekozen omdat dit scenario voldeed aan alle wensen van de stakeholders en het meest gunstig was op basis van terugverdientijd en Netto Contante waarde. Operatie BRP is meerdere malen herijkt. Door de opdrachtnemer is een planning en een begroting afgegeven. Dit betreft een schatting bij aanvang van het project onder andere gebaseerd op functiepuntentellingen. Het budget is opgedeeld in een tweetal onderdelen:  ontwerp en realisatie;  acceptatie, implementatie en communicatie. Per onderdeel is er een begroting opgesteld. Maandelijks wordt de voortgang beoordeeld en wordt gekeken of de begroting nog steeds reëel is. Dit leidt echter niet iedere keer tot een aanpassing van de begroting. Voor de overheadkosten worden gerekend met een marktconform percentage van 12%. De kosten voor Quality Assurance zijn geraamd op 8% van het totaalbudget. Dit is aangehouden als marktconform. De nadruk ligt op dit moment bij Ontwerp en Realisatie. Dit is de eerste stap die gemaakt moet worden voordat er iets geaccepteerd en geïmplementeerd kan worden. Er wordt gebouwd volgens de scrum-methode. Deze methode kent een start en een eind. Ieder periode heeft een duur van twee weken. Verantwoordelijken geven vooraf aan wat zij in deze twee weken kunnen realiseren. Na iedere periode wordt geanalyseerd of de gestelde opleveringen ook zijn behaald in deze twee weken. Ook worden de werkelijke kosten vergeleken met de begrote kosten en wordt beoordeeld of de forecast moet worden bijgesteld. Mochten de opleveringen niet zijn gehaald,

70

betekent dit niet gelijk dat de overallplanning moet worden aangepast en dat het project vertraging oploopt. Er zijn pieken en dalen aanwezig waardoor eventueel verloren tijd weer ingehaald kan worden in een andere periode. Er vindt constant overleg plaats tussen de stakeholders en de opdrachtnemer. Wanneer er wijzigingen worden doorgevoerd door opdrachtnemer wordt dit gecommuniceerd met de stakeholders. De opdrachtnemer bouwt de centrale database. Iedere stakeholder heeft eigen modules welke communiceren met de centrale database. De modules aanwezig bij de stakeholders worden voor het overgrote deel gebouwd en onderhouden door een aantal gemeentelijke pakketleveranciers. Het is dus van groot belang dat er met deze partijen goed wordt gecommuniceerd. Wanneer de opdrachtnemer klaar is met een onderdeel, is het de bedoeling dat de pakketleveranciers ook de modules hebben aangepast en dat deze communiceren met de centrale database. Naast de interne controles, zoals de Audit Dienst Rijk, welke plaatsvinden op planning en begroting vinden er ook controles plaats door externe partijen, zoals KPMG voor de code Kwaliteit. Ook vinden er controles plaats op de beheersing van Quality Assurance door PBLQ HEC. Bij de controle van de jaarrekening is operatie BRP ook een onderdeel. Er zijn verschillende redenen aanwezig waardoor het project een langere doorlooptijd heeft dan op voorhand gecalculeerd is en dat kosten hoger uitkomen. Onder andere doordat er enkele wijzigingen worden voorgesteld in de scope hebben er aanpassingen plaatsgevonden aan het fundament wat in 2009 is gesteld. Onder andere door deze wijzigingen bevat de planning geen lucht meer. Er is een team aanwezig dat deze wijzigingen moet beoordelen en moet aangeven of deze mee kunnen worden genomen in het project en wat hiervan de kosten zijn. De tijd die het team nodig heeft om de wijzigingen te beoordelen kunnen zij niet besteden aan de uitvoering van het project zelf. Dit heeft impact op het tijdspad van het project. Doordat de centrale database met meerdere modules moet kunnen communiceren wordt er gewerkt met een Logisch Ontwerp. Echter wanneer er in een module aanpassingen worden doorgevoerd, kan dit ook gevolgen hebben voor de centrale database. Hierin moeten dan ook aanpassingen worden doorgevoerd om te kunnen communiceren met de module. Uit het eerste deelonderzoek naar de omvang, voortgang en haalbaarheid van de planning van de modernisering GBA is gebleken dat de vertraging op de ontwikkeling van de BRP-voorziening aanzienlijk is. Daarom is er door Gartner in 2013 een tweede deelonderzoek uitgevoerd. Hierbij is een functiepuntenanalyse gemaakt. Het project is opgedeeld in functiepunten. Aan ieder functiepunt is een bedrag en een termijn gekoppeld. Op basis van deze informatie is een tijdspad uitgestippeld en is er een begroting opgesteld. De begroting komt neer op ca. € 75 miljoen. Deze begroting en planning zijn afgegeven aan de minister en aan de Tweede Kamer en zijn op moment van het gesprek nog steeds actueel. De verwachting is dat Operatie BRP in dit tijdsbestek en voor het begrote bedrag kan worden gerealiseerd. Concluderend geven Michael Bosch en Floris van Meerten aan nauw betrokken te zijn geweest bij de keuzes die de minister heeft gemaakt. Ook lichtten zij toe dat dit niet een beslissing van alleen de minister is geweest, maar dat er vooraf uitgebreid overleg heeft plaatsgevonden met de stakeholders. Het is een gezamenlijke beslissing geweest om het project tussentijds bij te stellen.

71

6 Conclusie en synthese In oktober 2014 is door de commissie Elias een rapportage opgeleverd aan de Tweede Kamer met betrekking tot een zestal ICT-projecten bij de overheid. Eén van deze zes projecten betreft modernisering GBA.

6.1

mGBA conclusies

Onderstaand zijn een viertal conclusies opgenomen vanuit deze rapportage. De bevindingen en conclusies van dit onderzoek zijn volledig in lijn met de conclusies van de commissie Elias. 1. De rijksoverheid heeft haar ICT-projecten niet onder controle De ambities van de rijksoverheid met ICT zijn groot. Het is daarom extra teleurstellend dat zij de besturing en beheersing van projecten met een belangrijke ICT-component niet op orde heeft. Het geheel van ICT-organisaties bij de rijksoverheid is chaotisch en ondoorzichtig. Taken en verantwoordelijkheden zijn versnipperd en onduidelijk. De belangen van de hoofdrolspelers bij ICTprojecten lopen te veel uiteen. De rijksoverheid heeft haar ICT-projecten vaak niet in de hand voor wat betreft de kosten, de tijd of zelfs het eindresultaat. Bovendien is er niemand die het echt voor het zeggen heeft over ICT-projecten. Omdat een financieel overzicht op overkoepelend rijksniveau sinds 1995 niet meer wordt opgesteld, ontbreekt inzicht in ICT-kosten. Niemand weet hoeveel de Nederlandse overheden aan ICT uitgeven. Daarom ook weet niemand hoeveel geld gemoeid is met mislukkingen. Een veilige schatting op grond van informatie van diverse deskundigen komt neer op 1 à 5 miljard euro verspilling per jaar – naar het oordeel van de commissie in alle gevallen een onaanvaardbaar hoog bedrag. De commissie stelt vast dat vooral de cultuur rondom ICT-projecten bij de rijksoverheid niet deugt. Enerzijds is er sprake van ongebreideld ICT-enthousiasme, waarbij ICT als oplossing voor alle vraagstukken wordt gezien. Anderzijds vraagt de Tweede Kamer juist om beleid zonder te beseffen dat ICT vrijwel altijd noodzakelijk is bij de uitvoering. De betrokken bewindspersoon zegt uitvoering van het beleid toe zonder eerst na te gaan of het ICT-technisch haalbaar is. Ambtenaren spreken de politieke leiding te weinig tegen wanneer het parlement wordt toegezegd dat ook onmogelijke eisen zullen worden ingewilligd, of informatie in die richting bereikt de politieke top niet. De departementen vragen vervolgens in aanbestedingen om, wat tijdens de hoorzittingen genoemd werd, “een auto zonder stuur”: zij vragen iets dat niet kán werken. De rijksoverheid negeert vaak de deskundigheid bij ICT-leveranciers, terwijl de ICT-kennis bij de overheid bij lange na niet op het niveau ligt van de leveranciers. De (schaarse) malen dat een leverancier zijn (potentiële) opdrachtgever waarschuwt voor vermijdbare problemen, wordt deze waarschuwing regelmatig niet serieus genomen. De Kamer maakt haar controlerende taak niet waar door een gebrek aan interesse voor ICT en een gebrek aan deskundigheid op ICT-gebied. Bovendien schiet de informatievoorziening van het kabinet aan de Kamer tekort. Dit heeft de commissie zelf aan den lijve ondervonden tijdens haar onderzoek. De rijksoverheid moet ingrijpend en doortastend optreden om haar ICT-projecten onder controle te krijgen. Het totaalpakket aan aanbevelingen van de commissie in dit rapport legt hiervoor de basis. 2. De verantwoordings- en besluitvormingsstructuur bij ICT-projecten is zeer gebrekkig De commissie stelt vast dat de taken, rollen en verantwoordelijkheden bij ICT-projecten van de rijksoverheid te vaak niet vastgelegd, versnipperd en onduidelijk zijn. Bovendien is het onduidelijk wie de leiding heeft in projecten. Deze «gedeelde onverantwoordelijkheid» zorgt ervoor dat de sturing en beheersing van ICT-projecten niet op orde is.

72

De beheersing van ICT-projecten loopt stuk op een marginale betrokkenheid van bestuurders en gebruikers, een gebrek aan lerend vermogen en zelfkritiek, te weinig uitwisseling van gegevens tussen projecten (portfoliomanagement) en een tekort aan informatie binnen projecten, zoals over de omvang van het project of de teambezetting (sturingsinformatie). De commissie stoort zich in het bijzonder aan dit laatste punt. Het verloop van ICT-projecten is immers beter te voorspellen dan vaak wordt gedacht. ICT-projecten kennen veel wetmatigheden. Zo mislukken bijvoorbeeld grote projecten significant vaker dan kleine, en kan het inzetten van meer personeel bij een project juist leiden tot een lagere productiviteit. Sturing op deze wetmatigheden kan mislukkingen voorkomen. Zo zou je bijvoorbeeld een groot project kunnen opknippen in kleinere, minder risicovolle deelprojecten. Het ontdekken van wetmatigheden kan daarom het lerend vermogen van de rijksoverheid vergroten. Hiervoor is wel meer sturingsinformatie nodig dan er nu is; binnen de projecten is dit vaak niet op orde. Bovendien zijn de hoeveelheid, kwaliteit en presentatie van openbare gegevens over ICT-projecten – zoals verzameld bij de Jaarrapportage Bedrijfsvoering Rijk en vooral bij het Rijks ICT-dashboard – nu onvoldoende. 3. De rijksoverheid heeft onvoldoende inzicht in de kosten en baten van haar ICT De commissie constateert dat veel problemen ontstaan aan het begin van ICT-projecten. Veel geplande projecten willen het onmogelijke voor elkaar krijgen. Projecten zijn te groot en te complex, terwijl juist deze grote projecten statistisch gezien vaker mislukken. Bovendien ontbreekt een goede zakelijke rechtvaardiging bij veel ICT-projecten. De rechtvaardiging wordt te veel gezien als een formaliteit, een manier om goedkeuring te krijgen om geld uit te geven, waarna het document in een la verdwijnt. «Businesscase, klaar is Kees», werd een gevleugelde uitdrukking bij de hoorzittingen. Het is juist belangrijk dat ook tijdens de uitvoering van een project de zakelijke rechtvaardiging van tijd tot tijd opnieuw bekeken wordt en vooral ook bijgewerkt. Het staat voor de commissie onomstotelijk vast dat op tijd stoppen met projecten essentieel is voor de beheersing van ICT-projecten van de rijksoverheid. Op dit moment zien opdrachtgevers te vaak niet op tijd dat een project dreigt te mislukken. Door een realistische en actuele zakelijke rechtvaardiging steeds opnieuw te beoordelen kan de schade worden beperkt. Alleen met een goede onderbouwing kan de juiste beslissing genomen worden over het stoppen of doorgaan met een project. Het valt zeer te betreuren dat er bij de rijksoverheid geen totaaloverzicht bestaat van de kosten van ICT-projecten, laat staan van het beheer en onderhoud van ICT-systemen. Deze kosten worden nu op te veel verschillende manieren berekend en bijgehouden. Het steekt de commissie dat kabinetten er tot 1995 wel in slaagden een bruikbaar totaaloverzicht te maken. En het is des te pijnlijker dat de Kamer onvoldoende actie heeft ondernomen toen de toenmalig Staatssecretaris van Binnenlandse Zaken in 1995 aankondigde om dit overzicht wegens «gebrek aan praktisch nut» niet meer te maken. 4. Het ICT-projectmanagement is zwak De organisatiestructuur en -processen binnen projecten (het projectmanagement) zijn niet op orde. Er wordt te weinig deskundig personeel ingezet en het is onduidelijk wie waarvoor verantwoordelijk is. Vaak wordt er niet genoeg nagedacht over beheersaspecten als tijd, geld, kwaliteit en reikwijdte. Algemeen bekende procedures om projecten te besturen worden wel gebruikt, maar niet goed of alleen gedeeltelijk toegepast. Zo is het risicomanagement bij de rijksoverheid onder de maat en zijn opdrachtgevers onvoldoende betrokken. Bovendien worden de belangen van de eindgebruiker in veel projecten helemaal vergeten. Daarnaast hebben niet alle medewerkers van een ICT-project dezelfde informatie. Wat uitvoerders van ICT-projecten zoals programmeurs en testers weten, komt vaak niet terecht bij de andere belanghebbenden (in het bijzonder de ambtelijke top en bestuurders). Door een gebrek aan kennis hebben bestuurders buiten de projectmanagementorganisatie onrealistische verwachtingen over doorlooptijd, budget en kwaliteit van een project. Zij zijn daardoor niet in staat om voortgang en risico’s

73

goed in te schatten en zo nodig bij te sturen. Zo blijkt uit de hoorzittingen dat de uitvoerders dit wel weten, maar de beslissers nogal eens voorspiegelen wat zij denken dat dezen willen horen.

6.2

Weerspiegeling met theorie

Vanuit de literatuur is een aantal theoretische concepten naar voren gekomen waarin de risico’s een repeterend karakter hebben. Zo blijkt dat de meeste bedrijven een beperkte effectiviteit hebben in het managen van projecten (Cicmil, 1999). 75%-80% van de gestarte projecten mislukt (Rosacker en Olson, 2008; Ward et al., 2007; Boersma et al., 2007; Ives, 2005; Drummond en Hodgson, 2003; Cozijnsen et al., 2000; Prakken, 1997). Projecten worden gestart om een vooraf gedefinieerd doel te behalen. Deze projecten zijn ontworpen op basis van aannames met betrekking tot menselijk, organisatorisch en technisch gedrag. Het tussentijds aanpassen van het project kan als gevolg hebben dat planningen en budgetten niet worden gehaald, maar erger nog dat het gehele project faalt. Projectfalen is meestal niet terug te leiden naar een enkele faalfactor, maar naar een combinatie van factoren die, verspreid in de tijd, projectfalen tot gevolg hebben (Ives, 2005; Ivory en Alderman, 2005; Drummond en Hodgson, 2003). Dit wordt onderbouwd door de onderzoeken die zijn uitgevoerd door de Standish Group. Uit het onderzoek wat de Standish Group heeft verricht in 2012 is gebleken dat 39% van alle projecten succesvol is afgerond. Dit houdt in dat het project tijdig is opgeleverd, binnen budget is gerealiseerd en alle functionaliteiten heeft zoals vereist. 43% van de projecten zijn afgerond, echter niet binnen de gestelde tijd, het budget of er ontbreken functionaliteiten. De projecten behorende bij de laatste 18% zijn gefaald. Deze cijfers vertegenwoordigen een stijging in de succespercentages van de vorige onderzoeken, en een daling van het aantal mislukkingen. Het dieptepunt in de laatste vijf onderzoeken was 2004, waarin slechts 29% van de projecten succesvol was. Ook is inzichtelijk gemaakt op welk vlak de projecten worden overschreden. Het bepalen van de relatie van projectoverschrijdingen tot geleverde functies is een analytisch proces. Uit de cijfers van 2012 blijkt een lichte stijging van zowel de overschrijdingen met betrekking tot de kosten en tijd. Kostenoverschrijdingen zijn gestegen van 56% in 2004 naar 59% in 2012. Tijdsoverschrijdingen zijn ook gestegen, namelijk van 71% in 2010 naar 74% in 2012. Het hoogtepunt in de overschrijdingen met betrekking tot tijd was in 2004 (84%). Ontwikkelde functies welke op voorhand vereist waren daalden van 74% in 2010 tot 69% in 2012. Organisaties zelf hebben vooral moeite met de beschikbaarheid en de juiste skills en ervaring van de teamleden. Maar ook governance, een duidelijke verdeling van taken, verantwoordelijkheden en bevoegdheden, ervaring bij de uitvoering van projecten en het kunnen omgaan met veranderingen zijn struikelblokken die uit de theorie blijken (Elonen & Artto, 2003; Reyck et al., 2005; Jonas, 2010; Frey & Buxmann, 2012). Ook moet er te allen tijde rekening worden gehouden met de invloed welke de politiek kan uitoefenen door het wijzigen van aan wet- en regelgeving of het niet tijdig nakomen van (politieke) doelstellingen(Algemene Rekenkamer, 2007; ISACA, 2009). Wanneer er tijdens het project vaak wisselingen plaatsvinden van teamleden betreft dit een risico voor het succesvol afronden van het project (McFarlan, Elonen (1981) & Artto, Jeffry & Leliveld (2004)). Vanuit de individuele IT-projectportfoliocomponenten betreffen het falen van individuele IT-projecten of IT-programma’s door het niet opleveren van resultaten binnen de gestelde tijd, budget en kwaliteit (Drake en Byrd (2006), Jeffery en Leliveld (2004), Benko en McFarlan (2003) en Kumar, Ajjan en Niu (2008).

74

7 Beantwoording onderzoeksvragen In dit hoofdstuk worden de onderzoeksvragen beantwoord, beginnend met de deelvragen (paragraaf 7.1) en vervolgens de centrale onderzoeksvraag (paragraaf 7.2).

7.1

Deelvragen

Deelvraag 1: Wat wordt verstaan onder de term portfoliomanagement en welke audit instrumenten gericht op risicobeheersing worden toegepast om zekerheid te verschaffen bij een project? Portfoliomanagement zorgt voor samenhang tussen ICT-projecten en is daarmee een cruciaal onderdeel van een goede beheersstructuur. Simpeler gezegd: de organisatie houdt overzicht over wat er allemaal is en wat er nog in de pijplijn zit en kan op basis hiervan besluiten wat prioriteit heeft, wat kan wachten of wat echt hobbyisme is. En door zo nu en dan terug te blikken op besluiten en projecten, kan zij leren. Portfoliomanagement is onderdeel van een goede beheersstructuur om de besluitvorming rondom ICT-projecten in de organisatie optimaal te organiseren. Het is een middel om grip te krijgen op projecten. Een projectleider of projectverantwoordelijke wil en moet het overzicht houden op alle ICTprojecten. Bij portfoliomanagement worden planning, beschikbare mensen, beschikbare middelen en andere afhankelijkheden optimaal gebalanceerd. Dit met als doel dat het totaal aan projecten maximale waarde toevoegt aan de strategische doelstellingen van een organisatie. Organisaties denken (idealiter) vanuit een strategie. Om de strategie te doen slagen zal de organisatie iets moeten doen, een unieke verandering moeten doormaken. Hiervoor staan schaarse middelen ter beschikking. Portfoliomanagement is de discipline die ervoor zorgt dat de strategie op een beheerste wijze wordt gerealiseerd. Vanuit de literatuur blijken er een aantal risico’s een repeterend karakter te hebben. De volgende risico’s worden veelvuldig benoemd:      

Risico’s vanuit de organisatie, haar governance en omgeving. Risico’s vanuit personele capaciteit en competenties. Risico’s vanuit processen en de uitvoering van IT-projectportfoliomanagement. Risico’s vanuit de samenstelling van de IT-projectportfolio als geheel. Risico’s vanuit de individuele IT-projectportfoliocomponenten. Risico’s vanuit afhankelijkheden en relaties van de IT-projectportfoliocomponenten.

In het kort komt het er op neer dat er te weinig aandacht wordt besteed aan het vooraf definiëren van een project. Voor het succesvol uitvoeren van een project dient het project toegevoegde waarde te bieden voor de organisatie en in lijn te liggen met de toekomstige strategie van de organisatie. Tevens dient er goed gekeken te worden of de personele capaciteit en competenties aanwezig zijn voor het verdelen van taken en verantwoordelijkheden. Om deze risico’s te mitigeren dient er op een gestructureerde manier gestart te worden met een project. Hiervoor kan er gebruik worden gemaakt van een auditinstrument. Door gebruik te maken van een auditinstrument wordt afgedwongen dat er van te voren goed wordt nagedacht over het project. Een auditinstrument dwingt af dat er wordt nagedacht over de kosten, de planning en personen die benodigd zijn voor de uitvoering van het project.

75

Er zijn verschillende auditinstrumenten waarmee een project meer gestructureerd zal verlopen. In 2008 is het CIO-stelsel geïntroduceerd bij de overheid. Het doel hiervan is om de beheersstructuur te verbeteren. Deze aanpak heeft goede dingen bereikt, maar de CIO’s en de CIO Rijk geven nog te weinig prioriteit aan de beheersing van de ICT-projecten. Veel CIO’s zijn te veel bezig met de ICTondersteuning van de bedrijfsvoering en te weinig met de ICT-projecten in het beleids-domein. De CIO Rijk heeft per definitie te weinig doorzettingsmacht om in te grijpen bij projecten die uit de hand lopen. Naast het CIO-stelsel dat wordt gebruikt bij de Nederlandse overheid, worden in het bedrijfsleven vele verschillende soorten auditinstrumenten gebruikt. In totaal gebruikt 85% van de ondervraagde organisaties in 2012 een auditinstrument. De meeste gehanteerde auditinstrumenten volgens onderzoek van KPMG zijn:  MSP  Prince2  Een eigen ontwikkelde variant Deelvraag 2: In hoeverre overschrijden complexe projecten vaak de begroting, op welke wijze is dit bij toekomstige projecten te voorkomen door gebruik te maken van een (ander) audit instrument? Wanneer er wordt gekeken in 2007 naar projecten van de Nederlandse overheid dan wordt door de Algemene Rekenkamer opgemerkt dat diverse overheidsprojecten in de problemen zijn geraakt. Grote projecten overschrijden planning en begroting met jaren en miljoenen euro’s. Uit een onderzoek van White en Fortune in 2002 is naar voren gekomen welke eisen projectleiders stellen aan een geslaagd project. Een geslaagd project:       

voldoet aan de gebruikerseisen; is afgerond binnen de gestelde tijd; is afgerond binnen het beschikbare budget; voldoet aan de organisatiedoelen; heeft toegevoegde waarde voor de organisatie; heeft minimale bedrijfsverstoringen opgeleverd; voldoet aan kwaliteitsstandaarden.

Door onderzoeksbureaus zoals de Standish Group wordt onderzoek gedaan naar het slagen van projecten. Uit een onderzoek van 2013 is gebleken dat 39% van alle projecten succesvol is afgerond. 43% van de projecten zijn afgerond, echter niet binnen de gestelde tijd, het budget of er ontbreken functionaliteiten. De projecten behorende bij de laatste 18% zijn gefaald. Van de onderzochte projecten is in 74% van de projecten de tijdsplanning overschreden en in 59% de begroting. Uit een onderzoek uitgevoerd door de commissie Elias in 2014 blijkt dat de verantwoording- en besluitvormingsstructuur rondom ICT-projecten bij de Nederlandse overheid is niet op orde. Het is te vaak onduidelijk waar verantwoordelijkheden liggen. Even veelvuldig komt het voor dat de verantwoordelijkheden zijn versnipperd. De commissie spreekt hier van gedeelde onverantwoordelijkheid met als gevolg dat beslissingen binnen projecten niet of te laat worden genomen. De commissie Elias heeft een aantal aanbevelingen geformuleerd. Deze aanbevelingen zijn opgenomen in de bijlage. Er zijn verschillende meningen over de toegevoegde waarde van het hanteren van een auditinstrument. Uit tientallen onderzoeken blijkt dat het hanteren van een auditinstrument niet hoeft

76

bij te dragen aan het succesvol afronden van een project. Zo wijst onderzoek in een periode van tien jaar (1996-2006) uit dat er een toename is van 28% van het hanteren van een auditinstrument door organisaties. Wanneer er wordt gekeken naar de succesfactor van deze projecten komt naar voren dat slechts 1% van de projecten succesvoller is afgerond. (Ward et al. 2007). Wanneer er naar overheidsprojecten wordt gekeken kan er worden gesteld dat begrotingen vaak worden overschreden. Onderstaand is een overzicht opgenomen van vijf overheidsprojecten welke de raming van kosten en doorlooptijd hebben overschreden. En dit is slecht een klein deel van alle overheidsprojecten welke niet binnen de begroting en planning zijn gerealiseerd. Project

Raming

Realisatie of prognose

C2000 Walvis NVIS SUB Toeslagen

598 360 12 129 77

793 (2 jaar later) 367 (realisatiedatum nog niet bekend) 24 (2,5 jaar later) 202 (realisatiedatum nog niet bekend) 275 (2 jaar)

Tabel 1: Raming en (geplande) realisatie projectkosten (bedragen x € 1 miljoen)

Door de commissie Elias wordt aanbevolen dat er meer structuur moet worden aangebracht in de uitvoering van een project en dat het duidelijk moet zijn hoe de besluitvorming moet plaatsvinden en wie hiervoor de juiste personen zijn. Door gebruik te maken van een auditinstrument kan dit inzichtelijk worden ingeregeld. Deelvraag 3: Op welke wijze kan vanuit het perspectief van IT-auditing zekerheid worden verschaft over de financiële sturing van projecten? De wijze van financiële sturing van ICT projecten is complex omdat er twee soorten sturing zijn die elkaar kunnen beïnvloeden. De eerste soort betreft het reguliere begrotingsproces. Hieronder wordt verstaan dat kosten inzichtelijk worden gemaakt voor de looptijd van het gehele project. Deze kosten moeten worden goedgekeurd door het management. De tweede soort sturing betreft een project of programma waarbij de financiële aspecten nog onzeker zijn in de beginfase van het project of programma. De helderheid in de eerste soort en de onzekerheden in het tweede soort, moeten zo goed mogelijk met elkaar worden samengevoegd. Het eerste soort begrotingsproces betreft vaak alleen de uitgaven op kasbasis voor de korte termijn terwijl de ramingen voor een project of programma een veel langere termijn zullen betreffen. Een goed ingericht portfoliomanagement is nodig om binnen een organisatie het overzicht te blijven bewaken over alle lopende projecten en programma’s in relatie tot het begrotingsproces. Wanneer er sprake is van een helder portfoliomanagement is tussentijdse sturing ook eenvoudiger. Om vast te stellen of een project ook baten gaat genereren zijn er een aantal financiële investeringsmodellen aanwezig. Met deze modellen kan een inschatting worden gemaakt of het project zich zelf terugverdient of eventuele baten gaat genereren in de toekomst. Echter is dit voor ICT projecten lastig om vast te stellen omdat ICT voornamelijk ondersteunend van aard is. Er worden vaak geen opbrengsten mee gegenereerd maar enkel kosten bespaard. De meest gebruikte financiële investeringsmodellen wereldwijd zijn:  Terugverdienperiode  Interne rentabiliteit  Netto Contante Waarde.

77

De terugverdienperiode is de meest eenvoudige methode. Hieronder wordt verstaan de tijd die nodig is om de initiële gemaakte kosten voor de investering in projecten te dekken (terug te verdienen) met de kasstromen die het project genereert. Als de terugverdienperiode als beoordelingscriterium wordt gebruikt, wordt de gevonden terugverdienperiode afgezet tegen de door de leiding van de organisatie verlangde terugverdienperiode. Bij een terugverdienperiode welke lager is dan de verlangde terugverdienperiode zal het project worden geaccepteerd. Als de leiding van een organisatie een keuze moet maken tussen twee elkaar uitsluitende projecten, zal het project met de kortste terugverdienperiode worden gekozen. De netto contante waarde methode en de methode van de interne rentabiliteit zijn gebaseerd op dezelfde gedachte. Gegeven een disconteringsvoet k worden bij de netto contante waarde methode de toekomstige vrije kasstromen contant gemaakt naar tijdstip t = 0 en vergeleken met het investeringsbedrag op dat tijdstip. Is de contante waarde van de toekomstige kasstromen groter dan het investeringsbedrag (netto contante waarde > 0), dan komt het desbetreffende project voor uitvoering in aanmerking. Bij de interne rentabiliteit daarentegen zoekt men juist die disconteringsvoet die de contant gemaakte kasstromen gelijk doet zijn aan het investeringsbedrag. In de volgende vergelijking zijn de kasstromen voor elke periode t en het investeringsbedrag gegeven. Onbekend zijn derhalve de netto contante waarde netto contante waarde en de disconteringsvoet k Hoewel de netto contante waarde methode en de interne rentabiliteit op dezelfde grondgedachte zijn gebaseerd, kunnen bij de selectie van elkaar uitsluitende projecten tussen deze twee methoden verschillen ontstaan in de voorkeursordening van de desbetreffende projecten. Deze verschillen in voorkeursordening kunnen ontstaan wanneer voor de projecten in kwestie er een ongelijkheid bestaat wat betreft:  investeringsbedrag;  looptijd;  verdeling van de kasstromen. Het overgrote deel van de kosten is in te schatten voor de start van het project. Er zal worden gekeken wat de benodigde mensen en middelen zijn voor het succesvol uitvoeren van het project. Ook zal er een inschatting worden gemaakt van de benodigde uren. Wanneer het projectplan gevolgd gaat worden zal de begroting in lijn moeten liggen met de uiteindelijke kosten. Een IT-auditor met ervaring omtrent het uitvoeren, monitoren en auditen van projecten zal hierover een uitspraak kunnen doen inzake de haalbaarheid. Echter wanneer er tussentijds wijzigingen worden doorgevoerd aan het project, is het oordeel van de IT-auditor niet meer bruikbaar. Wanneer projecten tussentijds worden bijgesteld zal het gehele project opnieuw moeten worden bekeken om een nieuwe inschatting te maken van kosten en planning. Generieke beheersmodellen zoals Prince2, MSP en Cobit gecombineerd met financiële instrumenten zoals Netto Contante Waarde en Terugverdientijd vormen een nagenoeg sluitend raamwerk voor beheersing.

7.2

Centrale onderzoeksvraag

In deze paragraaf wordt de beantwoording van de onderzoeksvragen afgerond met beantwoording van de centrale onderzoeksvraag: Op welke wijze kan vanuit het perspectief van IT-auditing enige mate van zekerheid worden verschaft over de financiële sturing van projecten en welke audit instrumenten kunnen hierbij gehanteerd worden?

78

In de praktijk gaan investeringen in projecten meestal gepaard met een grote mate van onzekerheid omtrent het technisch welslagen, het succes van de commerciële introductie, de totale kosten of de totale duur van het project. Gelukkig is een organisatie meestal enigszins flexibel bij het ontwerpen en uitvoeren van grote projecten. Projecten kunnen tussentijds worden stopgezet, uitgebreid, vertraagd, versneld, uitgesteld of worden gewijzigd. Er zijn verschillende auditinstrumenten waarmee een project meer gestructureerd zal verlopen. Een audit instrument verplicht een organisatie om vooraf goed na te denken over het project en wat hierbij komt kijken. Er zijn veel verschillende auditinstrumenten bekend over de hele wereld. De meeste gehanteerde auditinstrumenten wereldwijd betreffen Prince2 en PMBOK. Uit onderzoek blijkt dat in Nederland vaak de volgende auditinstrumenten gehanteerd:  MSP;  Prince2;  PMBOK;  Scrum;  Een eigen ontwikkelde variant. De eigen ontwikkelde varianten hebben vaak wel een basis van één van de bovenstaande auditinstrumenten. Zo wordt er bijvoorbeeld gesproken over Prince2 Light. Een onderdeel van een auditinstrument betreffen de kosten. De wijze van financiële sturing van ICT projecten is complex omdat er twee soorten sturing zijn die elkaar kunnen beïnvloeden. De eerste soort betreft het reguliere begrotingsproces. Hieronder wordt verstaan dat kosten inzichtelijk worden gemaakt voor de looptijd van het gehele project. Deze kosten moeten worden goedgekeurd door het management. De tweede soort sturing betreft een project of programma waarbij de financiële aspecten nog onzeker zijn in de beginfase van het project of programma. De helderheid in de eerste soort en de onzekerheden in het tweede soort, moeten zo goed mogelijk met elkaar worden samengevoegd. Veel gehanteerde financiële instrumenten zijn de volgende:  Gemiddelde boekhoudkundige rentabiliteit;  Terugverdienperiode;  Netto contante waarde;  Interne rentabiliteit. Een IT-auditor kan enige vorm van zekerheid verschaffen wanneer er een duidelijk en goed uitgeschreven plan is opgesteld door de organisatie. Dit plan dient een reële begroting en planning te bevatten. Door het hanteren van een auditinstrument wordt gestructureerd gewerkt en worden er meetmomenten ingebouwd. Met deze meetmomenten kan er tussentijdse (bij)sturing plaatsvinden van het project. Een IT-auditor die ervaring heeft bij het uitvoeren of ondersteunen van projecten kan beoordelen of de planning en begroting zoals deze zijn opgesteld een reëel beeld vormen. Daarnaast dient er nagegaan te worden, wanneer er gebruik wordt gemaakt van medewerkers van de organisatie zelf, of deze voldoende zijn opgeleid en gemotiveerd zijn om het project uit te voeren. De IT-auditor kan door het afnemen van interviews een beeld krijgen van de vaardigheden van medewerkers. Het oordeel van de IT-auditor komt te vervallen om het moment dat het project tussentijds wordt aangepast. Deze aanpassingen hebben vaak direct invloed op de begroting en planning.

79

Literatuurlijst Algemene Rekenkamer, (2007). Lessen uit ICT-projecten bij de overheid deel A. 29 november 2007. Algemene Rekenkamer, (2008). Lessen uit ICT-projecten bij de overheid deel B. 1 juli 2008. Anantatmula V.S (2008), The role of technology in the project manager performance model, Project Management Journal, Vol. 39, Project Management Institute. Baardman E, Bakker G, Beijnhem van J, Brave F, Coesmans P, Hombergen R, Leeuwen van H, Moussault A en Vinken R (2006), Wegwijzer voor methoden bij projectmanagement, van Haren publishing, Zaltbommel. Belassi W en Tukel O (1996), A new framework for determining critical success/failure factors in projects, International Journal of Project Management, Vol. 14, No. 3, Elsevier Science Ltd and IPMA, Great Britain. Benko C., & McFarlan, F.W., (2003). Connecting the Dots. Harvard Business School Press. Berghout E., Renkema T. (2005). Investeringsbeoordeling van IT-projecten, Information Management Institute B.V. Boersma K, Kingma S.F en Veenswijk M (2007), Paradoxes of control: The (electronic) monitoring and reporting system of the Dutch high speed alliance (HAS), Project Management Journal, Vol. 38, Project Management Institute. Bureau Gateway (2011), Gateway™ Review data: 15 tm 19 augustus Bureau Gateway (2010), Gateway™ Review data: 19 april t/m 23 april 2010 Capgemini (2008), Business Case Modernisering, Capgemini N.V. Capgemini (2009), Een moderne GBA mogelijk gemaakt…, Capgemini N.V. Capgemini (2011), Rapportage Toetsing en Bijstelling Business Case Modernisering GBA, Capgemini Consulting. Cicmil S (1999), An insight into management of organisational change projects, Journal of Workplace Learning, Vol. 11, No. 1, MCB University Press. Cicmil S.J.K (1997), Critical factors of effective project management, The TQM Magazine, Vol. 9, No. 6, MCB University Press. Cooper, R., Edgett, S., Kleinschmidt, E., (1999). New Product Portfolio Management: Practices and Performance. Journal of Product Innovation Management. Vol.16:333-351. Cozijnsen A.J, Vrakking W.J en van IJzerloo M (2000), Success and failure of 50 innovation projects in Dutch companies, European Journal of Innovation Management Vol. 3, No. 3, MCB University Press. Dey P.S (2002), Benchmarking project management of Caribbean organizations using analytic hierarchy process, Benchmarking: An international Journal, Vol. 9, No. 4, MCB University Press. Drake, J.R., & Byrd, T.A., (2006). Risk in Information Technology Project Portfolio Management. Journal of Information Technology Theory and Application, 8:3, 2006. Drummond H en Hodgson J (2003), The chimpanzees' tea party: a new metaphor for project managers, Journal of Information Technology, Vol. 18, No. 3, The Association for Information Technology Trust. Dvir D, Sadeh A en Malach-Pines A (2006), Projects and project managers: The relationship between project manager’s personality, project types, and project success, Project Management Journal, Vol. 37, Project Management Institute. Elonen, S., & Artto, K.A., (2003). From Experience: Problems in managing internal development projects in multi-project environments. International Journal of Project Management 21 pp. 395–402. Ernst & Young (2008), Resultaten ICT Barometer over ICT-projecten, Ernst & Young, Jaargang 8, Amsterdam. Ernst & Young (2010), Resultaten ICT Barometer over ICT-projecten, Ernst & Young, Jaargang 10, Amsterdam.

80

Frey, Th., & Buxmann, P., (2012). IT Project Portfolio Management – A Structured Literature Review. European Conference of Information Systems (ECIS) 2012 Proceedings, paper 167. Gartner Consulting (2013), Evaluatie scenario’s eindrapportage, Gartner Consulting. Gitman L.J. (2004), Principes van financieel management, Pearson Benelux B.V. Harpham, A. (2002). Successful Programme Management or Managing Successful Programmes. In 16th IPMA World Congress, Berlin. June. Harpum, P., (2007). Project Control. In Morris en Pinto 2007b, pp. 1-25. Hedeman, B., H. Fredriksz en G.Vis van Heemst. (2009). Projectmanagement op basis van PRINCE2 Editie 2009. Van Haren Publishing. Heemstra, F.J., Kusters, R.J., Nijhuis, R., & Rijn, Th.M.J. van (1997). Dealing with risk: beyond gut feeling - an approach to risk management in software engineering. Eindhoven 1997. Herst, A.C.C., S.J.E.W. Poirters & J.G.E. Spekreijse, ‘De investeringsbeslissing: theorie en praktijk’, Tijdschrift voor Bedrijfsadministratie, 102, maart, p. 70-77, 1998. Horngren C.T., Datar S.M., Foster G (2003), Cost Accounting, Eleventh edition, p 727. Information System Audit and Control Association, (2009). The Risk IT Framework. Information Systems Audit and Control Association (ISACA). Ives M (2005), Identifying the contextual elements of project management within organizations and their impact on project success, Project Management Journal, Vol. 36, Project Management Institute. Ivory C en Alderman N (2005), Can project management learn anything from studies of failure in complex systems, Project Management Journal, Vol. 36, Project Management Institute Jeffery, M. & Leliveld, I., (2004). Best Practices in IT Portfolio Management. MIT Sloan Management review. Vol.45 No.3. Jonas, D., (2010). Empowering project portfolio managers: How management involvement impacts project portfolio management performance. International Journal of Project Management 28, pp. 818-831. KPMG (2012). Project- en programmamanagement survey 2012, KPMG Advisory N.V. Kumar, R., Ajjan, H., & Niu, Y., (2008). Information Technology Portfolio Management: Literature Review, Framework and Research Issues. Information Resources Management Journal, Volume 21, Issue 3 pp. 64-87. Kuruppuarachchi P.R, Mandal P en Smith R (2002), IT Project implementation strategies for effective changes: A critical review, Logistics information management, Vol. 5, No. 2, MCB University Press. Kwak L.S., (2011). Gateway review: een vorm van IT-(project) auditing?, de IT-Auditor nummer 3. Lehtonen P en Martinsuo M (2006), Three ways to fail in project management and the role of project management methodology, Project Perspectives, Annual Publication of International Project Management Association, Vol. XXVIII, IPMA, Nijkerk. Maizlish, B., & Handler, R., (2005). IT Portfolio Management Step by Step. Wiley. Martijnse N en Noordam P (2007), Projectmanagement: Lessen uit falende en succesvolle ictprojecten, MCA - Tijdschrift voor Organisaties in Control, Jaargang 11, nummer 3, Kluwer, Deventer. Matthijsse R., (2012). Manieren om zekerheden te verschaffen bij overheids-ICT-projecten, I Bestuur, januari 2012. McFarlan, F. Warren, (1981). Portfolio Approach to Information Systems, Harvard Business Review. Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (2011), Projectinitiatiedocument Implementatie mGBA. Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (2011), Kennismaken met OGC Gateway Review Morris, Peter W.G., & Jamieson, A., (2004). Translating Corporate Strategy into Project Strategy – realizing Corporate Strategy through Project Management. Project Management Institute. Neering R, Batenburg R, Bunk E, Harmsen F en Brinkkemper S (2005), Het IT-methodenlandschap in Nederland anno 2005 Via selectie, implementatie en toepassing naar succes?, institute of information and computing sciences, Utrecht University, Utrecht.

81

Onna, M.van en A. Koning. (2010). De kleine PRINCE2 Gids voor projectmanagement, Editie 2010. Academic Service. Prakken B (1997), Informatie en de besturing van organisaties, een bedrijfskundige aanpak van informatievraagstukken, Van Gorcum & Comp. B.V., Assen. Project Management Institute, (1996). A Guide to the Project Management Body of Knowledge. Project Management Institute Inc. 1996. Project Management Institute, (2008). The Standard for Portfolio Management Second Edition. Project Management Institute Inc. 2008. Reyck, B. de, Grushka-Cockayne, Y., Lockett, M., Calderini, S. R., Moura, M., & Sloper, A. (2005). The impact of portfolio management on information technology projects. International Journal of Project Management 23, pp. 524-537. Rosacker K.M en Olson D.L (2008), An empirical assessment of IT Project Selection and Evaluation Methods in State Government, Project Management Journal, Vol. 39, Project Management Institute. Sanchez, H., Robert, B. & Pellerin, R. (2008). A Project Portfolio Risk-Opportunity Identification Framework. Project Management Journal, Vol. 39, No. 3, pp. 97-109, september 2008. Tesh D, Kloppenborg T.J en Stemmer J.K (2003), Project management learning: What the literature has to say, Project Management Journal, Vol. 34, Project Management Institute The Standish Group (1995), CHAOS Report, The Standish Group International, Inc. The Standish Group (1999), Chaos: A recipe for success, The Standish Group International, Inc. The Standish Group (2001), Extreme Chaos, The Standish Group International, Inc. The Standish Group (2001), Micro Projects Cause Constant Change, The Standish Group International, Inc. The Standish Group (2013), CHAOS Manifesto, The Standish Group International, Inc. Tweede Kamer der Staten Generaal (2014), Parlementair onderzoek naar ICT-projecten bij de Overheid. Tweede Kamer, vergaderjaar 2014–2015, 33 326, nr. 5 Tweede Kamer, vergaderjaar 2009–2010, 27 859, nr. 36 Tweede Kamer, vergaderjaar 2010–2011, 27 859, nr. 39 Tweede Kamer, vergaderjaar 2013–2014, 27 859, nr. 68 Tweede Kamer, vergaderjaar 2014–2015, 27 859, nr. 78 Verhoef, C. & Kersten B., (2003). IT Portfolio Management: A Banker’s Perspective on IT. Cutter IT Journal 2003 Vol. 16, No. 4. Ward J, De Hertogh S en Viaene S (2007), Managing Benefits from IS/IT Investments: an Empirical Investigation into Current Practice, Proceedings of the 40th Annual Hawaii International Conference on System Sciences, IEEE. Ward, J., & Daniel, E. (2006). Benefits management: Delivering value from IS & IT investments (Vol. 30). Chichester: John Wiley & Sons. Weill, P., & Broadbent, M., (1998). Leveraging the new Infrastructure – How Market Leaders Capitalize on Information Technology. Harvard Business School Press. Boston, MA, USA. Weill, P., & Vitale, M., (1999). Assessing the Health of an Information Systems Application Portfolio: An Example From Process Manufacturing. MIS Quarterly. Vol. 23 No.4. pp. 601-624. White D en Fortune J (2002), Current practice in project management - an empirical study, International Journal of Project Management, Vol. 20, No. 1, Elsevier Science Ltd and IPMA, Great Britain. Winter, M., Smith, C., Morris, P., & Cicmil, S. (2006). Directions for future research in project management: the main findings of a UK government-funded research network. International journal of project management, 24(8), 638-649.

82

Websites http://ictu.nl https://www.overheid.nl http://www.operatiebrp.nl http://www.ipma.nl/wiki http://www.twynstraguddekennisbank.nl

http://www.compact.nl

83

Bijlage Door de commissie Elias zijn de volgende aanbevelingen geformuleerd:                             

Het oprichten een tijdelijke ICT-autoriteit: het BIT (Bureau ICT-toetsing); De Kamer zal zich voorafgaand aan haar politieke keuzes beter moeten verdiepen in de technische uitvoerbaarheid en de doorlooptijden van ICT-projecten; De Kamer moet zich bewust worden van het belang van ICT. De Kamer zal daarom voortaan de ICT-problematiek in het introductieprogramma van nieuwe Kamerleden opnemen; De Kamer gaat meer gebruikmaken van bestaande instrumenten zoals de Regeling Grote Projecten, en met deze intensievere informatievoorziening ook daadwerkelijk iets doen; De commissie verzoekt het kabinet om ICT voortaan expliciet en structureel mee te nemen in zijn besluitvorming; Zorg voor meer centrale sturing van het ICT-beleid van de rijksoverheid; De positie en doorzettingsmacht van de CIO Rijk moeten veranderen; Maak de besparingen en maatschappelijke opbrengsten van het algemene ICT-beleid zichtbaar; De rijksoverheid heeft zich al voorgenomen om – waar het kan – te kiezen voor open source en open standaarden; Ga door met de centralisatie van ICT-inkoop en rijk brede ICT-voorzieningen; Alle ICT-projecten binnen de rijksoverheid inclusief publiekrechtelijke zelfstandige bestuursorganen krijgen een projectorganisatie met een duidelijke sturing; Laat de departementale CIO’s meer prioriteit geven aan de beheersing van ICT-projecten en geef hun meer doorzettingsmacht; Verbeter de kwaliteit van informatie over grote en risicovolle ICT-projecten in de jaarrapportages en breid deze uit; Verzamel continu en structureel de gegevens van zo veel mogelijk ICT-projecten binnen de rijksoverheid, inclusief de oordelen van het BIT; Zorg ervoor dat de rijksoverheid in staat is een goede prioritering te maken van ICT-projecten; Gebruik de zakelijke rechtvaardiging niet alleen bij de start van een project; Er komt een verplichte starttoets bij projecten van meer dan 5 miljoen euro met een belangrijke ICT-component; Zorg voor een jaarlijks totaaloverzicht van de ICT-kosten bij de rijksoverheid, inclusief personeels-, beheer- en onderhoudskosten; Zorg ervoor dat de rijksoverheid genoeg ICT-experts van hoog niveau in dienst neemt; Ontwikkel een centraal en structureel ICT-opleidingsprogramma voor opdrachtgevers en projectleiders binnen de rijksoverheid; Maak ICT een vast onderdeel van interne opleidingen voor alle rijksambtenaren; De departementale CIO ziet erop toe dat rollen en verantwoordelijkheden helder zijn belegd; Zorg ervoor dat alle betrokkenen belang hebben bij een succesvolle afronding van het project; De uitvoerders en álle managementlagen dienen hun ambtelijke top en bestuurders te voorzien van realistische informatie over de voortgang van een project; Verplicht de rijksoverheid om voor en/of tijdens aanbestedingstrajecten altijd te overleggen met de markt; Verplicht het functioneel aanbesteden, tenzij de opdrachtgever kan uitleggen waarom dat bij een specifiek project nadelig zou zijn; Resultaten uit het verleden van een leverancier zullen voortaan worden meegewogen in de beoordeling van aanbiedingen; Stel een gedragscode op voor ICT-leveranciers; Zoek de mogelijkheden op van de Aanbestedingswet;

84

   

De departementale CIO ziet er op toe dat de rijksoverheid zich als opdrachtgever in ICTprojecten professioneler en meer betrokken opstelt; Voorkom meerwerk zo veel mogelijk en vermijd het gebruik van uurtarieven; Neem in contracten altijd ontsnappingsclausules en wijzigingsprocedures op; Stop een contract na ondertekening niet in een la, maar maak er ook daadwerkelijk gebruik van.

85