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

Auteur: Rogier Alarm Studentnummer: 2036878 Organisatie: Countus Accountants + Adviseurs B.V. VU begeleider (extern): dr. René Matthijsse RE Bedrijfscoach (intern): Mark Spijker RA Afstudeerdatum: juli 2015

2

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 IT-

auditors 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

3

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 Plan van aanpak ............................................................................................................................... 9

2 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

4

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 Conclusie en synthese ............................................................................................................................ 72

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

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

7 Beantwoording onderzoeksvragen ........................................................................................................ 75

7.1 Deelvragen ..................................................................................................................................... 75

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

Literatuurlijst ................................................................................................................................................. 80

Websites ........................................................................................................................................................ 83

Bijlage ............................................................................................................................................................ 84

5

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.

6

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. De rijksoverheid heeft haar ICT-projecten niet onder controle.

2. De politiek beseft het niet, maar ICT is overal.

3. De rijksoverheid maakt haar ICT-beleidsambities niet waar.

4. De verantwoordings- en besluitvormingsstructuur bij ICT-projecten is zeer gebrekkig.

5. De rijksoverheid heeft onvoldoende inzicht in de kosten en baten van haar ICT.

6. De ICT-kennis van de rijksoverheid schiet tekort.

7. Het ICT-projectmanagement is zwak.

8. ICT-aanbestedingstrajecten bevatten perverse prikkels.

9. Het contractmanagement bij ICT-projecten is onprofessioneel.

10. 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 ICT-

projecten 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 ICT-

beleidsambities 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

7

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.

8

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 ‘uurtje-

factuurtje’ 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 IT-

auditors 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?

9

1.2.3 Deelvragen

Ter onderbouwing van de centrale vraagstelling zijn de volgende deelvragen geformuleerd:

1 Wat wordt verstaan onder de term portfoliomanagement en welke audit instrumenten gericht op

risicobeheersing worden toegepast om zekerheid te verschaffen bij een project?

2 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?

3 Op welke wijze kan vanuit het perspectief van IT-auditing zekerheid worden verschaft over de

financiële sturing van projecten?

1.3 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.

10

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 IT-

project 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 IT-

projectportfoliomanagement (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:

11

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 IT-

portfolio’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 IT-

investeringen, 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.

12

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

13

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.

14

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

15

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 IT-

projectportfoliomanagement:

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 IT-

projectportfolio 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.

16

Risico’s vanuit de individuele IT-projectportfoliocomponenten

Risico’s 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).

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

17

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).

18

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.

19

Project Raming Realisatie of prognose

C2000 598 793 (2 jaar later)

Walvis 360 367 (realisatiedatum nog niet bekend)

NVIS 12 24 (2,5 jaar later)

SUB 129 202 (realisatiedatum nog niet bekend)

Toeslagen 77 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.

20

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 IT-

project;

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.

21

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.

22

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.

23

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

24

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.

25

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. Auditinstrument

1 A4 projectmanagement

2 New Product Development

3 PMBOK, Project Management Body of Knowledge

4 Prince2, PRojects IN Controlled Environments

5 Procesmanagement

6 Projectmatig creëren

7 Projectmatig werken

8 System Management

9 Scrum

10 PROPS

11 Project Management method

12 Doeltreffend Projectmanagement

13 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).

26

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

27

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-project-

managementteam 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 PRINCE2-

technieken 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.

28

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 vast-

gelegd in de oorspronkelijke projectinitiatiedocumentatie zijn gerealiseerd (of dat

goedgekeurde wijzigingen in de doelstellingen zijn gerealiseerd).

29

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).

30

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

31

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.

32

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.

33

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

34

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.

35

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 Review-

methode 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:

36

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.

37

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

38

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 Kasstroom A Kasstroom B

0 -100.000 -100.000 1 34.000 30.000 2 34.000 30.000 3 34.000 30.000 4 34.000 100.000 5 75.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.

39

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;

Io = initiële investering;

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 Kasstroom A x 1/(1+k)t Contact waarde op t = 0

0 -100.000 1,000 -100.000 1 34.000 0,943 32.062 2 34.000 0,890 30.260 3 34.000 0.840 28.560 4 34.000 0,792 26.928 5 75.000 0,747 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.

40

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

41

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 waarde-

methode 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 ont-

wikkelingssubsidie 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

42

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 waarde-

methodiek 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:

43

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.

44

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.

45

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.

Verenigde

Staten Australië Canada Ierland Japan Verenigd

Koninkrijk Zuid- Korea

TVP 59% 61% 50% 84% 52% 76% 75% IR 52% 37% 62% 84%

4% 39% 75%

NCW 28% 45% 41% 6% 38% 60% GBR 13% 24% 17% 24% 36% 28% 68% Overig 44% 7% 8% - 5% 7% -

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.

46

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.

47

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.

48

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.

49

5.2 Projectbeschrijving mGBA

5.2.1 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:

50

1. doelstellingen (inclusief maatschappelijke effecten) zijn behaald;

2. het project binnen de planning en het budget is gerealiseerd;

3. stakeholders tevreden zijn en

4. de technische systemen met voldoende kwaliteit en

5. 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 Aantal inwoners Aantal gemeenten

Kleine gemeente Tot 20.000 156 Middelgroot 20 – 50.000 191 Groot 50 – 100.000 45 100+ 100 – 250.000 22 G4 Meer dan 250.000 4

51

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

52

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 169.319 6,0 jaar

Scenario 3 -25.362 -

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.

53

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 BZS-

K, 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

54

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 back-

office 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.

55

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.

56

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.

57

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.

58

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

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.

59

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.

60

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 BZS-

K 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.

61

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.

62

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.

63

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.

64

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

65

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.

66

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.

67

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.

5.7 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;

68

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.

69

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.

70

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,

71

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.

72

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 ICT-

projecten 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.

73

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

74

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).

75

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 ICT-

projecten.

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.

76

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 ICT-

ondersteuning 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

77

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 598 793 (2 jaar later)

Walvis 360 367 (realisatiedatum nog niet bekend)

NVIS 12 24 (2,5 jaar later)

SUB 129 202 (realisatiedatum nog niet bekend)

Toeslagen 77 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.

78

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?

79

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.

80

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.

81

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 ict-

projecten, 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.

82

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.

83

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

84

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;

85

De departementale CIO ziet er op toe dat de rijksoverheid zich als opdrachtgever in ICT-

projecten 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.