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

Transcriptie

1 Financiële sturing van IT-projecten Scriptie ter afronding van de postgraduate IT-audit opleiding aan de Vrije Universiteit Auteur: Rogier Alarm Studentnummer: 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 ITauditors zekerheid kunnen verschaffen over de opgestelde begrotingen. Hiervoor kan bijvoorbeeld een audit instrument gehanteerd worden. Naast een literatuuronderzoek is een praktijk onderzoek uitgevoerd aan de hand van interviews met medewerkers van het Ministerie van Binnenlandse Zaken en Koninkrijkrelaties. Zij hebben inzicht gegeven in de werkwijze die de overheid hanteert voor het sturen en beheersen van IT-projecten. Het afronden van mijn IT audit opleiding in combinatie met mijn werkzaamheden als senior assistent accountant en IT auditor bij Countus Accountants + Adviseurs B.V. is een zeer goede manier geweest om mijn verkregen theoretische kennis met de audit praktijk te combineren. Ten eerste wil ik de heer René Matthijsse bedanken voor de deskundige begeleiding van dit onderzoek. Als afstudeerbegeleider heeft hij op kritische wijze het onderzoek gevolgd en gestuurd. Daarnaast wil ik mijn collega s van Countus Accountants + Adviseurs B.V. bedanken voor de serieuze interesse in mijn werk en het verschaffen van relevante documentatie en feedback. Deze interesse en hulpvaardigheid hebben mijn scriptie op vele manieren verbeterd. Ook wil ik de medewerkers van het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties bedanken voor het geven van inzichten met betrekking tot projectsturing bij de overheid. Meppel, juli 2015 Rogier Alarm 2

3 Inhoudsopgave Voorwoord... 2 Inhoudsopgave Omgevingsraming en projectieraamwerk Aanleiding en vraagstelling Probleemstelling Doelstelling Centrale vraagstelling Deelvragen Plan van aanpak De portfoliobenadering voor het aansturen van IT-projecten De portfoliobenadering voor het aansturen van IT-projecten IT-projectportfolio definitie, samenstelling en kenmerken IT-projectportfoliomanagement IT-projectportfolio beheersing Definitie en kenmerken Risicogebieden Faalfactoren bij projecten Welke elementen zorgen dat een project faalt? Overschrijding van de begrote kosten Succesfactoren Instrumenten voor project auditing Voordelen van het hanteren van een auditinstrument Meest gehanteerde projectmanagementmethoden Prince Managing Succesful Programmes (MSP) Gateway review Financiële sturing van ICT projecten Gemiddelde boekhoudkundige rentabiliteit Terugverdienperiode Netto contante waarde Interne rentabiliteit Verschillen netto contante waarde en interne rentabiliteit Onderzoeken naar gekozen methode Mogelijkheden tijdens de uitvoering van een project

4 5 Praktijkonderzoek Onderzoeksaanpak Projectbeschrijving mgba Achtergrond Projectresultaten en maatschappelijke effecten Gebruikers en afnemers Gehanteerde projectportfoliomethodes Gehanteerde financiële sturingsmethode o.b.v. rapportage Capgemini Baten- en kostengebieden per stakeholder Resultaten en conclusies business case Conclusie Gekozen methodiek op basis van rapportage Capgemini Bijstelling Business Case mgba Evaluatie mgba door Gartner in Bevindingen Terugblik op de scenario s van Bijstelling van scenario 2 in Aanpassing projectaanpak naar aanleiding van onderzoek Gartner Analyse gemaakte keuzes Conclusie en synthese mgba conclusies Weerspiegeling met theorie Beantwoording onderzoeksvragen Deelvragen Centrale onderzoeksvraag Literatuurlijst Websites Bijlage

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

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

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

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 uurtjefactuurtje komen te vaak voor tijdens de uitvoering van het project. Het management let niet goed op of opdrachtgever en leverancier zich wel houden aan de oorspronkelijk vastgelegde afspraken. Problemen komen bovendien te laat aan het licht. Opdrachtgever en opdrachtnemer overleggen tijdens het project onvoldoende structureel en bovendien niet op de juiste niveaus in de organisaties. Ad 10. Het ontbreekt de rijksoverheid aan lerend vermogen op ICT-gebied Uit bovenstaande conclusies en de onderliggende analyse blijkt dat veel verschillende elementen samen verantwoordelijk zijn voor het mislukken van ICT-projecten. De meeste hiervan zijn ook al eerder benoemd in andere rapporten en onderzoeken. Toch mislukken grote ICT-projecten van de rijksoverheid nog steeds keer op keer. De commissie constateert dan ook dat een van de belangrijkste oorzaken hiervan ligt in een gebrek aan lerend vermogen bij de rijksoverheid. Het meest recente schrijnende voorbeeld hiervan is een groot project van het programma van de Sociale Verzekeringsbank (SVB Tien) dat in september 2014 na acht jaar werd stopgezet, met alle financiële en andere gevolgen van dien. Op bovenstaande tien punten worden door de commissie Elias aanbevelingen gedaan. Ook wordt er gesteld dat als slechts enkele aanbevelingen worden uitgevoerd en de resterende niet, de commissie een herhaling voorziet van zetten uit het verleden en daardoor komt er wéér geen structurele oplossing voor de problemen. Dan blijft de rijksoverheid op dit vlak aanmodderen en belastinggeld verspillen. De commissie zou dat als een gemiste kans zien niet de eerste op dit terrein. 1.2 Probleemstelling In deze paragraaf wordt aan de hand van de doelstelling de centrale vraag met bijbehorende deelvragen geïntroduceerd. De onderzoeksvraag wordt middels een specifieke onderzoeksmethode beantwoord. De sub paragraaf deelvragen beschrijft de scope van dit onderzoek Doelstelling Het doel van dit onderzoek is om een bijdrage te leveren aan het vakgebied IT Auditing door inzichtelijk te maken welke struikelblokken er aanwezig zijn bij projecten en op welke manier de ITauditors zekerheid kunnen verschaffen over de opgestelde begrotingen. Hiervoor kan bijvoorbeeld een audit instrument gehanteerd worden Centrale vraagstelling Op basis van de onderzoeksdoelstellingen is de centrale vraagstelling als volgt geformuleerd: Op welke wijze kan vanuit het perspectief van IT-auditing enige mate van zekerheid worden verschaft over de financiële sturing van projecten en welke audit instrumenten kunnen hierbij gehanteerd worden? 8

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

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 ITproject niet in alle opzichten te vergelijken is met andere projecten. Een aantal redenen hiervoor zijn: De investeringen welke worden gedaan betreffen uitgaven aan software en hardware. Deze producten worden niet aangeschaft om te bewerken tot een eindproduct, maar dienen ondersteunend te zijn. Er kunnen zelfs exit kosten aanwezig zijn (Jeffery & Leliveld, 2003; Verhoef & Kersten, 2004). Normaliter wordt bij portfoliomanagement gekeken naar de opbrengsten welke gerealiseerd zullen worden door het project. Met een IT-project worden geen directe opbrengsten gegenereerd. Er is geen Return On Investment (ROI) aanwezig (Jeffery & Leliveld, 2003). De impact van een IT-project kan verstrekkende gevolgen hebben voor de gehele bedrijfsvoering (Jeffery & Leliveld, 2003). De opkomst van de portfoliobenadering is mede ontstaan doordat de Verenigde Staten deze aanpak bij wet verplicht heeft gesteld. In Nederland is deze verplichting niet aanwezig. Wel is door de Algemene Rekenkamer (2007, 2008) aangegeven dat het hanteren van een portfoliobenadering leidt tot een beter eindresultaat van IT-projecten bij de overheid. 2.1 De portfoliobenadering voor het aansturen van IT-projecten Het aansturen van projecten conform de portfoliobenadering wordt ook wel ITprojectportfoliomanagement (ITPPM) genoemd, kortweg portfoliomanagement. Het aan te sturen object betreft een IT-projectportfolio. De eerste fase van een IT-projectportfolio- is het ontwerpen van begrippenkader van de definitie, samenstelling, eigenschappen, relaties en afhankelijkheden van de IT-projectportfolio. In deze paragraaf zullen bovengenoemde zaken worden behandeld IT-projectportfolio definitie, samenstelling en kenmerken Wanneer de literatuur er op wordt nageslagen zijn er veel definities aanwezig als het gaat om een project, programma of projectportfolio. Het Project Management Institute (PMI) heeft voor ieder van deze begrippen definities opgesteld: 10

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 ITportfolio s. Een IT-portfolio heeft altijd relaties met andere projecten. Het gehele project draagt de naam IT-projectportfolio. Door Weill en Broadbent (1998) wordt een onderverdeling gehanteerd naar een vier typen ITinvesteringen, te weten: Strategisch; Informatie; Transactioneel; Infrastructuur. Maizlish en Handler (2005) delen de IT-portfolio in naar verschillende soorten levenscycli. Dit leidt tot de volgende drie portfolio s: De IT-assetportfolio; De IT-projectportfolio; De IT-innovatieportfolio. 11

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

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

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) 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 Risicogebieden In deze paragraaf wordt een opsomming gegeven van de risico s zoals deze blijken uit de bestudeerde literatuur. Hiervoor zijn in de literatuur zoektermen gebruikt zoals risico s, risicofactoren, problemen, succesfactoren, best practices en dergelijke. De gevonden risico s zijn onderverdeeld in zes categorieën, te weten: Risico s vanuit de organisatie, haar governance en omgeving. Risico s vanuit personele capaciteit en competenties. Risico s vanuit processen en de uitvoering van IT-projectportfoliomanagement. Risico s vanuit de samenstelling van de IT-projectportfolio als geheel. Risico s vanuit de individuele IT-projectportfoliocomponenten. Risico s vanuit afhankelijkheden en relaties van de IT-projectportfoliocomponenten. Risico s vanuit de organisatie, haar governance en omgeving Risico s welke betrekking hebben op de organisatie zelf hebben vooral betrekking op beschikbaarheid en de juiste skills en ervaring van de teamleden. Maar ook governance, een duidelijke verdeling van taken, verantwoordelijkheden en bevoegdheden, ervaring bij de uitvoering van projecten en het kunnen omgaan met veranderingen (Elonen & Artto, 2003; Reyck et al., 2005; Jonas, 2010; Frey & Buxmann, 2012). Ook moet er te allen tijde rekening worden gehouden met de invloed welke de 14

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 ITprojectportfoliomanagement: De verkeerde projecten. Projecten die geen meerwaarde hebben voor de organisatie of niet overeenkomen met de strategie of toekomstplannen; Een te groot aantal actieve projecten. Door de diversiteit van projecten in type, omvang en doelstellingen is het voor het management lastig om overzicht te houden op welke projecten er actief zijn en wat hiervan de status is; Geen duidelijke balans in de projectportfolio en resourceallocatie: o Te veel nadruk op ontwikkeling en te weinig op onderzoek. o Te veel nadruk op korte termijn. o Te veel riskante projecten. o Te veel beslag op en concurrentie om essentiële resources. Alleen aandacht voor enkele belangrijke projecten, waarbij geen rekening wordt gehouden met het geheel; Projecten waardoor er verschillen ontstaan tussen projectdoelen; Vanuit de business leiding te weinig draagvlak. Risico s vanuit de samenstelling van de IT-projectportfolio Er is sprake van risico vanuit de IT-projectportfolio als geheel wanneer de samenstelling ervan niet voldoet aan de eisen die gesteld worden aan een gezonde portfolio. Een gezonde IT-projectportfolio draagt met bij aan de doelen welke door een organisatie op lange termijn worden gesteld. Enkele kenmerken van een gezonde IT-projectportfolio zijn: 1. In lijn met de organisatiestrategie. De beoogde einddoelen liggen in lijn met de ITprojectportfolio met de strategie van de organisatie of de toekomstige plannen; 2. Maximale waard creatie uit IT-investeringen. De financiële resources van organisaties zijn over het algemeen beperkt. Er kan niet te veel geld in een project worden gestoken omdat het terugverdientijd over meerdere jaren wordt verspreid. Een belangrijke drijfveer voor organisaties is het maximale resultaat te behalen met zo weinig mogelijk middelen en geld; 3. Gebalanceerd. Een portfolio is goed in balans wanneer de kenmerken genoemd bij één en twee aanwezig zijn zonder een organisatie bloot te stellen aan risico s welke niet worden geaccepteerd. Bij de uitvoering van IT-projecten zijn altijd risico s verbonden. Door het vinden van de juiste balans tussen de bedrijfswaarde en bedrijfsrisico kan een optimale balans worden gevonden tussen toekomstige meerwaarde in geldmiddelen en risico s; 4. Zowel korte termijn als lange termijn visie. IT-projecten hebben over het algemeen betrekking op een langere termijn. Via deze investeringen kan een organisaties zowel aan hun huidige als toekomstige behoefte voorzien. De IT-projectportfolio moet dan zowel op korte als op langere termijn voldoen aan strategische doelen van een organisatie. 15

16 Risico s vanuit de individuele IT-projectportfoliocomponenten Risico s vanuit de individuele IT-projectportfoliocomponenten betreffen het falen van individuele ITprojecten of IT-programma s door het niet opleveren van resultaten binnen de gestelde tijd, budget en kwaliteit (Drake en Byrd (2006), Jeffery en Leliveld (2004), Benko en McFarlan (2003) en Kumar, Ajjan en Niu (2008). Risico s vanuit afhankelijkheden en relaties van de IT-projectportfoliocomponenten Er is sprake van afhankelijkheid wanneer meerdere aspecten van projecten zoals kosten en baten, of resources samenhangen met andere projecten welke worden uitgevoerd of staan gepland. Door de samenhang tussen deze projecten kan dit het succes of falen van andere projecten beïnvloeden en daarmee het algehele portfolioresultaat. Dit houdt in dat het falen van één project of programmaonderdeel vervolgfalen kan hebben voor alle projecten welke worden uitgevoerd en dus uiteindelijk op de gehele IT-portfolio. 2.3 Faalfactoren bij projecten Uit onderzoek is gebleken dat de meeste bedrijven een beperkte effectiviteit hebben in het managen van projecten (Cicmil, 1999). 75%-80% van de gestarte projecten mislukt (Rosacker en Olson, 2008; Ward et al., 2007; Boersma et al., 2007; Ives, 2005; Drummond en Hodgson, 2003; Cozijnsen et al., 2000; Prakken, 1997). De vraag is waarom deze projecten mislukken. Om deze vraag te kunnen beantwoorden zal eerst moeten worden aangegeven wat de eisen zijn waaraan een geslaagd project moet voldoen. De manier waarop wordt getoetst of een project geslaagd is, is een lastig punt. Is een project succesvol afgerond wanneer deze binnen de gestelde eisen is opgeleverd of is een project geslaagd wanneer een klant zijn goedkeuring geeft (Anantatmula, 2008; Drummond en Hodgson, 2003; Cicmil, 1997; Belassi en Tukel, 1996; Matthijssen, Bij het doorlezen van diverse artikelen wordt er op deze vraag geen duidelijk antwoord gegeven. Uit onderzoek onder nagenoeg duizend projectmanagers zijn een aantal factoren naar voren gekomen wanneer een project kan worden beschouwd als succesvol (White en Fortune, 2002): voldoet aan de gebruikerseisen; is afgerond binnen de gestelde tijd; is afgerond binnen het beschikbare budget; voldoet aan de organisatiedoelen; heeft toegevoegde waarde voor de organisatie; heeft minimale bedrijfsverstoringen opgeleverd; voldoet aan kwaliteitsstandaarden. Toch geeft het uitgevoerde onderzoek geen goed beeld van de werkelijke weergave. Wanneer er wordt gekeken naar de ondervraagde personen betreft het in alle gevallen een projectmanager. Er is dus bijvoorbeeld niet gekeken naar de eindgebruikers en naar de leiding van de organisatie. Zij kunnen hele andere opvattingen hebben over dat het project wel of niet succesvol is uitgevoerd. Een organisatie welke uitgebreid onderzoek doet naar het slagen en mislukken van projecten met betrekking tot IT is de Standish Group. Deze organisatie houdt zich al sinds 1985 bezig met dit type onderzoeken. Uit het onderzoek wat de Standish Group heeft verricht in 2012 is gebleken dat 39% van alle projecten succesvol is afgerond. Dit houdt in dat het project tijdig is opgeleverd, binnen budget is gerealiseerd en alle functionaliteiten heeft zoals vereist. 43% van de projecten zijn afgerond, echter niet binnen de 16

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

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

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

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