Risicomanagement en ICT-projecten - VUrORE · 2012-04-18 · Cobit Risicomanagement en Value...

1

Vrije Universiteit Amsterdam Register EDP Audit opleiding

Risicomanagement en ICT-projecten

Complexiteit Business en ICT alignment

Continu risicodenken en -management Succes of falen

De relatie tussen de toepassing van risicomanagement en het slagen of falen van ICT-projecten en verschillen tussen de private en publieke sector

Namen Luigi Mathilda Bart Tesselaar Adres Dirk Sonoystraat 121 Prinses Margrietlaan 17 1067XV Amsterdam 3641HA Mijdrecht Telefoon +31 (0)6-2125 1876 +31 (0)6-2125 1708 E-mail [email protected] [email protected] Studentnummer 1689894 1689886 Teamnummer 937 Datum 3 april 2009 Werkgever Ernst & Young TSRS, Amsterdam Bedrijfscoach E&Y drs. I. Bolderhey RE RA Begeleider VU drs. B. van Staveren

mailto:[email protected]

mailto:[email protected]

2

Inhoud

1 INLEIDING..............................................................................................................................................................3 1.1 AANLEIDING VAN HET ONDERZOEK .....................................................................................................................3 1.2 DOEL .................................................................................................................................................................3 1.3 VRAAGSTELLING ................................................................................................................................................3 1.4 REIKWIJDTE .......................................................................................................................................................4 1.5 ONDERZOEKSMETHODE ......................................................................................................................................4 1.6 LEESWIJZER........................................................................................................................................................4

2 RISICOMANAGEMENT EN ICT-PROJECTEN..................................................................................................5 2.1 INLEIDING ..........................................................................................................................................................5 2.2 DEFINITIE RISICOMANAGEMENT PROCESSEN ........................................................................................................5

2.2.1 Risicoanalyse.............................................................................................................................................6 2.2.2 Risicobeheersing........................................................................................................................................6 2.2.3 Evaluatie en bewaking ...............................................................................................................................6

2.3 ORGANISATIEBREED RISICOMANAGEMENT: COSO...............................................................................................6 2.4 RISICOMANAGEMENT GERICHT OP ICT ................................................................................................................7

2.4.1 CobiT ........................................................................................................................................................7 2.4.2 Risk IT.......................................................................................................................................................9 2.4.3 CMMi...................................................................................................................................................... 10

2.5 RISICOMANAGEMENT GERICHT OP ICT-GERELATEERDE PROJECTEN .................................................................... 11 2.5.1 Projects in Controlled Environments (Prince2) ........................................................................................ 11 2.5.2 NIST........................................................................................................................................................ 12 2.5.3 Val IT ...................................................................................................................................................... 13

2.6 TOEPASSING ICT RISICOMANAGEMENT BINNEN ORGANISATIES........................................................................... 15 2.6.1 Toepassing ICT risicomanagement binnen organisaties............................................................................ 15 2.6.2 Risicomanagement rondom ICT-projecten................................................................................................ 16

2.7 HET NEGENVLAKSMODEL ................................................................................................................................. 17 2.7.1 Bruikbaarheid voor probleemstelling ....................................................................................................... 17 2.7.2 Analyse van risicomanagement met het Negenvlaksmodel......................................................................... 19

3 THEORETISCH KADER...................................................................................................................................... 22 4 FAALFACTOREN ICT-PROJECTEN OVERHEID IN DE PRAKTIJK VERSUS THEORETISCH TOETSINGSKADER..................................................................................................................................................... 23

4.1 ACHTERGROND ICT-PROJECTEN BIJ DE OVERHEID.............................................................................................. 23 4.2 FAALFACTOREN ICT-PROJECTEN OVERHEID ...................................................................................................... 23

4.2.1 Politieke complexiteit............................................................................................................................... 23 4.2.2 Organisatorische complexiteit.................................................................................................................. 24 4.2.3 Technische complexiteit ........................................................................................................................... 24

4.3 FAALFACTOREN OVERHEID VERSUS THEORETISCH KADER .................................................................................. 24 4.3.1 Ingevoerde risicobeheersende maatregelen bij het UWV........................................................................... 25 4.3.2 Faalfactoren overheid versus theoretisch toetsingskader .......................................................................... 25

5 BEHEERSING VAN ICT-PROJECTEN BIJ PRIVATE SECTOR IN DE PRAKTIJK..................................... 26 5.1 RISICOMANAGEMENT BIJ ICT-PROJECTEN IN DE PRIVATE SECTOR ....................................................................... 26 5.2 TOETSINGSKADER RISICOMANAGEMENT RONDOM GROTE ICT-PROJECTEN .......................................................... 32

5.2.1 Toetsingskader ........................................................................................................................................ 32 5.2.2 Impact en rol IT Audit vakgebied ............................................................................................................. 33

5.3 ANALYSE SUCCES VERSUS MISLUKKING ............................................................................................................. 34 5.3.1 Verschillen tussen slagen en falen van projecten ...................................................................................... 34 5.3.2 Verschillen en overeenkomsten tussen publiek en privaat.......................................................................... 35

6 CONCLUSIE.......................................................................................................................................................... 36

3

1 Inleiding

1.1 Aanleiding van het onderzoek Organisaties zijn over het algemeen erg afhankelijk van IT systemen om hun processen te automatiseren en bedrijfskritische data op te slaan, als gevolg waarvan IT-risico’s een significante component vormen van het totale operationele risico. Hierdoor wordt de beheersing van IT gerelateerde risico’s ook steeds belangrijker voor organisaties. Onder IT risicomanagement wordt verstaan: het op gestructureerde wijze identificeren en kwantificeren van IT-risico’s en het vaststellen van beheersmaatregelen. De IT-risico’s omvatten onder meer de elementen beveiliging, beschikbaarheid, performance en compliance. De beheersing van risico’s op het vlak van de organisatie, processen en techniek ten opzichte van de beheersing van IT-risico’s binnen projecten kan een organisatie in staat stellen om onzekerheden in de IT omgeving (bijvoorbeeld defecten in applicaties, ongeautoriseerde toegang tot bedrijfskritische informatie, etc.) adequaat te beheersen. Op basis van rapporten van de Rekenkamer en andere deskundigen (bijv. de website www.cio.com) zijn echter een groot aantal voorbeelden van ICT-projecten die mislukt zijn in de publieke sector. Neem bijvoorbeeld de uitkering van toeslagen door de Belastingdienst waarbij mensen door automatiseringsproblemen geen, of juist te veel geld hebben ontvangen. Of het Walvis/SUB-project bij het UWV. Effectief risicomanagement rondom deze ICT-projecten zou deze organisaties voor deze mislukkingen mogelijk hebben kunnen behoeden. Voor de private sector zijn mislukte ICT-projecten minder algemeen bekend, omdat deze geen onderdeel uitmaken van Rekenkamer-rapportages of soortgelijke openbare bronnen. Daarom zijn deskundigen in enkele grote ondernemingen benaderd om na te gaan of lering kan worden getrokken uit de faalfactoren in de publieke sector, zoals te veel politieke bemoeienis, en of deze faalfactoren worden meegenomen in de risicoanalyse in de private (profit) sector.

1.2 Doel De doelstelling van dit onderzoek is om inzichtelijk te maken waarom veel ICT-projecten in de publieke sector niet het beoogde resultaat realiseren, of dit tevens in deze mate voorkomt ten aanzien van ICT-projecten in de private sector en of er verbanden en/of lessons learned zijn te herleiden uit een vergelijking van de publieke en private sector. Zoals genoemd in de aanleiding is de publieke sector meer toegankelijk qua informatie over het mislukken van ICT-projecten dan de private sector.

1.3 Vraagstelling Op basis van de uiteengezette aanleiding is de volgende centrale vraag geformuleerd:

Op basis van bovenstaande centrale vraagstelling, is een uitsplitsing gemaakt naar de volgende subvragen: 1 Theorie: Wat is risicomanagement en op welke wijze kan dit tot uitvoering worden gebracht

(modellen/best practices)? 2 Theorie: Op grond van literatuuronderzoek, in hoeverre wordt risicomanagement gebruikt binnen

organisaties tot op heden? 3 Theorie: Op welke wijze kan het Negenvlaksmodel van Prof. dr ir Rik Maes, (Universiteit van

Amsterdam) worden gebruikt om een adequaat risicomanagement toetsingskader voor projecten te definiëren?

4 Praktijk: Worden de faalfactoren (faalfactoren ICT-projecten publieke sector, bijv. specifiek bij het UWV het Walvis/SUB-project) die zijn genoemd in het rapport van de Algemene Rekenkamer geadresseerd in het theoretische kader?

5 Praktijk: Hoe hebben organisaties zowel binnen de publieke als private sector invulling gegeven aan de beheersing van risico’s rondom ICT-projecten?

Wat zijn de verschillen in de toepassing van risicomanagement tussen organisaties waar ICT-projecten zijn geslaagd en organisaties waar ICT-projecten zijn mislukt en welke verschillen zijn er tussen de publieke en private sector?

http://www.cio.com)

4

6 Praktijk: Wat zijn de verschillen tussen de organisaties waar risicomanagement wel heeft geleid tot een goed project-resultaat en de organisaties waar ICT-projecten zijn mislukt? En welke rol dient de IT-Auditor te spelen bij ICT-projecten?

1.4 Reikwijdte In het onderzoek wordt specifiek aandacht besteed aan (het managen van) de risico’s rondom ICT-projecten en de relatie tot het slagen/falen hiervan. Een beperkt aantal publieke en private organisaties is onderzocht.

1.5 Onderzoeksmethode Het onderzoek is uitgevoerd door enerzijds een literatuuronderzoek op het gebied van de theoretische deelvragen en anderszijds door interviews uit te voeren met: § relevante medewerkers van Information Risk Management afdelingen en strategisch betrokkenen bij ICT-

projecten binnen een beperkt aantal organisaties; § professionals binnen onze organisatie (Ernst&Young).

1.6 Leeswijzer De opbouw van dit scriptierapport is conform bovengenoemde deelvragen en de bijbehorende hoofdstukken worden in onderstaande figuur weergegeven:

1. Theorie risicomanagement en ICT-projecten

2. Theorie toepassing risico-management binnen organisaties

3. Uitwerken theoretisch kader aan de hand van theorie en negenvlak

4. Praktijkonderzoek faalfactoren en risicomanagement publieke sector

5. Praktijkonderzoek risicomanagement bij ICT-projecten in de private sector

Beantwoorden hoofdvraag / conclusie

6. Analyse en uitwerken toetsingskader voor risicomanagement rondom ICT-projecten

Hoofdstuk 2. Hoofdstuk 2 en 3 Hoofdstuk 4 en 5 Hoofdstuk 5 en 6

5

2 Risicomanagement en ICT-projecten

2.1 Inleiding In dit hoofdstuk wordt op basis van diverse relevante theoretische modellen beschreven wat risicomanagement inhoudt en op welke wijze dit tot uitvoering kan worden gebracht in relatie tot ICT-gerelateerde projecten. De volgende theoretische modellen worden in dit hoofdstuk beschreven: Theorie Raakvlak onderzoek Paragraaf

Paragraaf 2.2: Definitie risicomanagement processen Risicomanagement Definitie risicomanagement processen 2.2

Paragraaf 2.3: Organisatiebreed risicomanagement: COSO COSO Organisatiebreed risicomanagement (interne controle) 2.3.1

Paragraaf 2.4: Risicomanagement gericht op ICT Cobit Risicomanagement en Value Delivery als onderdeel van IT governance 2.4.1 Risk IT Risicomanagement op het gebied van bedrijfsrisico’s gerelateerd aan het gebruik van IT 2.4.2 CMMi Risicobeheersing rondom systeemontwikkeling 2.4.3

Paragraaf 2.5: Risicomanagement gericht op ICT-gerelateerde projecten Prince2 Project(risico) management 2.5.1 NIST Risicobeheersing rondom informatiesystemen 2.5.2 Val IT Risicomanagement met als doel het verkrijgen van positieve bedrijfswaarde uit IT-

gerelateerde investeringen 2.5.3

Paragraaf 2.6: Toepassing ICT risicomanagement binnen organisaties Toepassing risico-management

Op basis van de theorie wordt beschreven in welke mate risicomanagement wordt toegepast in de praktijk, in het algemeen en specifiek rondom ICT-gerelateerde projecten

2.6

Waar mogelijk wordt gebruik gemaakt van overige theorie (bijv. artikelen) ter ondersteuning van de theoretische modellen. Op basis van relevante aspecten uit deze theoretische modellen wordt in hoofdstuk 3 een theoretisch kader samengesteld met als doel:

2.2 Definitie risicomanagement processen Elk bedrijf heeft een eigen unieke omgeving die vrij complex en dynamisch kan zijn, omdat organisaties te maken hebben met allerlei invloeden van interne of externe aard, zoals werknemers, klanten, leveranciers, maatschappelijke ontwikkelingen, ontwikkelingen op het gebied van de wetgeving etc. Het management zal deze omgeving goed moeten kennen en de veranderingen erin waarnemen en er een antwoord op weten. Het adequaat reageren van bedrijven op die veranderingen in hun omgeving is van cruciaal belang. In de praktijk wordt dit in projectvorm uitgevoerd en deze projecten bieden diverse kansen voor diezelfde organisaties. Echter om deze kansen te kunnen benutten en de daarbij horende risico’s te kunnen beheersen, is het van wezenlijk belang dat binnen de organisatie een efficiënt en effectief risicobeheersingsysteem wordt opgebouwd. Wat is eigenlijk risicomanagement? Het management zal over informatie willen en moeten beschikken om risico’s te beoordelen, te evalueren en op basis daarvan keuzes te maken (Christiaanse en van Praat, 2005). Hier gaat het dus om de volgende drie processen die onderling met elkaar in samenhang moeten zijn: § Risicoanalyse; § Risicobeheersing; § Evaluatie en bewaking. Deze drie processen zijn noodzakelijk in het kader van het adequaat reageren van organisaties op de ontwikkelingen die zowel binnen als buiten haar eigen omgeving plaatsvinden.

Adequaat risicomanagement rondom ICT-projecten en daarmee het verkrijgen van (de beoogde) positieve bedrijfswaarde en het voorkomen van mislukking.

6

2.2.1 Risicoanalyse Risicobeoordeling is het eerste proces van de risicobeheersingmethodologie en bevat het op systematische wijze identificeren van risico’s, het evalueren van de daarbij horende impact en het aanbevelen van risicoreducerende maatregelen. Organisaties maken gebruik van dit proces om de omvang van mogelijke ongewenste gebeurtenissen en de bijbehorende risico’s voor hun (informatie)systemen vast te stellen. Het resultaat van dit proces helpt organisaties om hieruit gemotiveerde conclusies te trekken voor het minimaliseren of elimineren van risico’s gedurende het risicobeheersingproces. Risico is een functie van de kans op een bepaalde oorzaak dat gevaar als gevolg heeft die tevens een potentiële kwetsbaarheid met zich meebrengt en de daarbij resulterende impact van dit ongunstig incident op de organisatie (Stoneburner e.a., 2002).

2.2.2 Risicobeheersing Nadat de potentiële risico’s in kaart zijn gebracht, moet de benodigde maatregelen en/of procedures worden ingevoerd en gehandhaafd, zodat de geïdentificeerde risico’s worden gemitigeerd. Dit proces bevat verder het toekennen van prioriteiten aan de geïdentificeerde risico’s, het evalueren van de voorgestelde maatregelen uit het risicoanalyseproces en het implementeren van de juiste risicoreducerende maatregelen. Het elimineren van alle geïdentificeerde risico’s is doorgaans bijna een onmogelijke activiteit. Hierdoor is het management verantwoordelijk voor het implementeren van de meest geschikte en economische maatregelen, om de risico’s die een dreiging vormen voor de bedrijfsmissie terug te brengen naar een geaccepteerd niveau (Stoneburner e.a., 2002).

2.2.3 Evaluatie en bewaking Door de continu veranderende interne- en externe omgeving van organisaties, kan dit tot gevolg hebben dat nieuwe risico’s optreden of dat eerder gemitigeerde risico’s opnieuw een dreiging vormen voor de realisatie van de organisatiedoelen. In figuur 1 hieronder is risicomanagement in relatie met de drie processen: Risicoanalyse, Risicobeheersing en Evaluatie, weergegeven.

Figuur 1 Risicomanagement in relatie met Risicoanalyse, Risicobeheersing en Evaluatie.

2.3 Organisatiebreed risicomanagement: COSO Ten aanzien van organisatiebreed risicomanagement is het raamwerk “Internal Control – Integrated Framework” van de “Committee of Sponsoring Organizations of the Treadway Commission” (hierna: COSO) het meest bekend. Indien een organisatie haar beoogde doelstellingen wil bereiken is het van belang dat de bijbehorende risico’s in de (unieke) omgeving in kaart worden gebracht. Daarnaast dienen deze risico’s te worden beheerst. De COSO-commissie heeft in 1992 een rapport gepubliceerd waarin het COSO Internal Control – Integrated Framework is opgenomen. De centrale doelstelling die ten grondslag ligt aan het COSO raamwerk is het bieden van ondersteuning aan het bestuur van organisaties bij de beheersing van de bedrijfsprocessen van de onderneming (Christiaanse en van Praat, 2005). Voorts heeft deze commissie in 2004 de COSO Enterprise Risk

Risicomanagement

Risicoanalyse

Risicobeheersing Evaluatie

7

Management (hierna: ERM) gepubliceerd en staat bekend als COSO II. Het ERM raamwerk is een uitbreiding op het COSO Internal Control – Integrated Framework en is een meer risicogeoriënteerd raamwerk (COSO, 2004). Deze methodologie is verder uitgerust met een proces om met een redelijke mate van zekerheid, de doelstellingen van de organisatie te bereiken op de volgende gebieden: (COSO, 2004) 1. Strategisch – deze zijn bedrijfsdoelstellingen op hoog niveau die de missie van de organisatie ondersteunen; 2. Operationeel – effectieve en efficiënte gebruik van bedrijfsmiddelen; 3. Verslaglegging - betrouwbaarheid van de informatievoorziening; 4. Toezicht – naleving van de toepasbare weten regelgeving. Het COSO-raamwerk omvat acht componenten die in een iteratief proces aan elkaar gerelateerd zijn, waarin elke component van invloed kan zijn op een andere component: § Interne omgeving – deze omgeving geeft de toon binnen de organisatie aan en de basis van de wijze waarop

risico’s worden gezien en geadresseerd door haar medewerkers, inclusief de risicobeheersingfilosofie en de mate waarop de organisatie bereid is om risico’s te accepteren (“risk appetite”), integriteit, ethische waardes en de omgeving waarin de organisatie opereert;

§ Doelstelling – doelen moeten bestaan voordat het management potentiële risico’s kan identificeren die van invloed zijn op de realisatie van deze doelstellingen. ERM waarborgt dat het management een proces in plaats heeft voor het definiëren van doelen en dat de gestelde doelen in lijn zijn met de bedrijfsmissie en zijn consistent met de “risk appetite” van de organisatie;

§ Risico identificatie – zowel interne als externe risico’s die een impact hebben op de realisatie van bedrijfsdoelstellingen moeten worden geïdentificeerd, waarbij onderscheid tussen risico’s en kansen dient te worden gemaakt. Kansen worden teruggekoppeld met de strategie van het management of het doelstellingsproces binnen de organisatie;

§ Risico beoordeling – risico’s worden geanalyseerd, inclusief de kans op de gebeurtenis ervan en de impact, zodat dit als basis kan worden gebruikt voor het bepalen van de mitigerende acties. Risico’s worden beoordeeld op een inherente en residuele basis;

§ Risico response – het management selecteert een risico respons, zoals ontwijkend, accepterend, reducerend of delend gedrag, waarbij een set van acties wordt bepaald voor de afstemming met de risicotoleranties en risk appetite;

§ Controle activiteiten – beleid en procedures zijn opgesteld en geïmplementeerd voor de waarborging van het adequate risico respons;

§ Informatie en communicatie – relevante informatie is geïdentificeerd, vastgelegd en gecommuniceerd in de vorm en tijdsbestek dat het mogelijk wordt voor de betrokken medewerkers om hun verantwoordelijkheden uit te kunnen oefenen.

§ Monitoring – het geheel van “Enterprise Risk Management” wordt bewaakt binnen de organisatie en waar nodig worden aanpassingen gemaakt. Dit wordt gerealiseerd door management activiteiten en/of gescheiden evaluaties die continu hierop zijn gericht.

2.4 Risicomanagement gericht op ICT ICT risicomanagement is het proces voor het systematisch identificeren, analyseren en beheersen van risico’s met betrekking tot de inrichting van de informatievoorziening binnen organisaties (Stoneburner, 2002). Het ultieme doel van dit proces is om organisaties te ondersteunen in het verbeteren van de beheersing van IT gerelateerde risico’s. In de volgende paragrafen wordt verder ingegaan op ICT risicomanagement op basis van de modellen: a) Cobit (paragraaf 2.4.1), b) Risk IT (paragraaf 2.4.2) en c) CMMi (paragraaf 2.4.3).

2.4.1 CobiT “Control Objectives for Information and Related Technology” (hierna: CobiT) is een algemeen toepasbare en geaccepteerde standaard voor de beveiliging en beheersing van de informatievoorziening (MAB, 2005). De CobiT standaard stelt het management verder in staat om het gat te overbruggen met betrekking tot controle-eisen, technische kwesties, bedrijfsrisico’s, en de communicatie hierover met de betrokken partijen. Daarnaast biedt de standaard ondersteuning voor “IT-governance” praktijken en een referentiekader voor het management, gebruikers, beveiligingsdeskundigen, auditors en beheerders. IT-governance valt tevens onder de verantwoordelijkheid van het management en de raad van bestuur, en bestaat uit leiderschap, organisatiestructuren en processen die waarborgen dat de doelstellingen en missie van de organisatie worden

8

ondersteund en uitgebreid door de IT-functie1. Risk Management is onderdeel van de vijf IT-governance focus gebieden: § Strategic Alignment: het op een lijn brengen van de bedrijfsvoering met de totaaloplossingen; § Value Delivery: optimalisatie van de uitgaven en het aantonen van de waarde van IT; § Risk Management: beveiliging van de IT-omgeving, calamiteiten plan en de continuïteit van de

bedrijfsvoering; § Resource Management: optimalisatie van kennis en de IT-infrastructuur; § Performance Measurement: project realisatie en het monitoren van IT-diensten.

2.4.1.1ICT risicomanagement Het raamwerk van CobiT bestaat uit drie dimensies, a) zeven kwaliteitsaspecten, b) vier categorieën van informatiemiddelen en c) een generiek procesmodel met vier domeinen (ITGI, 2007). Deze dimensies en de onderlinge verbanden worden in bijalge 1 (figuur 1) nader geïllustreerd. Binnen het procesdomein ‘Planning en Organisatie’ definieert CobiT een specifieke beheersmaatregel ten aanzien van de analyse en beheersing van IT-risico’s. Deze maatregel heeft als doelstelling om IT-risico’s te analyseren en communiceren, zodat de potentiële impact van deze risico’s op de bedrijfsprocessen en doelen kan worden vastgesteld. Organisaties dienen hierbij de focus te leggen op de ontwikkeling van een risicobeheersingsysteem dat geïntegreerd is met het bedrijfsdomein inclusief operationele risicomanagement, risicobeoordeling, risicobeheersing en communicatie over resterende risico’s. Volgens het Cobit-model kunnen organisaties dit realiseren door te waarborgen dat: § risicomanagement volledig is geïncorporeerd in de managementprocessen en wordt zowel in de interne- als

de externe omgeving op een consistente wijze toegepast; § risicoanalyses op een continu wijze worden uitgevoerd; § risicoreducerende maatregelen worden aanbevolen en gecommuniceerd. Voorts onderscheidt Cobit de volgende bedrijfsmiddelen die geraakt worden door het risicobeheersingproces: 1. Applicaties; 2. Informatie; 3. Infrastructuur; 4. Personeel. Dit proces kan verder volgens Cobit worden onderverdeeld in de volgende subprocessen: § IT Risicobeheersingraamwerk – een IT risicobeheersingsysteem opzetten die in lijn is met het

organisatiebrede risicobeheersingsysteem; § Risico context – de context bepalen waarin het risicobeheersingsysteem moet worden toegepast, zodat de

beoogde resultaten worden geborgd. Hierbij dient zowel de interne- als externe context van de risicoanalyse te worden vastgesteld, tevens het doel van de analyse en de criteria waartegen risico’s worden geëvalueerd;

§ Risico identificatie – het identificeren van relevante gebeurtenissen die kunnen leiden tot een significante kwetsbaarheid met een negatieve impact op de bedrijfsdoelen ten aanzien van het bedrijfsdomein, regelgeving, juridisch, technologisch, handelspartners, personeel en andere operationele aspecten. Voorts is het hier van belang dat de aard van de impact dient te worden bepaald en vastgelegd;

§ Risicoanalyse – de kans op de gebeurtenis en de impact van alle geïdentificeerde risico’s dienen continu te worden beoordeeld door middel van kwalitatieve en kwantitatieve methoden;

§ Risicoresponse – het ontwikkelen en onderhouden van een proces voor het identificeren van een risicoresponse dat waarborgt dat economische beheersmaatregelen worden getroffen om de betreffende risico’s te mitigeren op een regelmatige basis. Dit proces onderkent de volgende risicoresponse categorieën: ontwijkend, reducerend, verspreidend of accepterend. Hierbij is het verder van belang dat de corresponderende verantwoordelijkheden bepaald moeten worden en het risicoacceptatie niveau;

§ Onderhoud en bewaking van het actieplan voor risico’s – het toekennen van prioriteiten en het plannen van beheersingsactiviteiten op alle niveaus voor de implementatie van de gekozen risicoresponses, inclusief kosten en baten identificatie en de verantwoordelijkheden voor de executie ervan. Voorts moeten de aanbevolen risicoreducerende acties worden geautoriseerd, residuale risico’s dienen te worden geaccepteerd en afwijkingen van het actieplan dienen te worden gerapporteerd aan het management.

1 “Board Briefing on IT-Governance 2nd Edition” - http://www.isaca.org

http://www.isaca.org

9

2.4.1.2Projectbeheersing Naast risicomanagement definieert CobiT een specifieke maatregel voor de beheersing van projecten binnen het proces van Planning en Organisatie. Deze maatregel valt tevens onder het focusgebied van Value Delivery binnen IT-Governance en heeft als doelstelling om projectresultaten op te leveren binnen de met de business afgestemde tijdslijnen, budget en kwaliteit. Organisaties dienen hierbij te focussen op een gedefinieerde methodologie voor de beheersing van IT-projecten, die het doorgaans mogelijk maakt voor de betrokken partijen om te participeren in het project en dat de projectrisico’s en voortgang worden bewaakt. Indien hiervan gebruikt wordt gemaakt, dan is het mogelijk voor organisaties om projecten adequaat te beheersen. In tegenstelling tot het proces voor de beheersing van IT-risico’s, worden de volgende drie bedrijfsmiddelen geraakt door het proces voor de beheersing van projecten: (1) applicaties, (2) infrastructuur en (3) personeel. Als onderdeel van het proces voor de beheersing van projecten wordt de stap “Projectrisicobeheersing” gedefinieerd. Hier gaat het om het elimineren of minimaliseren van specifieke projectrisico’s met een systematisch proces voor het plannen, identificeren, analyseren, reageren, bewaken en beheersen van de gebieden of gebeurtenissen die een potentiële ongewenste verandering op het project kunnen hebben. Als onderdeel van de processtap projectprestatie worden de prestatie gemeten op basis van de scope, tijdspad, kwaliteit, kosten en risicocriteria.

2.4.2 Risk IT In februari 2009 is door het ITGI een exposure draft uitgebracht van het “Risk IT” model, dat gerelateerd is aan COBIT. Het model is gebaseerd op de principes van COSO ERM en beschrijft hoe risicomanagement zou moeten worden ingericht rondom ICT. Het rapport beschrijft dat modellen van IT risicomanagement tot op heden voornamelijk zijn gericht op IT security. Risk IT is gericht op alle aspecten van IT-risico’s die onder te verdelen zijn in de volgende categoriën: § IT service delivery risico’s; deze risico’s worden geassocieerd met de performance en beschikbaarheid van

IT services en kunnen leiden tot vernietiging of verkleining van de waarde van IT services aan de bedrijfsvoering;

§ IT solution delivery/benefit realisation risico’s; deze risico’s worden geassocieerd met de bijdrage van IT aan nieuwe of verbeterde bedrijfstoepassingen, normaal gesproken in de vorm van ICT-projecten en programma’s;

§ IT benefit realisation risico’s; deze risico’s worden geassocieerd met (gemiste) kansen om technologie te gebruiken om de efficiency of effectiviteit van bedrijfsprocessen te verbeteren, of om technologie te gebruiken als enabler van nieuwe bedrijfsinitiatieven.

Figuur 2 illustreert de relaties tussen de risicocategorieën binnen dit model:

Figuur 2 Risicocategorieën Risk IT

Risico’s rondom ICT-projecten worden binnen het Risk IT model gezien als IT solution delivery/benefit realisation risico’s. Deze risico’s worden geassocieerd met de bijdrage van IT aan nieuwe of verbeterde bedrijfstoepassingen, in de vorm van ICT-projecten en programma’s. Het model biedt geen handreiking voor het uitvoeren van risicomanagement specifiek rondom ICT-projecten. Risico’s rondom ICT-projecten volgen

10

hetzelfde model van Risk IT als de overige IT-gerelateerde risicocategorieën. Risk IT argumenteert dat IT-risico’s altijd bestaan, ongeacht of deze worden gedetecteerd of herkend door een organisatie. Het gaat hier om bedrijfsrisico’s gerelateerd aan het gebruik van IT. Het model is berust op de volgende principes: 1. Effectieve besturing van IT-risico’s binnen en rondom de organisatie; 2. Effectief management van IT-risico’s.

2.4.2.1 Effectieve besturing van IT-risico’s binnen en rondom de organisatie In alle gevallen dient te worden geborgd dat er een aansluiting tussen IT-risico’s en bedrijfsdoelen plaatsvindt. Hiervoor hanteert Risk IT de volgende uitgangspunten: § IT risico wordt behandeld als bedrijfsrisico; § IT risicomanagement is een business enabler, en niet een hinderlijk obstakel; § De focus ligt op de uitkomsten van bedrijfsdoelen. IT risico wordt uitgedrukt als de impact die het kan

hebben op het behalen van de bedrijfsdoelen of strategie. Bij het vertalen van IT-risico’s naar impact op de bedrijfsvoering kunnen bijvoorbeeld de COBiT kwaliteits-/informatiecriteria (effectiviteit, efficiency, integriteit, etc) of COBiT bedrijfsdoelen (financieel, client, intern, groei) worden gebruikt.

Het Risk IT model beschrijft voorts dat het management van IT-gerelateerde risico’s in afstemming moeten zijn met het organisatiebrede risicobeheersingsysteem, bijvoorbeeld op het gebied van “risk appetite” en “risk tolerance” en management commitment.

2.4.2.2 Effectief management van IT-risico’s Voor het bewerkstelligen van een effectief beheersingsysteem van IT-risico’s volgens het Risk IT-model, is het van belang dat organisaties de volgende elementen toepassen: § Het stimuleren van eerlijke en open communicatie ten aanzien van IT-risico’s, waarbij openlijke, accurate,

tijdige en transparante informatie wordt gedeeld ten aanzien van IT-risico’s. Dit dient als basis voor alle risicogerelateerde besluiten;

§ Het realiseren van de juiste stimulans vanuit het topmanagement, terwijl: o sleutelpersonen zijn betrokken bij IT risicomanagement; o duidelijke taken en acceptatie van risico-eigenaarschap zijn verdeeld; o een risicobewuste cultuur wordt gestimuleerd vanuit het topmanagement; o besluiten ten aanzien van IT-risico’s worden genomen door daartoe geautoriseerde individuen met een

focus op bedrijfsmanagement. § Het uitvoeren van IT risicomanagement als een continu proces en als onderdeel incorporeren in de dagelijkse

werkzaamheden. Als gevolg van de dynamische aard van risico’s is IT risicomanagement een iteratief, duurzaam en continu proces. Elke verandering, organisatorisch of gerelateerd aan wetgeving, IT of bedrijfsvoering – brengt risico’s en/of kansen met zich mee en de organisatie bereid zich hier op voor door middel van risicomanagement. Over de hele organisatie wordt adequate aandacht gegeven aan consistente risicoanalyse methoden, rollen en verantwoordelijkheden, technieken en criteria.

2.4.2.3 Processen ICT risicomanagement De processen voor IT risicomanagement kunnen volgens Risk IT worden onderverdeeld in drie domeinen, te weten “Risk Governance”, “Risk Evaluation” en “Risk Response”. Adequate communicatie tussen deze domeinen staat centraal. Het Risk Governance-domein waarborgt dat de uitvoering van IT risicomanagement verweven is binnen de organisatie met als doel een optimale “risk-adjusted return” te bereiken. Het Risk Evaluation-domein waarborgt dat IT-gerelateerde risico’s en kansen worden geïdentificeerd en geanalyseerd en worden gepresenteerd in begrijpelijke bedrijfstermen. Het Risk Response-domein waarborgt dat IT-gerelateerde risico issues, kansen en gebeurtenissen worden geadresseerd op een kosteneffectieve wijze en in overeenstemming met de bedrijfsprioriteiten. Ter illustratie van deze domeinen en de onderliggende verbindingen is het Risk IT procesmodel opgenomen in bijlage 2 (figuur 2 en 3).

2.4.3 CMMi Het Capability Maturity Model (hierna: CMMi) is een procesverbeteringsmodel dat organisaties de nodige elementen biedt om te komen tot een effectief proces van systeemontwikkeling. Binnen CMMi zijn een vijftal niveaus van volwassenheid gedefinieerd, inclusief procesdoelen, die een basis vormen voor continu procesverbetering van het systeemontwikkelingsproces. De kenmerken van deze niveaus zijn: (Harmon, 2003)

11

1. Initial level – het systeemontwikkelingsproces wordt gekarakteriseerd door een set van ad hoc activiteiten . Er zijn geen tot weinig expliciet gedefinieerde processen, en het succes van projecten is afhankelijk van individuele inspanningen;

2. Repeatable level – op dit niveau worden basis projectmanagementactiviteiten uitgevoerd voor het monitoren van de planning, kosten en oplevering van het softwareproduct. De discipline is beschikbaar om eerder behaalde successen bij vergelijkbare projecten te herhalen;

3. Defined level – het proces voor zowel de beheersing als de uitvoering van de complete levenscyclus van informatiesystemen is geformaliseerd en gedocumenteerd. Voorts wordt een geautoriseerde versie door het management van dit proces gebruikt bij alle projecten;

4. Managed level – het systeemontwikkelingsproces en de kwaliteit van het softwareproduct worden gemeten en de resultaten hiervan worden vastgelegd. Zowel dit proces als de ontwikkelde producten worden kwantitatief geanalyseerd en beheerst;

5. Optimizing level – op basis van kwantitatieve feedback vanuit het proces en innovatieve ideeën en technologieën wordt continu procesverbetering mogelijk gemaakt.

Voor het bereiken van het CMM niveau drie en de daarop volgende niveaus, is het van wezenlijk belang dat risicomanagement in het systeemontwikkelingsproces is geïmplementeerd en verankerd (Elieson, 2006). Dit kan worden bewerkstelligd bij de beheersing van de levenscyclus van het informatiesysteem en de toepassing van een projectmanagement methodologie gedurende het systeemontwikkelingsproces.

2.5 Risicomanagement gericht op ICT-gerelateerde projecten In deze paragraaf wordt ingegaan op een aantal modellen voor risicomanagement gericht op ICT-gerelateerde projecten, namelijk: a) Prince2, b) NIST en c) Val IT. Een project is een tijdelijke organisatievorm die nodig is om een uniek en vooraf gedefinieerd product te maken of resultaat te behalen op een vooraf afgesproken tijdstip, gebruikmakend van vooraf vastgestelde middelen (Onna, e.a., 2007). ICT-gerelateerde projecten worden uitgevoerd voor het ontwikkelen en implementeren van informatiesystemen binnen organisaties. Door de omvang en complexiteit van de systemen en de impact hiervan op de organisatie, verloopt de uitvoering van deze projecten veelal niet zonder risico’s. Om een project op een beheerste wijze uit te kunnen voeren, wordt door organisaties vaak gebruik gemaakt van een projectmanagement methodologie. Prince2 is een van de meest bekende en gebruikte projectmanagement methodieken en kan bijdragen aan een adequate beheersing van een project en de bijbehorende risico’s.

2.5.1 Projects in Controlled Environments (Prince2) Prince2 is oorspronkelijk ontwikkeld door het Britse Central Computer & Telecommunications Agency (CCTA) met als doel om te waarborgen dat het resultaat van projecten op een beheerste wijze conform de gedefinieerde acceptatiecriteria worden opgeleverd. Deze projectmanagementmethode maakt gebruik van een procesmatige aanpak die uit de volgende acht hoofdprocessen bestaat: (van Praat en Suerink, 2004) § Opstarten van een project: nadat een haalbaar projectvoorstel is gemaakt door de organisatie, dan is het

volgens Prince2 verantwoord om met een project te beginnen; § Initiëren van een project: na goedkeuring van het projectvoorstel door het management, wordt dan het

projectinitiatiedocument (PID) vervaardigd waarin onder meer de resultaten van het haalbaarheidsonderzoek (business case) zijn opgenomen, de op te leveren softwareproducten, de te stellen kwaliteitseisen aan de producten en de projectbeheersing;

§ Dirigeren van een project: de start, fasering en einde van het project wordt bepaald door de stuurgroep. Voorts definieert de stuurgroep de marges en richtlijnen waarbinnen de projectmanager dient te werken;

§ Beheersen van een fase: dit proces beschrijft de beheersingsactiviteiten die door de projectmanager moeten worden uitgevoerd, zoals planning, voortgangsbewaking, kwaliteitsborging en de wijze waarop wijzigingsverzoeken dienen te worden afgehandeld;

§ Managen van productoplevering: in deze fase worden de activiteiten en verantwoordelijkheden beschreven voor de projectmedewerkers, zodat het beoogde resultaat wordt gerealiseerd;

§ Managen van faseovergangen: de activiteiten die moeten worden uitgevoerd voor de informatieverstrekking aan en besluitvorming door de stuurgroep worden in dit proces beschreven. Deze informatie, inclusief geconstateerde afwijkingen van richtlijnen en margeoverschrijdingen, dient minimaal te worden verstrekt over het einde van een fase. Op basis hiervan neemt de stuurgroep voorts go/no go-beslissingen;

12

§ Afsluiten van een project: dit proces beschrijft de structuur van de beëindiging van het project, de acceptatie en overdrachtprocedures aan de gebruikersorganisatie;

§ Opstellen van een plan: de overkoepeling van alle PRINCE2-processen om het globale projectplan en de gedetailleerde faseplannen te vervaardigen worden in dit proces beschreven.

Daarnaast beschrijft dit gestructureerde projectmanagement methodologie acht specifieke componenten voor het minimaliseren van projectrisico’s. Hiertoe behoren: (van Praat en Suerink, 2004) § Organisatie: deze component beschrijft de verantwoordelijkheden, taken en bevoegdheden van de diverse

rollen binnen de projectorganisatie; § Plannen: voor de beheersing van het softwareontwikkelingsproces zijn plannen benodigd. Hiervoor

definieert PRINCE2 het globale projectplan en de gedetailleerde faseplannen; § Beheersing: het opstellen van procedures voor de informatieverstrekking over de voortgang en afwijkingen

(scope, tijd, geld, risico’s en kwaliteit) zodat het mogelijk is om gedurende het project tijdig bij te sturen; § Fasen: het opdelen van een project in meerdere fasen om minder complexe deelprojecten te creëren

waardoor mogelijk de beheersing wordt verbeterd; § Risicobeheer: richtlijnen moeten worden opgesteld door de stuurgroep voor het analyseren en beheersen van

risico’s; § Kwaliteitsbeheer: softwareproducten moeten conform de vooraf gespecificeerde kwaliteitseisen worden

ontwikkeld. Bovendien dient een product pas goedkeuring te krijgen als het voldoet aan de eisen uit de productspecificatie;

§ Configuratiebeheer: het identificeren, registreren en volgen van alle producten, inclusief projectdocumentatie, gedurende het project;

§ Wijzigingsbeheer: wijzigingsverzoeken binnen het project moeten worden beoordeeld, goedgekeurd en beheerst, waarbij de impact op de scope, tijd, geld, risico’s en kwaliteit in kaart moeten worden gebracht.

2.5.2 NIST De Computerbeveiliging divisie van het Amerikaanse National Institute of Standards and Technology (hierna: NIST) heeft een risicomanagement methode ontwikkeld die bij projecten en gedurende de ontwikkeling van informatiesystemen kan worden gebruikt. Voorts kan deze richtlijn worden toegepast bij organisaties in zowel de publieke als private sector. Deze methode heeft als doel om een fundament te bieden voor de ontwikkeling van een effectief risicobeheersingprogramma die de benodigde definities en praktijkgerichte richtlijnen bevat voor het beoordelen en mitigeren van de geïdentificeerde risico’s binnen informatiesystemen (Stoneburner e.a., 2002).

2.5.2.1Levenscyclus van informatiesystemen Een effectief systeem van risicomanagement dient verder volledig geïntegreerd te zijn met het systeemontwikkelingsproces. De levenscyclus van een informatiesysteem bestaat uit de volgende vijf fases: (Stoneburner e.a., 2002). § Initiatie; § Ontwikkeling of Acquisitie; § Implementatie; § Exploitatie en Beheer; § Uitfasering. Hoewel binnen het ontwikkelingsproces van een informatiesysteem, een aantal van de bovengenoemde fasen parallel kunnen worden doorlopen, dient de gebruikte methode van risicomanagement identiek te zijn voor alle fasen uit de levenscyclus van het informatiesysteem. Risicomanagement is derhalve een iteratief proces dat kan worden uitgevoerd gedurende elke relevante fase van het systeemontwikkelingsproces. De NIST-methode heeft voorts in kaart gebracht hoe risicomanagement kan worden uitgevoerd en ter ondersteuning kan worden gebruikt per fase uit het systeemontwikkelingsproces: (Stoneburner e.a., 2002)

Softwareont-wikkelingsfase

Fase-eigenschappen Ondersteuning van risicomanagement-activiteiten

Fase 1 - Initiatie De behoefte voor een informatiesysteem is kenbaar gemaakt en het doel inclusief de scope van de systeem is gedocumenteerd

Geïdentificeerde risico’s worden gebruikt ter ondersteuning voor het ontwikkelen van systeemspecificaties, inclusief beveiligingseisen en een beveiligingsplan voor de IT-beheerprocessen

13

Softwareont-wikkelingsfase

Fase-eigenschappen Ondersteuning van risicomanagement-activiteiten

Fase 2 – Ontwikkeling of

Acquisitie

Het IT-systeem is ontworpen, geacquireerd of ontwikkeld De geïdentificeerde risico’s gedurende deze fase kunnen worden gebruikt ter ondersteuning voor de analyse ten aanzien van de beveiliging van het

IT-systeem, die kunnen leiden tot beheerste en gebalanceerde wisselwerking tussen architectuur en ontwerp

Fase 3 - Implementatie

De instellingen van de systeembeveiliging dienen te worden geconfigureerd, geactiveerd, getest en geverifieerd

Het risicomanagement proces ondersteunt de verificatie van de systeemimplementatie ten opzichte van de afgestemde systeemspecificaties en de ontworpen operationele omgeving.

Fase 4 – Exploitatie en Beheer

Het systeem functioneert. Kenmerkend voor deze fase is door veranderingen in de organisatie, processen en/of procedures, worden wijzigingen op een regelmatige basis doorgevoerd ten aanzien van de hardware en software

Risicomanagement activiteiten worden uitgevoerd ten behoeve van periodieke beoordeling van de systeemautorisaties.

Fase 5 - Uitfasering

Deze fase heeft betrekking op de uitfasering van de hardware, software en informatie.

Risicomanagement activiteiten worden uitgevoerd voor systeemcomponenten die worden uitgefaseerd, zodat kan worden geborgd

dat residuale data adequaat wordt afgehandeld en dat systeemintegratie wordt uitgevoerd op een beheerste en systematische wijze.

Tabel 1 Systeemontwikkeling en geïntegreerd risicomanagement

2.5.3 Val IT Het Val IT model (ITGI, 2008) is totstandgekomen met als doel organisaties te helpen met het meten, monitoren en optimaliseren van de realisatie van bedrijfswaarde uit IT investeringen en organisatorische veranderingen als gevolg van IT. Aan de basis hiervan ligt het feit dat veel grootschalige IT-investeringen en IT-gerelateerde veranderingen zijn mislukt of niet het beoogde rendement hebben gebracht voor de organisatie.

Figuur 3 Statistieken inzake het rendement van IT-investeringen (ITGI, 2008) Verder worden een aantal illustraties van mislukkingen gegeven: § Nike heeft meer dan 200 miljoen dollar gerapporteerd aan verlies als gevolg van problemen rondom de

implementatie van haar supply chain software; § Tokyo Gas heeft een verlies van 46,6 miljoen dollar gerapporteerd als gevolg van het stopzetten van een

grootschalig CRM project; § in de publieke sector, heeft het Engelse Ministerie van Arbeid en Pensioenen meer dan 2 miljard pond verlies

geleden als gevolg van het stopzetten van drie grote ICT-projecten. Val IT biedt een antwoord op de vraag wat er benodigd is binnen organisaties om zorg te dragen voor het verkrijgen van positieve bedrijfswaarde uit IT. IT-gerelateerde investeringen kunnen van grote waarde zijn voor organisaties, maar alleen met de juiste besturing en management processen. Het model is complementerend aan het COBIT model.

2.5.3.1Val IT principes De Val IT principes zijn als volgt: § IT-gerelateerde investeringen worden gemanaged als een portfolio van investeringen; § IT-gerelateerde investeringen omvatten alle activiteiten die benodigd zijn om de potentiële bedrijfswaarde te

realiseren, ook op het gebied van de bedrijfsvoering, -processen, etc; § IT-gerelateerde investeringen worden gemanaged in de gehele economische levenscyclus; § Value delivery praktijken:

o erkennen dat er verschillende investeringscategorieën bestaan, die op een verschillende/specifieke wijze dienen te worden geëvalueerd en gemanaged;

o definiëren en monitoren de kritieke prestatie indicatoren en reageren voorspoedig op veranderingen of afwijkingen;

14

o betrekken alle stakeholders en kennen verantwoordelijkheden toe voor de aanlevering van capaciteiten en de realisatie van bedrijfswaarde;

o worden continu bewaakt, geëvalueerd en verbeterd waar mogelijk. De organisatie dient te begrijpen dat IT geen doel op zich is maar een middel om bedrijfsuitkomsten te realiseren. Verder dient binnen de organisatie consistentie aanwezig te zijn wat betreft gebruikte terminologie.

2.5.3.2 Val IT domeinen en processen Val IT gaat specifiek in op structuren en processen rondom drie best practice domeinen, te weten: § Value Governance; het volwassenheidsniveau van de waardemanagement praktijken binnen de organisatie; § Portfolio Management; het managen van het portfolio aan IT-gerelateerde investeringen op het gebied van

optimale bedrijfswaarde; § Investment Management; de contributie van individuele IT-gerelateerde investeringen aan optimale

bedrijfswaarde (zie figuur 4 hieronder).

Figuur 4 Val IT best practice domeinen (ITGI, 2008) Val IT heeft een vijftal volwassenheidsniveaus gedefinieerd aan de hand van een aantal aspecten voor de beheersing van investeringen. Dit maturity model is opgenomen in bijlage 3.

2.5.3.3 Val IT en risicomanagement Gedurende het uitvoeren van Portfolio- en Investment Management speelt risicomanagement een grote rol, met als doel het verkrijgen van (de beoogde) positieve bedrijfswaarde uit de investering. De risicogerelateerde processen zijn erop gericht om de impact van mogelijke negatieve scenario’s te minimaliseren en het volledige voordeel te verkrijgen uit kansen tot verbetering. Het model argumenteert dat bij vrijwel elke processtap heroverweging van risico’s dient plaats te vinden. De volgende aspecten van risico’s worden onderscheiden binnen het Val IT model:

Delivery risk—Het risico op het niet leveren van de beoogde capaciteiten.

Benefits risk—Het risico op het niet behalen van de beoogde resultaten/voordelen.

Voorbeelden van risico drivers: – Kwaliteit van het programma en project plan; – Duidelijkheid van de scope en deliverables; – Niet bewezen technologie;

– Compliance aan technologische architectuur en standaarden;

Voorbeelden van risico drivers: – Geen afstemming met commerciële richtlijnen of strategie; – Geen afstemming met technische standaarden, architectuur, etc; – Compliance met beveiligingsrichtlijnen/ standaarden;

– Duidelijkheid/aannemelijkheid van gewenste bedrijfsuitkomsten;

15

Delivery risk—Het risico op het niet leveren van de beoogde capaciteiten.

Benefits risk—Het risico op het niet behalen van de beoogde resultaten/voordelen.

– Duur van projecten; – Grootte van projecten in relatie tot eerdere succesvolle projecten;

– Interfaces met bestaande systemen en processen; – Mate van betrokkenheid van senior staf bedrijfsvoering; – Ervaring/kwaliteit van de betrokken project managers en project teams; – Afhankelijkheid van leveranciers en factoren die buiten controle vallen van project teams; – Kwaliteit van risicobeheersing mechanismen;

– Het vermogen om aanhoudende operationele ondersteuning te leveren.

– Meetbaarheid en monitoring rondom uitkomsten; – Gevoeligheid voor timing of externe afhankelijkheden, inclusief

wijzigingen in de economie, marktcondities of een specifieke industriesector; – De mate waarin organisatorische verandering is vereist; – De kwaliteit van het wijzigingsbeheer plan voor de organisatie; – De mate van bedrijfsorganisatorisch draagvlak en begrip; – Beschikbaarheid van financiële steun vanuit de bedrijfsvoering; – Mate van betrokkenheid van senior staf bedrijfsvoering;

– De mate waarin het programma is opgesplitst in fasen, zodat geen ‘big bang’ aanpak hoeft te worden gehanteerd.

Tabel 2 Val IT risicocategorieën (ITGI, 2008) Een belangrijke risico driver is volgens het Val IT model de mogelijkheid of bereidwilligheid van organisaties ten aanzien van het maken van betrouwbare en accurate voorspellingen van kosten, uitkomsten en profijt uit projecten. Dit betreft beide risicoaspecten, dus zowel delivery als benefits risico’s. Om het risico op onterechte acceptatie of verwerping van projecten te verkleinen zou de risicoanalyse kunnen worden uitgevoerd door een van het programma onafhankelijk orgaan.

2.6 Toepassing ICT risicomanagement binnen organisaties In deze paragraaf wordt op grond van literatuuronderzoek beschreven in hoeverre risicomanagement wordt toegepast binnen organisaties, in het algemeen en specifiek in relatie tot ICT-projecten. De beheersing van risico’s op het vlak van de organisatie, processen en techniek ten opzichte van de beheersing van IT-risico’s binnen projecten kan een organisatie in staat stellen om onzekerheden in de IT omgeving adequaat te beheersen.

2.6.1 Toepassing ICT risicomanagement binnen organisaties In 2007 is een wereldwijde survey uitgevoerd naar het managen van IT-risico’s binnen de financiële sector (Ernst & Young, 2007). Op een vijftal gebieden zijn geconstateerde positieve trends en verbeterpunten beschreven in het rapport (zie tabel in bijlage 4). Rondom alle gebieden zijn verbeteringen ten opzichte van voorgaande onderzoeken geconstateerd maar uit het onderzoek blijkt dat bij veel financiële instellingen nog steeds verbeteringen benodigd zijn op het gebied van risicomanagement. Voorbeelden zijn de mate van (formele) toepassing van risicomanagement, afstemming van ICT risicomanagement op het bedrijfsbrede programma en een holistische aanpak. Risicomanagement wordt bij veel organisaties gezien als een project, niet als een continu proces. Ondanks dat risicoanalyses zijn gespecificeerd in bepaalde voorschriften en standaarden, hebben vele organisatie geen formele processen hiervoor geïmplementeerd. Oorzaak hiervan is bijvoorbeeld dat bedrijven hierin geen toegevoegde waarde zien of niet de beschikking hebben over voldoende hierin geschoold personeel. Uit de theorie blijkt dat risicoanalyses op zichzelf staand niet voldoende zijn om risico’s adequaat te managen. Daarvoor dienen risicoanalyse processen te worden ondergebracht als onderdeel van een wijder, continu risicomanagement programma, inclusief continue communicatie en afstemming met de business. Binnen vele organisaties waar risicomanagement op de agenda staat zijn processen niet in genoemde diepgang geïmplementeerd en/of geaccepteerd. Bedrijven zijn doorgaans geneigd te kiezen voor een relatief simpele aanpak voor risicoanalyse dat slechts beperkte tijd in beslag neemt van betrokken IT en business medewerkers (Symantec, 2007 en 2008). Risicomanagement wordt voorts bij veel organisaties voornamelijk benaderd vanuit security perspectief en te weinig vanuit de perspectieven compliance, beschikbaarheid en performance. IT-risico’s rondom deze gebieden dienen tevens te worden meegenomen gedurende het tot uitvoering brengen van adequaat risicomanagement (Symantec, 2007 en 2008).

16

Figuur 5. IT-risico’s omvatten vier typen elementen, waarbij elk element zijn eigen drivers en potentiële impact kent

Uit de theorie blijkt dat veel bedrijven in de praktijk worstelen met het geven van adequate invulling aan risicomanagement. Een aantal belangrijke verbeterpunten zijn mogelijk op dit gebied die organisaties in staat kunnen stellen risico’s op systematische, continu en adequate wijze te identificeren en te managen.

2.6.2 Risicomanagement rondom ICT-projecten

2.6.2.1Mate van toepassing Risicomanagement modellen en processen dienen de aspecten integriteit, vertrouwelijkheid, beschikbaarheid, beveiliging en snelheid van informatie te adresseren, dat wordt gecreëerd, verwerkt en gedeeld binnen en buiten de organisatie. Wanneer deze aspecten in gevaar worden gebracht kan dit leiden tot een substantiële negatieve financiële impact of reputatieverlies (cio.com, 2008). De mate waarin risicomanagement wordt toegepast binnen projecten is onlosmakelijk verbonden met de succesvolle uitvoering hiervan. Uit onderzoek van Bisnez Management onder 230 Nederlandse bedrijven is gebleken dat ongeveer 26 procent van de respondenten voorafgaand aan de start van het project risicomanagement toepast. Circa 13 procent doet dit tijdens het project en bijna 43 procent past risicomanagement cyclisch toe. 18 procent maakt geen gebruik van risicomanagement. Uit het onderzoek is tevens gebleken dat het cyclisch uitvoeren van risicomanagement tot de grootste tevredenheid leidt (MCA, 2007). Bij een adequate, cyclische uitvoering van risicomanagement rondom ICT-projecten dienen een minimaal aantal mijlpalen te worden meegenomen (NOREA, 2005):

Figuur 6. Mijlpalen risicomanagement rondom ICT-projecten.

17

Uit onderzoek (Ernst & Young, 2007) blijkt voorts dat 56,8% van de ondervraagde financiële instellingen risicomanagement uitvoert rondom ICT projecten/initiatieven. 39,6% voert monitoring uit op IT-risico’s rondom ICT projecten/initiatieven en 3,6% voert geen van beiden uit (zie bijlage 4). Uit de theorie blijkt dat het belang van adequaat risicomanagement specifiek in relatie tot projecten groot is, maar dat veel bedrijven in de praktijk worstelen met het geven van invulling hieraan.

2.6.2.2Risicocategorieën Op basis van de ‘risicostaalkaart’ (Van Strijen en Kleyn, 1994) kunnen acht risicocategorieën van elkaar worden onderscheiden rondom ICT-projecten:

De eerste vier aandachtsgebieden hebben betrekking op de (complexiteit van de) omgeving van het project, de laatste vier op de projectbeheersing. Volgens de theorie wordt minstens de helft van het projectresultaat bepaald door de omgeving en de andere helft door de manier van beheersing. Het risicoprofiel van een project bestaat uit de complexiteit in combinatie met de risico’s die voortkomen uit de mate van beheersing. Complexiteit heeft te maken met de uitgangspunten, de doelstellingen en de resultaten van een project. Uit onderzoek van Bisnez Management (MCA, 2007) kwam het volgende naar voren: § de technische complexiteit wordt nog steeds onderschat bij ICT-projecten. Degelijk huiswerk vooraf, een

goed (gedocumenteerd) beeld van het bestaande ICT-landschap en veel aandacht voor integratie tijdens de projectuitvoering blijven nog steeds noodzakelijk;

§ zeker bij grotere geïntegreerde projecten blijkt de sociale complexiteit nog steeds het grootste risicogebied. Bij geïntegreerde projecten waar ICT maar een onderdeel is van de totale transitie, geven vrijwel alle geënquêteerden aan dat de inpassing van de ‘nieuwe werkwijze’ in de bestaande situatie het belangrijkst is.

2.7 Het Negenvlaksmodel Het Negenvlaksmodel is niet direct een raamwerk voor het beheersen van IT-risico’s, maar een model voor informatiemanagement (hierna: IM) dat in 2003 werd geïntroduceerd door Prof. dr. ir. R. Maes. Zoals immers is gesteld in paragraaf 2.1, zal het management over informatie willen en moeten beschikken om adequaat te kunnen reageren op de geïdentificeerde risico’s in hun specifieke omgeving. Het Negenvlaksmodel biedt een hulpmiddel, gebaseerd op de volgende uitgangspunten: (Maes, 2003) 1. De beheersing van informatie als een bedrijfsmiddel; en 2. Het managen van de business en ICT relatie. Deze uitgangspunten worden verder in dit onderzoek gebruikt om te kunnen interpreteren welke aspecten volgens het Negenvlaksmodel een rol spelen tussen de vraag en aanbod van informatie binnen organisaties en bij de beheersing van ICT-projecten. Hierop wordt in paragraaf 2.7.1 nader ingegaan. Vervolgens wordt op basis hiervan in paragraaf 2.7.2 de sterktes en zwaktes van de reeds behandelde risicomanagement modellen in kaart gebracht voor het samenstellen van een theoretisch kader voor de beheersing van risico’s bij projecten.

2.7.1 Bruikbaarheid voor probleemstelling Zoals gesteld in paragraaf 2.2, kunnen projecten een significante impact hebben op een (deel) van de organisatie. Hierdoor moeten deze projecten niet alleen tot het domein van IT worden gerekend. Indien het succes van IT-projecten in gevaar komt, kunnen diverse bedrijfsoorzaken hiermee te maken hebben. Het Negenvlaksmodel onderscheidt drie besturingslagen die op de IM-kaart op de verticale as zijn gemarkeerd: (Maes, 2003) § Strategie (richten); § Structuur (inrichten); § Operations (verrichten).

a. Projectuitgangssituatie: opdrachtformulering, specificaties, stabiliteit projectomgeving etc. b. Projectdoelstellingen en afstemming op de bedrijfsdoelstellingen. c. Sociale/organisatorische complexiteit. d. Technische/functionele complexiteit: infrastructuur, interfaces, bediening, migratie etc. e. Projectmedewerkers: beschikbare capaciteit, verloop, deskundigheid etc. f. Projectorganisatie: verantwoordelijkheden en bevoegdheden, communicatie, besluitvorming etc. g. Projectbeheer en beheersing: fasering, planning, bijsturing, begroting, kwaliteitssysteem etc. h. Projecthulpmiddelen en -technieken: procedures en richtlijnen, relatie met leveranciers etc.

18

Informatiemanagement relateert voorts de processen van en de ondersteunende technologie voor (intern en extern) informeren en communiceren aan algemene businessaspecten, die op de IM-kaart op de horizontale as worden aangegeven: (Maes, 2003) § Bedrijfsdomein – op basis van de omgeving van de organisatie wordt de te volgen bedrijfsstrategie

geformuleerd; § Informatie en Communicatie – de wijze waarop informatie en communicatie processen plaatsvinden en de

mate waarop de IT functie ondersteuning biedt aan deze processen; § Technologie – de wijze waarop invulling is gegeven aan de informatievoorziening binnen de organisatie. In de figuur opgenomen in bijlage 5 is informatiemanagement in relatie tot de drie besturingsniveaus en de drie domeinen weergegeven als het Negenvlaksmodel. Het Negenvlaksmodel illustreert dat veranderingen in de bedrijfsstrategie vaak een impact hebben op zowel de inrichting als de uitvoering van de bedrijfsprocessen. Hierdoor komen veelal ook veranderingen ten aanzien van de informatie- en communicatiebehoefte tot stand, waardoor bijgevolg veranderingen noodzakelijk kunnen zijn van de IT functie binnen de organisatie. Verder wordt in dit model de onderlinge relaties duidelijk in kaart gebracht door middel van de verbindingswegen tussen de diverse gebieden die in samenhang dienen te zijn. IT-projecten zijn veelal het resultaat van de wisselwerking die continu plaatsvindt tussen de business en ICT. Het is hier derhalve van wezenlijk belang dat de relatie tussen de business en ICT wordt beheerst binnen organisaties. Dit aspect komt naadloos overeen met het informatiemanagement element over de beheersing van de business en ICT relatie. Daarnaast wordt bij een IT-project vaak een informatiesysteem of de acquisitie van een softwareproduct als projectresultaat opgeleverd. De implementatie hiervan binnen organisaties heeft betrekking op zowel het vlak van de inrichting als van de verrichting van het technologisch domein. Dit omdat bij de inrichting van het technologisch domein wordt het nieuwe systeem in productie genomen voor gebruik door de business en bij de verrichting van dit domein wordt het systeem geëxploiteerd en beheerd. Doorgaans valt dit onder het informatiemanagement element over de beheersing van informatie als een bedrijfsmiddel. Aangezien het object van onderzoek betrekking heeft op ICT-projecten, zijn de relevante gebieden van het Negenvlaksmodel voor de probleemstelling groen gearceerd, zoals aangegeven in figuur 7.

Figuur 7 Bruikbaarheid IM-kaart voor probleemstelling Op basis van figuur 7 worden de volgende besturingsniveaus en domeinen inclusief de onderlinge relaties geïdentificeerd die relevant zijn voor de probleemstelling: 1. Inrichting van het bedrijfsdomein; 2. Inrichting van het informatie- en communicatiedomein; 3. Inrichting van het technologisch domein; 4. Verrichting van het technologisch domein; 5. De relatie tussen de business en het informatie- en communicatiedomein;

19

6. De relatie tussen het informatie- en communicatiedomein en het technologisch domein.

2.7.2 Analyse van risicomanagement met het Negenvlaksmodel De Negenvlakskaart wordt in dit onderzoek gehanteerd als denkmodel om de sterktes en zwaktes in kaart te brengen van de behandelde theorie in de voorgaande paragrafen. Hierbij wordt tevens aangegeven wat de bruikbaarheid is per risicomanagement model voor ons onderzoek, aan de hand van figuur 7. Een scorekaart is opgesteld met een schaalverdeling die gebaseerd is op de zes geïdentificeerde punten in de voorgaande paragraaf. Deze analyse wordt in tabel 3 hieronder verder weergegeven.

Informatiemanagement elementen Model Managen van informatie als een

bedrijfsmiddel Managen van de business-ICT relatie Bruikbaarheid voor

probleemstelling COSO Sterktes:

• ERM waarborgt dat het management een risicobeheersingproces heeft voor de inrichting en verrichting van het bedrijfsdomein;

• Relevante informatie is geïdentificeerd, vastgelegd en gecommuniceerd;

Zwaktes: • De richting, inrichting en verrichting

van het IT domein wordt niet specifiek geadresseerd door dit model.

Sterktes: • Verantwoordelijkheden worden

verdeeld ten aanzien van de beheersing van de relatie tussen business en de informatie- en communicatie functie.

Zwaktes: • Verantwoordelijkheden worden niet

specifiek verdeeld ten aanzien van de beheersing van de relatie tussen de business en IT en de daarbij horende risico’s.

CobiT Sterktes: • CobiT biedt organisaties een raamwerk

voor de richting, inrichting en verrichting van het Informatie- en communicatiedomein;

• CobiT biedt organisaties een raamwerk voor de richting, inrichting en verrichting van het technologisch domein;


van het bedrijfsdomein wordt niet specifiek geadresseerd door Cobit.


verdeeld voor de beheersing van de relatie tussen het bedrijfsdomein en informatie- en communicatiedomein;

• Verantwoordelijkheden worden verdeeld voor de beheersing van de relatie tussen het informatie- en communicatiedomein en het technologisch domein.

Risk IT Idem als CobiT. Idem als CobiT. Idem als CobiT.

CMMi Sterktes: • CMMi biedt organisaties een

procesverbeteringsmodel voor de inrichting en verrichting van het technologisch domein;


van zowel het bedrijfsdomein als de informatie- en communicatie domein worden niet specifiek geadresseerd door CMMi;

• De richting van het technologisch domein wordt niet door CMMi behandeld.


specifiek verdeeld ten aanzien van de beheersing van de business en ICT relatie en de daarbij horende risico’s.

Laag

Hoog

Hoog

Laag

Hoog

Laag

20

Informatiemanagement elementen Model Managen van informatie als een

bedrijfsmiddel Managen van de business-ICT relatie Bruikbaarheid voor

probleemstelling Prince2 Sterktes:

• Prince2 waarborgt dat organisaties een gedefinieerd projectmanagement methodiek hanteren bij de beheersing van de inrichting en verrichting van het technologisch domein;


van zowel het bedrijfsdomein als de informatie- en communicatie domein worden niet specifiek geadresseerd door Prince2;

• De richting en verrichting van het technologisch domein wordt niet specifiek door Prince2 behandeld.

Sterktes: • De verantwoordelijkheden voor de

beheersing van het ontwikkelingstraject van informatiesystemen worden verdeeld;


specifiek verdeeld ten aanzien van de beheersing van de relatie tussen het bedrijfsdomein en de informatie- en communicatie functie.

NIST Sterktes: • NIST waarborgt dat organisaties een

geïntegreerd systeem hebben voor de beheersing van de inrichting en verrichting van het technologisch domein;


van zowel het bedrijfsdomein als de informatie- en communicatie domein worden niet specifiek geadresseerd door NIST;

• De richting van het technologisch domein wordt niet specifiek door NIST behandeld.




Val IT Sterktes: • Val IT waarborgt dat organisaties het

beoogde rendement behalen uit IT-gerelateerde investeringen voor zowel een adequate inrichting als verrichting van het technologisch domein;


van het bedrijfsdomein en de informatie- en communicatie domein worden niet specifiek geadresseerd door Val IT;

• Daarnaast wordt de richting van het technologisch domein niet specifiek geadresseerd door Val IT.




Tabel 3 Sterkte-zwakte analyse risicomanagement modellen

Hoog

Laag

Laag

Hoog

Hoog

Laag

21

Zoals in de tabel 3 hierboven wordt aangetoond, zijn een aantal risicomanagement modellen vergeleken met het Negenvlaksmodel en is aangegeven in welke mate deze frameworks bruikbaar zijn voor de beheersing van risico’s bij ICT-projecten. Het COSO framework is op basis hiervan minder bruikbaar voor de probleemstelling in het kader van dit onderzoek. Dit risicobeheersingmodel heeft een organisatiebreed karakter, dat gericht is op het identificeren van de relaties tussen de ondernemingsrisico’s en het interne beheersingsysteem waarbij een aansluiting wordt gemaakt met de doelstellingen van de organisatie. Daarnaast is geconstateerd dat het CMMi model ook een relatief laag bruikbaarheidgehalte heeft binnen dit onderzoek. CMMi biedt een procesverbeteringsmodel voor de inrichting en verrichting van het technologisch domein, maar geen richtlijnen voor de beheersing van projecten. Het CobiT- en Risk IT framework kunnen worden gezien als de specifieke invulling van COSO op het gebied van IT. Prince2, NIST en Val IT geven invulling aan COSO, CobiT en Risk IT aan de hand van gedefinieerde richtlijnen voor de inrichting, uitvoering en beheersing van ICT-projecten. De modellen die relatief hoog hebben gescoord (drie of meer groengekleurde vlakken), worden gebruikt om bouwstenen te identificeren voor verdere analyse. Op basis hiervan wordt een theoretisch kader opgesteld in hoofdstuk 3.

22

3 Theoretisch kader In hoofdstuk 2 zijn een aantal theoretische risicomanagement modellen nader toegelicht en is op basis van het Negenvlaksmodel aangegeven in welke mate deze modellen bruikbaar zijn voor het adequaat beheersen van risico’s bij projecten. Het resultaat hiervan wordt in dit hoofdstuk gebruikt om een theoretisch kader samen te stellen voor de beheersing van ICT-projecten. Het onderliggende resultaat van deze analyse is opgenomen als tabel in bijlage 6. Op basis van de diverse theorieën wordt hieronder het theoretische kader weergegeven.

Doel Adequaat risicomanagement rondom ICT-projecten en daarmee het verkrijgen van (de beoogde) positieve bedrijfswaarde uit IT-gerelateerde investeringen. Principes § betrouwbare en accurate voorspellingen van kosten en uitkomsten; § aansluiting tussen IT-risico’s en bedrijfsdoelen; § effectief management van IT-risico’s als continu proces en als onderdeel van de dagelijkse

werkzaamheden; § Portfolio Management gericht op potentiële bedrijfswaarde van investeringen en realisatie

hiervan; § definiëren en monitoren van KPI’s; § volledige integratie risicomanagement met systeem ontwikkelingsproces. Processen a) Value/Risk Governance; b) Portfolio Management; c) Investment Management; Risk Analysis, -Evaluation en –Response worden uitgevoerd als onderdeel van Portfolio- en Investment Management. De business case, risicoheroverweging en monitoring staan gedurende de gehele levenscyclus van de investering centraal in het kader van risicomanagement. Voorts wordt risicomanagement tenminste uitgevoerd bij de volgende mijlpalen: § Project preparation; § Business blueprint; § Realisatie; § Going life; § Post implementatie. Risicocategorieën Risicomanagement dient tenminste te zijn gericht op de volgende risicocategorieën: – a) Delivery risk—Het risico op het niet leveren van de beoogde capaciteiten. – b) Benefits risk—Het risico op het niet behalen van de beoogde resultaten/voordelen. Risicomanagement dient te worden uitgevoerd bij alle fasen uit het systeem ontwikkelingsproces en tenminste bij de vijf mijlpalen. De complexiteit van ICT-projecten dient te worden beheerst op basis van de interne risicocategorieën (bijv. projectbeheer en –beheersing) en de categorieën die worden opgelegd uit de omgeving (bijv. sociale/organisatorische complexiteit). Verantwoordelijkheden De Project Manager is verantwoordelijk voor risicomanagement en dient grip te houden op complexiteit door middel van adequaat en continu risicomanagement. Prestatiemeting dient te worden uitgevoerd door een onafhankelijk daarin gespecialiseerd orgaan. Informatiemanagement De relatie tussen de business en ICT dient continu te worden beheerst door de projectmanager.

23

4 Faalfactoren ICT-projecten overheid in de praktijk versus theoretisch toetsingskader

In dit hoofdstuk wordt op grond van de lessen uit ICT-projecten bij de overheid in de praktijk (rapport Algemene Rekenkamer) beschreven in welke mate de faalfactoren rondom ICT-projecten binnen de publieke sector worden geadresseerd in het opgestelde theoretisch kader in hoofdstuk 3. Voordat deze analyse wordt uitgevoerd, wordt nader ingegaan op de achtergrond (paragraaf 4.1) en faalfactoren (paragraaf 4.2) ten aanzien van ICT-projecten bij de overheid. Vervolgens wordt in paragraaf 4.3 in kaart gebracht in hoeverre deze faalfactoren worden geadresseerd in het opgestelde theoretisch kader zoals beschreven in hoofdstuk 3.

4.1 Achtergrond ICT-projecten bij de overheid De rekenkamer heeft in 2007 (29 november 2007, deel A) en 2008 (1 juli 2008, deel B) twee rapporten gepubliceerd genaamd “Lessen uit ICT-projecten bij de overheid”. Deze onderzoeken zijn uitgevoerd omdat er vele voorbeelden zijn dat projecten veel duurder worden dan gedacht, meer tijd vragen dan gepland of niet het gewenste resultaat leveren. Problemen die volgens het rapport niet kenmerkend zijn voor ICT-projecten alleen of voor de (Nederlandse) overheid. Tevens wordt geargumenteerd dat de cijfers die in de omloop zijn bewijzen dat het probleem van niet volledig succesvolle ICT-projecten zowel bij het bedrijfsleven als bij de overheid substantieel is. Alle grotere organisaties, of het nu gaat om overheid of bedrijfsleven, worstelen met het goed besturen van omvangrijke ICT-projecten. De problemen bij de overheid staan echter veel meer in de schijnwerpers dan die in het bedrijfsleven. Er is al veel literatuur over hoe grote (ICT-)projecten moeten worden gemanaged en hoe de risico’s ervan beheerst zouden kunnen worden, maar toch blijven de problemen hardnekkig (Algemene Rekenkamer, 2007). Volgens het “Memo Advies betreffende ICT-beleid om administratieve lasten te verminderen” maakt het College zich zorgen over de grote verschillen in de mate waarin bij de in de Quick scan onderzochte ICT-projecten aandacht aan (gedetailleerde) planningen, projectrisico’s en “risk management” wordt besteed. Juist bij deze grote ICT-infrastructuurprojecten, waarbij complexiteit en onderlinge afhankelijkheden een grote rol spelen, is het in kaart brengen van projectrisico’s, het gedetailleerd plannen en risicomanagement van groot belang.

4.2 Faalfactoren ICT-projecten overheid De belangrijkste oorzaak voor het (deels) mislukken van ICT-projecten die uit het onderzoek van de Rekenkamer naar voren komt is dat ICT-projecten van de overheid vaak te ambitieus en te complex worden door de combinatie van politieke, organisatorische en technische factoren. Volgens het onderzoeksrapport kunnen de faalfactoren rondom ICT-projecten binnen de publieke sector worden onderverdeeld in de categorieën politieke-, organisatorische- en technische complexiteit.

4.2.1 Politieke complexiteit ICT enthousiasme Betrokkenen zien ICT als instrumentele oplossing voor een probleem, terwijl bestuurders vaak onvoldoende zicht hebben op de mogelijkheden, maar vooral ook de onmogelijkheden van ICT. Wanneer een minister zich vervolgens bij zijn besluitvorming onvoldoende laat ondersteunen door deskundigen met voldoende kennis van ICT en organisatie, neemt het risico op te ambitieuze projecten toe. Zonder een zakelijke rechtvaardiging (business case) kan het project leiden tot veel teleurstelling. In het ontstaan van te ambitieuze projecten spelen ook de leveranciers van ICT-producten en ICT-diensten een rol. Zij zullen om commerciële redenen niet snel kanttekeningen bij een project plaatsen. Al het bovenstaande heeft geleid tot onderschatting van benodigde tijd, geld en menskracht. Politieke deadlines Deadlines voor ICT-projecten in de publieke sector worden vaak niet vastgesteld op basis van een onderbouwde en realistische planning, maar op basis van politieke overwegingen en deadlines. Verder wordt onvoldoende tijd genomen om doelen en eisen te specificeren. Onduidelijk, onzorgvuldig of onvoldoende gedetailleerd uitgewerkte doelen en eisen dragen verder bij aan het afbreukrisico.

24

Te weinig heroverweging onderweg Belangrijke wijzigingen ten aanzien van bijvoorbeeld randvoorwaarden voor het project of nieuwe eisen/wensen voor het ICT-project leiden niet altijd tot herbezinning op de uitgangspunten van het project. Hetzelfde geldt voor signalen tijdens de projectuitvoering over ontstane problemen of nieuwe risico’s op het gebied van planning, inzet van mensen, budget of op te leveren functionaliteiten. Bij de overheid komt het vaker voor dan bij het bedrijfsleven dat een project doormoddert in plaats van wordt gestopt wanneer het nodig is. Het bedrijfsleven heeft te maken met de tucht van de markt en stopt hierdoor eerder met projecten die niet rendabel zijn. Hier is sprake van een beweging waarbij IT-investeringen onder eenzelfde regime komen te vallen als andere grote risicovolle investeringen (Digitaal Bestuur, 2006). Als er in het project geen momenten van herbezinning zijn ingebouwd, wordt de kans kleiner dat de signalen worden herkend en dat op het juiste moment de juiste bijstellingen plaatsvinden.

4.2.2 Organisatorische complexiteit Verschillende organisaties Vaak zijn verschillende, veelal autonome organisaties betrokken bij ICT-projecten van de overheid, bijvoorbeeld omdat: a) een gezamenlijk ICT-systeem wordt ontwikkeld en/of b) deze afhankelijk van elkaar zijn in de werkprocessen/informatie-uitwisseling. Centrale regie of doorzettingsmacht ontbreekt en is vaak onmogelijk en besluitvorming is vaak een moeizaam proces. Impact van verandering Bij het realiseren van politieke doelstellingen wordt vaak de relatie tussen ICT en organisatie over het hoofd gezien. Door de sterke verwevenheid van bedrijfsprocessen met ICT, heeft wijziging van het een vaak grote consequenties voor het ander. Dit wordt meer dan eens onderschat.

4.2.3 Technische complexiteit ICT-ontwikkeling vereist specificatie van doelen en eisen welke aan wijziging onderhevig zijn Veel politieke en organisatorische processen zijn dynamisch en flexibel, terwijl het ontwikkelen van een ICT-systeem juist gebaat is bij een zo stabiel mogelijke politieke en organisatorische omgeving en bij het zo vroeg en specifiek mogelijk omschrijven van doelen en eisen. Dit kan leiden tot wijzigingen in doelen en eisen gedurende het project, met overschrijdingen van tijd en budget als gevolg. Aansluiting op andere ICT-systemen Bij het ontwikkelen van ICT-systemen is aansluiting op andere, vaak bestaande, systemen een complicerende factor. Het succes van de technische realisatie van een ICT-systeem is mede afhankelijk van deze aansluiting. Snelheid van de ontwikkelingen Ontwikkelingen op het gebied van ICT gaan zeer snel, wat betekent dat expertise en kennis relatief snel verouderd zijn. De snelle technologische ontwikkelingen (bijv. nieuwe technieken) kunnen leiden tot technische wijzigingen gedurende de looptijd van het project.

4.3 Faalfactoren overheid versus theoretisch kader Bij ICT-projecten van de overheid blijkt dat de geschetste risico’s gemakkelijk samenkomen, met als consequentie mislukking van ICT-projecten. Juist de combinaties van deze effecten kunnen leiden tot grote problemen, inclusief IT-falen (Digitaal Bestuur, 2006). Allerlei voorwaarden worden binnen de overheid gesteld om oordeelskundig met IT-investeringen om te gaan, maar in de praktijk blijken deze niet voldoende geweest om een succesvolle IT-functie te waarborgen. Hieruit blijkt dat continu risicomanagement van uiterst belang is rondom ICT-projecten, waarbij ook aandacht zou moeten worden besteed aan de geschetste faalfactoren. Eén van de mislukte ICT-projecten in de publieke sector is het WIA-project bij het UWV. Als gevolg van de geconstateerde tekortkomingen rondom de projectbeheersing zijn een aantal risicobeheersende maatregelen gedefinieerd en ingevoerd. Alvorens de faalfactoren worden uitgezet tegen het theoretische toetsingskader worden de bij het UWV ingevoerde maatregelen beschreven.

25

4.3.1 Ingevoerde risicobeheersende maatregelen bij het UWV In de “Tussenrapportage Resultaten onderzoek Wia-systeem” wordt weergegeven wat de oorzaken zijn van de mislukking van het WIA-project bij het UWV. Het memo beschrijft dat forse tekortkomingen zijn geconstateerd ten aanzien van sturing, beheersing, kennis en kunde rondom het ICT-domein van het WIA-programma. Als gevolg hiervan zijn een aantal risicobeheersende maatregelen ingevoerd: – herinrichting van de organisatie op het gebied van de informatievoorziening en ICT; – projecten worden alleen gerealiseerd in overzienbare stappen; – een centrale projectadministratie op financieel gebied wordt ingesteld; – het nadrukkelijker aanspreken van verantwoordelijken op accountability; – een campagne starten om ICT-deskundigheid te verwerven (is gestart); – de rol van de Chief Information Officer (CIO) is versterkt; – UWV laat aanvullende accountantswerkzaamheden uitvoeren opdat geborgd wordt dat ook de na 16 juni 2008 (datum beëindiging programma WIA) te maken kosten die verband houden met het programma, volledig in beeld komen.

4.3.2 Faalfactoren overheid versus theoretisch toetsingskader In de volgende tabel wordt in kaart gebracht in hoeverre de faalfactoren rondom ICT-projecten binnen de publieke sector (rapport Algemene Rekenkamer) worden geadresseerd in het theoretisch kader dat in hoofdstuk 3 is gedefinieerd.

Categorie Faalfactor Geadresseerd in theoretisch toetsingskader?

Aspecten uit theoretisch kader (hoofdstuk 2)

Politieke complexiteit

- ICT enthousiasme - Politieke deadlines - Te weinig

heroverweging onderweg

Ja, deze faalfactoren worden geadresseerd door het theoretische toetsingskader.

- business case, risicoheroverweging en monitoring gedurende de gehele levenscyclus;

- betrouwbare en accurate voorspellingen van kosten en uitkomsten;

- aansluiting tussen IT-risico’s en bedrijfsdoelen; - betrekken stakeholders en toekennen

verantwoordelijkheden. Organisato-rische complexiteit

– Verschillende organisaties – Impact van verandering

Nee, dit is een specifiek onderwerp dat niet direct in de theorie wordt geadresseerd. Ja.

Identieke adressering als voor politieke complexiteit.

Technische complexiteit

– ICT-ontwikkeling vereist specificatie van doelen en eisen welke aan wijziging onderhevig zijn – Aansluiting op andere ICT-systemen – Snelheid van de ontwikkelingen

Ja. Ja, als onderdeel van “delivery risks”.

Door middel van de business case, heroverweging en monitoring dienen wijzigingen in doelen en eisen die gedurende het project plaatsvinden tijdig te worden geïdentificeerd en opgevolgd. Overschrijdingen van initiële tijd en budget kan het gevolg zijn. Dit dient te worden heroverwogen in de business case. Risicomanagement dient te worden uitgevoerd rondom Technische/functionele complexiteit, maar dit geeft geen garantie voor de technische realisatie van interfaces met bestaande, vaak verouderde applicaties en het inspelen op snelle technologische ontwikkelingen.

26

5 Beheersing van ICT-projecten bij private sector in de praktijk In dit hoofdstuk wordt op grond van praktijkonderzoek geanalyseerd wat de verschillen zijn tussen de organisaties waar IT risicomanagement wel heeft geleid tot een goed project-resultaat en de organisaties waar ICT-projecten zijn mislukt. Voor deze analyse worden eerst de gehanteerde uitgangspunten in het reeds opgestelde theoretisch kader geverifieerd, aan de hand van een interview met een professional die uitgebreide ervaring heeft met o.m. de beheersing van projecten. Hierop wordt in paragraaf 5.1 nader ingegaan. Vervolgens wordt op basis van een tweetal casussen beschreven hoe organisaties in de private sector invulling geven aan de beheersing van risico’s omtrent ICT-projecten en de verhouding hiervan tot succes of mislukking van deze projecten. De resultaten hiervan worden ook in paragraaf 5.1 weergegeven. Voorts wordt in paragraaf 5.2. de resultaten hiervan gebruikt om een toetsingskader te definiëren voor de adequate beheersing van risico’s rondom projecten. Tenslotte wordt in paragraaf 5.3. naast de analyse van de geïdentificeerde verschillen tussen de organisaties waar IT risicomanagement wel heeft geleid tot een goed project-resultaat en de organisaties waar ICT-projecten zijn mislukt ook de eventuele verschillen tussen de publieke- en private sector in kaart gebracht.

5.1 Risicomanagement bij ICT-projecten in de private sector Op basis van diverse interviews met relevante medewerkers van een handel/technologie firma en een grote levensverzekeringmaatschappij, is in kaart gebracht hoe deze organisaties doorgaans invulling gegeven aan de beheersing van risico’s gedurende de levenscyclus van ICT-projecten. In tabel 4 hieronder zijn de resultaten hiervan opgenomen, aan de hand van de volgende aspecten die afgeleid zijn uit het theoretische toetsingskader: (1) Schaal, (2) Projectmanagement, (3) Relatie tussen de Business en ICT, (4) Risicomanagement, (5) Prestatie en monitoring, (6) Succes- en faalfactoren van ICT-projecten. De volgende interviews zijn gehouden: § levensverzekeringmaatschappij (Bedrijf A): interview met de IT Risk Manager. Bij dit bedrijf wordt relatief

veel aan softwareontwikkeling gedaan en in de afgelopen jaren heeft hierdoor een verdubbeling plaatsgevonden van het aantal medewerkers bij de ICT afdeling. De volgende soorten projecten worden onderscheiden: (1) grote projecten die betrekking hebben op maatwerkontwikkeling voor de invoer van nieuwe verzekeringsproducten of infrastructurele veranderingen, en (2) systeem-wijzigingen die benodigd zijn om de ondersteuning aan de business te kunnen waarborgen.

§ handel/technologie firma (Bedrijf B): twee interviews, één met de IT Governance Manager en één met het management van het Project Management Office (PMO). Dit bedrijf investeert tientallen miljoenen Euro per jaar, verspreid over diverse projecten en programma’s, inclusief eigen ontwikkeling.

§ Ernst & Young professional: interview met de Partner van de afdeling Program Advisory Services (hierna: PAS).

27

Aspect Bedrijf A – grote levensverzekeraar Bedrijf B – handel/technologie firma Ernst & Young professional Analyse / toevoegingen kader

Doel: Adequaat risicomanagement rondom ICT-projecten en daarmee het verkrijgen van (de beoogde) positieve bedrijfswaarde uit IT-gerelateerde investeringen.

N.v.t. N.v.t. N.v.t. Geen wijzigingen in theoretisch kader.

Principes: a) Betrouwbare en accurate voorspellingen van kosten en uitkomsten; b) Aansluiting tussen IT-risico’s en bedrijfsdoelen; c) Effectief management van IT-risico’s als continu proces en als onderdeel van de dagelijkse werkzaamheden; d) Portfolio Management gericht op potentiële bedrijfswaarde van investeringen en realisatie hiervan; e) Definiëren en monitoren van KPI’s; f) Volledige integratie risicomanagement met systeem ontwikkelingsproces.

Prince2 en de Copafit methode worden gehanteerd voor de beheersing en uitvoering van IT-projecten. Ingediende projectvoorstellen moeten worden gestaafd door een business case en een haalbaarheidsonderzoek, waarbij zowel gedelegeerden van de business en IT zijn betrokken. Na het goedkeuren van deze resultaten door het managementteam van de ICT-afdeling, worden projecten tot uitvoering gebracht op basis van de systeemontwikkelingsfasen. Gedurende de levenscyclus van projecten wordt risicomanagement op continue wijze uitgevoerd, omdat het succes van ICT-projecten voor een aanzienlijke mate hierdoor wordt bepaald. Geïnitieerde projecten worden pas beëindigd als het opgeleverde systeem in productie functioneert conform de opgestelde gebruikersacceptatie criteria. Tevens moet het ontwikkelde product bruikbaar zijn voor de business anders wordt het niet geïmplementeerd.

Projecttypen worden gedefinieerd aan de hand van de variabelen Effort / Cost en Complexiteit. De gevolgde methodiek heeft raakvlakken met Prince2, maar deze is minder formeel en pragmatisch ingericht. Op basis van een Business Case (bestaand o.a. uit een risk assessment) en een Feasibility Study wordt een project gedefinieerd. Business cases worden voor elk project opgesteld door een business analist. Op basis van onder meer de beoogde impact op sales en operationele en technische aspecten worden financiële middelen geaccordeerd en vrijgemaakt. In de business case wordt tevens een sectie opgenomen voor risico’s ten aanzien van deze aspecten. Technische risico’s (ook ten aanzien van technische middelen) worden geanalyseerd als onderdeel van de systeemontwikkeling (SDLC).

Betrouwbare voorspelling van kosten en uitkomsten op het niveau van: - Portfolio - middelen dienen door het management te worden gereserveerd en beheerst om voldoende beschikbare capaciteit te borgen; - Programma – aansturing van projecten aan de hand van gedefinieerde resultaten op het gebied van bijvoorbeeld verhoogde betrouwbaarheid of verbeterde transparantie; - Project – de projectmanager is verantwoordelijk voor het realiseren van het beoogde resultaat. Verder is het van belang dat de aansluiting tussen de IT-risico’s en de bedrijfsdoelen voortdurend wordt bewaakt en integraal beheerst. Een belangrijke kanttekening volgens de geïnterviewde hierbij is dat de projectmanager niet vanuit: KPI’s moet denken die voornamelijk financieel getint zijn, maar vanuit gedefinieerde KRI’s. Bovendien zal een projectmanager ervoor moeten zorgen dat er voldoende maatregelen zijn getroffen om potentiële risico’s op te vangen (het zogenoemde “bottom line thinking”). Tevens dient een onafhankelijke partij op continue basis Quality Assurance uit te voeren bij grote

a) Betrouwbare en accurate voorspellingen van kosten en uitkomsten, zowel op het gebied van projecten, programma’s als portfolio’s. e) Definiëren en monitoren van KPI’s en KRI’s. g) Quality Assurance wordt op een continue basis uitgevoerd door een onafhankelijk orgaan. b), c), d), f) Geen wijzigingen in theoretisch kader.

28


IT programma’s voor de waarborging van de realisatie van de beoogde resultaten.

Processen: a) Value/Risk Governance; b) Portfolio Management; c) Investment Management; Risk Analysis, -Evaluation en –Response worden uitgevoerd als onderdeel van Portfolio- en Investment Management. De business case, risicoheroverweging en monitoring staan gedurende de gehele levenscyclus van de investering centraal in het kader van risicomanagement. Voorts wordt risicomanagement tenminste uitgevoerd bij de volgende mijlpalen: a) Project preparation; b) Business blueprint; c) Realisatie; d) Going life; e) Post implementatie.

De afdeling Operational Risk Management (hierna: ORM) is verantwoordelijk om risico’s omtrent projectvoorstellen te identificeren en te analyseren. Het resultaat hiervan wordt door het managementteam van de ICT-afdeling gebruikt om te bepalen welke projectvoorstellen in aanmerking komen voor behandeling. De ORM afdeling bestaat uit diverse medewerkers met verschillende aandachtsgebieden, zoals compliance, business, IT en juridische zaken. Op basis van de kennis en expertise van deze medewerkers worden risico’s geanalyseerd ten aanzien van de (technische) complexiteit van de omgeving van het project en de interne projectbeheersing. Binnen ORM is bovendien de afdeling Information Risk Management belegd met de verantwoordelijkheid om de technische risico’s ten aanzien van de beveiliging en beschikbaarheid van informatie te analyseren. Nadat de risico’s in kaart zijn gebracht, wordt door ORM de impact van de geïdentificeerde risico’s bepaald en de daarbij horende maatregelen. Voorts wordt risicomanagement op continue wijze uitgevoerd gedurende de levenscyclus van projecten, omdat gebruikerswensen kunnen veranderen of nieuwe marktontwikkelingen kunnen optreden die aanvankelijk niet bekend waren. Het uitvoeren van risicomanagement is een bepalende factor voor het slagen van projecten.

Besluitvorming rondom projecten is afhankelijk van het type project. Reguliere projecten kunnen relatief snel worden stopgezet wanneer bijvoorbeeld de voortgang te langzaam is, de kwaliteit niet naar wens of de kosten te hoog worden. Voor programma’s geldt dat het budget of de tijdgrenzen meer uitrekbaar zijn. Bij elke stap afzonderlijk wordt nagegaan wat de bestede tijd en geld is. Gedurende de uitvoering van het project kan de kwaliteit/functionaliteit naar beneden worden afgesteld, afhankelijk van de complexiteit en mogelijkheden. Gedurende de implementatie wordt de UAT uitgevoerd, waarin de functionaliteit al dan niet wordt geaccepteerd.

Continu risicomanagement gedurende projecten is noodzakelijk, en dient tenminste te worden uitgevoerd bij elk gedefinieerde projectfase, zoals business case, initiatie, realisatie, implementatie en support. Splitsen van de fases met betrekking tot ontwikkeling en implementatie in beheersbare stappen.

Projecten worden alleen gerealiseerd in overzienbare stappen.

29


Risicocategorieën: a) Delivery risk—Het risico op het niet leveren van de beoogde capaciteiten. b) Benefits risk—Het risico op het niet behalen van de beoogde resultaten/voordelen. Risicomanagement dient te worden uitgevoerd bij alle fasen uit het systeem ontwikkelingsproces en tenminste bij de vijf mijlpalen. De complexiteit van ICT-projecten dient te worden beheerst op basis van de interne risicocategorieën en de categorieën die worden opgelegd uit de omgeving (bijv. sociale/organisatorische complexiteit).

a) het kost relatief veel tijd om ontwikkelingen op het gebied van weten regelgeving te volgen, zodat aanpassingen in de systemen tijdig kunnen worden doorgevoerd. Hierdoor heeft dit veelal bijgevolg dat de organisatie meer bezig is met verbeteringstrajecten dan het vernieuwen van de bedrijfsprocessen; b) technische complexiteit van de systemen draagt verder niet altijd bij aan het slagen van IT-projecten; c) projectvoorstellen zijn soms te complex en/of de planning voor de realisatie ervan is te ambitieus. Nadat een project is geïnitieerd, is het managementteam samen met de business en IT verantwoordelijk voor de nadere inrichting van het project. Hierbij wordt doorgaans op basis van KRI’s die opgenomen zijn in de risk log van de projectmanager de voortgang en prestaties van het project bewaakt. Dit wordt verder ondersteunt door een procedure die gedurende het project waarborgd dat bij elke faseovergang alle betrokken partijen akkoord zijn voor de implementatie van het product. Voor de relatief kleinere wijzigingen die worden geïmplementeerd in de systemen wordt ook een risicoafweging uitgevoerd, echter in tegenstelling tot de projecten is de inhoudelijke diepgang van deze analyses beperkter van aard.

Gebruik wordt gemaakt van de KPI’s financiële kosten en tijd. Vanuit de business en het monitoring en compliance office wordt tevens gemanaged op kwaliteit. Er wordt geen concreet gebruik gemaakt van KRI’s rondom het managen van projecten/programma’s.

De volgende risicogebieden zijn voorts volgens de geïnterviewde typerend bij projecten: a) Interne projectbeheersing – veelal is het geval dat opgestelde business cases sterk gericht zijn op de beoogde financiële voordelen en in minder mate geconcentreerd zijn op de mogelijke risico’s, zoals de waarschijnlijkheid van de planning; b) Complexiteit van de projectomgeving – de markttrend wijst erop dat de complexiteit steeds meer toe zal nemen waardoor de intrinsieke risico’s ook toe zullen nemen, zoals groeiende inhuur van externe ICT-dienstverleners, stakeholders, minder transparantie, culturele aandachtsgebieden die worden veroorzaakt door buitenlandse uitbestedingen, integratie met legacy systemen en andere technische implicaties. Ondanks dat complexiteit de grootste vijand is voor het slagen van projecten, begrijpen we verder dat risico’s in deze categorie relatief makkelijker te herkennen zijn voor een projectmanager.

Risicomanagement gericht op veranderingen in weten regelgeving.

30


Verantwoordelijkheden: De Project Manager is verantwoordelijk voor risicomanagement en dient grip te houden op complexiteit door middel van adequaat en continu risicomanagement. Prestatiemeting dient te worden uitgevoerd door een onafhankelijk daarin gespecialiseerd orgaan.

Tijdens de uitvoering van projecten wordt door de toegekende Project Manager de planning, budget en kwaliteit van het softwareproduct bewaakt. Daarnaast heeft de Project Manager een “ risk log” tot zijn of haar beschikking om additionele risico’s, die optreden gedurende het systeemontwikkelingsproces, vast te leggen. Dit document wordt regelmatig met de ORM afdeling overlegd om de impact van de geïdentificeerde risico’s verder te bepalen en te beheersen. Tevens kent elke fase van het project een Go/No Go-beslissingsmoment, om te borgen dat de doorlooptijd van het project zo efficiënt en effectief mogelijk verloopt. Projecten worden in overzienbare stappen uitgevoerd.

Een Project Review Board (PRB) is operationeel als besturend orgaan en bestaat uit zowel business als ICT gedelegeerden. Vanuit het PRB wordt geen monitoring uitgevoerd op kwaliteit, uitsluitend op financiën. Dit betekent dat er geen zicht is op het realiseren van de beoogde voordelen/requirements voor de business.

Voor een effectieve beheersing van projecten is het noodzakelijk dat de projectmanager verantwoordelijk is voor de uitvoering van risicomanagement activiteiten zowel voor de start als gedurende het project. De projectmanager dient verantwoordelijk te zijn voor de deelname en toewijding van alle stakeholders (zoals de business sponsor, gebruikersorganisatie, ontwikkelaars, testers, etc.) gedurende de gehele levenscyclus van het project.

a) Centrale projectadministratie op financieel gebied; b) Geïdentificeerde en geanalyseerde risico’s moeten formeel worden beschreven door de projectmanager met behulp van een “risk log”, voor een consistente vastlegging van geïdentificeerde risico’s en ondernomen risico reducerende maatregelen; c) Project review board en/of projectmanager die naast de planning en budget ook de kwaliteit van het product bewaakt middels Go/No Go-momenten bij elke faseovergang.

Informatiemanagement: De relatie tussen de business en ICT dient continu te worden beheerst door de projectmanager.

Gedurende de volgende fasen vindt afstemming plaats tussen Business en ICT: a) tijdens de initiatiefase voor het haalbaarheidsonderzoek; b) gedurende de ontwerpfase voor het definiëren van de business requirements; c) bij de implementatiefase voor de uitvoering van de gebruikersacceptatie testen (UAT). De laatste jaren heeft de interactie tussen de Business en ICT zich positief ontwikkeld. Dit in tegenstelling tot het verleden waar vaak sprake was van projecten die niet het beoogde resultaat hebben opgeleverd. Een project wordt niet gestart, indien de betreffende ICT’er heeft aangegeven dat er technische implicaties zijn gedurende het haalbaarheidsonderzoek van het project.

Afstemming rondom projecten tussen de business en ICT vindt doorgaans plaats bij de volgende mijlpalen: a) tijdens het samenstellen van Business Requirements; b) gedurende de PRB meetings; c) gedurende de UAT; go/no go.

In het kader van de beheersing van projecten dient de projectmanager verantwoordelijk te zijn voor de beheersing van de relatie tussen de Business en ICT. Hierbij heeft de projectmanager een cruciale functie om de regie te voeren over de kanalisatie van alle vragen die geïdentificeerd worden bij zowel ICT als de business. Op deze wijze faciliteert de projectmanager de afstemming die benodigd is tussen de business en de (externe) leverancier.

Geen wijzigingen in theoretisch kader.

31


Overige aspecten, niet geadresseerd in theoretisch kader

a) de kwaliteit van de projectmanager die tevens over de vaardigheden moet beschikken om de ontwikkelingen in de markt te overzien; b) strakke projectleiding en een gedefinieerde methodiek voor de beheersing van projecten; c) bij het inkopen van capaciteit die benodigd is voor de uitvoering van projecten, wordt de derde partij formeel verantwoordelijk gesteld voor de levering van de gevraagde diensten.

Het afgelopen jaar zijn goede resultaten behaald rondom het slagen van projecten, op basis van de indicatoren geld en tijd. De afstemming en samenwerking tussen business en ICT is adequaat verlopen met als gevolg een hoge mate van succesvolle ICT-gerelateerde projecten. Wat hierbij als een succesfactor in het bijzonder wordt beschouwd is het Project Management kennis- en ervaringsniveau van betrokkenen, de project cultuur en adequaat risicomanagement.

a) Een goede projectmanager dient te beschikken over de eigenschappen en/of ervaring om tijdig te signaleren dat er problemen zijn binnen het project. Om de stelregel van de geïnterviewde te citeren: “Elke brand is te blussen met een glas water”. b) Daarnaast dient een projectmanager leiderschapskwaliteiten te hebben om de continuïteit van het project te waarborgen. c) Bij de samenstelling van het projectteam dient rekening te worden gehouden met de benodigde competenties voor het project. Bovendien komt het succes van een project daadwerkelijk ten goede, als de projectmanager in staat is om een team te smeden van de geselecteerde projectmedewerkers.

a) Kennis, ervaring en het risicodenkende vermogen van project managers en overige betrokkenen zijn voor een groot deel bepalend voor het resultaat. b) Afspraken en verantwoordelijk stellen van betrokken derde partijen.

Tabel 4 Praktijkresultaten over risicomanagement bij ICT-projecten in de private sector

32

5.2 Toetsingskader risicomanagement rondom grote ICT-projecten Aan de hand van de geanalyseerde faalfactoren bij de publieke sector (hoofdstuk 4) en interviewresultaten van diverse professionals uit het bedrijfsleven (paragraaf 5.1), zijn additionele aspecten geïdentificeerd in bovenstaande tabel 4 die vanuit de praktijk een belangrijke rol spelen bij de adequate beheersing van projecten. Deze praktijkgerichte aspecten zijn toegevoegd aan het samengestelde theoretisch kader (hoofdstuk 3) en het resultaat hiervan is als een geverifieerd toetsingskader opgenomen voor de beheersing van risico’s bij projecten. Daarnaast wordt in paragraaf 5.2.2 nader op de rol van de IT-Auditor ingegaan bij de beheersing van risico’s binnen projecten.

5.2.1 Toetsingskader Hieronder wordt het voorgestelde toetsingskader weergegeven voor de beheersing van risico’s rondom projecten op basis van aspecten die additioneel zijn geïdentificeerd gedurende het praktijkonderzoek. De grijs gemarkeerde aspecten zijn bijgevoegd aan het theoretische kader op basis van het onderzoek.

Doel Adequaat risicomanagement rondom ICT-projecten en daarmee het verkrijgen van (de beoogde) positieve bedrijfswaarde uit IT-gerelateerde investeringen. Principes § Betrouwbare en accurate voorspellingen van kosten en uitkomsten, zowel op het gebied van

projecten, programma’s als portfolio’s; § Aansluiting tussen IT-risico’s en bedrijfsdoelen; § Effectief management van IT-risico’s als continu proces en als onderdeel van de dagelijkse

werkzaamheden; § Portfolio Management gericht op potentiële bedrijfswaarde van investeringen en realisatie

hiervan; § Definiëren en monitoren van KPI’s; § Definiëren en monitoren van KRI’s; § Volledige integratie risicomanagement met systeem ontwikkelingsproces. § Quality Assurance wordt op een continue basis uitgevoerd door een onafhankelijk orgaan. Processen a) Value/Risk Governance; b) Portfolio Management; c) Investment Management; Risk Analysis, -Evaluation en –Response worden uitgevoerd als onderdeel van Portfolio- en Investment Management. De business case, risicoheroverweging en monitoring staan gedurende de gehele levenscyclus van de investering centraal in het kader van risicomanagement. Voorts wordt risicomanagement tenminste uitgevoerd bij de volgende mijlpalen: § Project preparation; § Business blueprint; § Realisatie; § Going life; § Post implementatie. Projecten worden alleen gerealiseerd in overzienbare stappen. Zie volgende pagina voor vervolg.

33

5.2.2 Impact en rol IT Audit vakgebied De IT Auditor beoordeelt de kwaliteit van de risicobeheersing van IT risico’s, waarvoor specialistische kennis van IT en IT-beheersing benodigd is (MAB, 2008). Specifiek in relatie tot IT-projecten en -programma’s kan de IT auditor optreden vanuit een attestfunctie of adviesfunctie (Van Praat en Suerink, 2004), gericht op de volgende varianten: § onafhankelijke Project Audit (health check / APK-keuring projecten); § quality assurance; § ondersteuning bij de implementatie van project management governance en –processen, waaronder

project portfolio management en project en programma delivery / performance.

Risicocategorieën Risicomanagement dient tenminste te zijn gericht op de volgende risicocategorieën: – a) Delivery risk—Het risico op het niet leveren van de beoogde capaciteiten. – b) Benefits risk—Het risico op het niet behalen van de beoogde resultaten/voordelen. Risicomanagement dient te worden uitgevoerd bij alle fasen uit het systeem ontwikkelingsproces en tenminste bij de vijf mijlpalen. De complexiteit van ICT-projecten dient te worden beheerst op basis van de interne risicocategorieën (bijv. projectbeheer en –beheersing) en de categorieën die worden opgelegd uit de omgeving (bijv. sociale/organisatorische complexiteit). Als onderdeel van risicomanagement dient speciale aandacht te worden gericht op veranderingen in weten regelgeving, indien van toepassing. Verantwoordelijkheden De Project Manager is verantwoordelijk voor risicomanagement en dient grip te houden op complexiteit door middel van adequaat en continu risicomanagement. Geïdentificeerde en geanalyseerde risico’s moeten formeel worden beschreven door de projectmanager met behulp van een “risk log”, voor een consistente vastlegging van geïdentificeerde risico’s en ondernomen risico reducerende maatregelen. Prestatiemeting dient te worden uitgevoerd op de planning, budget en kwaliteit door een daartoe onafhankelijk daarin gespecialiseerd orgaan (bijvoorbeeld een Project Review Board). Op financieel gebied dient een centrale projectadministratie te zijn ingericht. Indien derde partijen betrokken zijn dienen duidelijke afspraken te worden gemaakt en deze dienen verantwoordelijk te worden gesteld. Informatiemanagement De relatie tussen de business en ICT dient continu te worden beheerst door de projectmanager. Soft skills Vanuit het praktijkonderzoek blijkt dat hard skills (processen, tools en technieken) alleen niet voldoende zijn om ICT-gerelateerde risico’s rondom projecten adequaat te beheersen. Soft skills, zoals communicatie, leiderschap, “risk mindedness”, etc., zijn minstens zo belangrijk in adequaat risicomanagement en bepalen mede het succes van projecten. Volgens de theorie (Barrow e.a., 2008) zijn er tenminste zes wijzen waarop soft skills kunnen bijdragen aan het succes van projecten, specifiek gericht op risicomanagement: #1 - By overcoming obstacles caused by cultural differences;

#2 - Through earlier identification of people risks in projects; #3 – By promoting greater understanding of the psychological aspects of risk management; #4 – By using lenses as a means of focussing on softer project issues; #5 - By improving the effectiveness of risk management workshops; #6 - By helping project managers improve their awareness of interpersonal communications.

De kennis, ervaring en het risicodenkende vermogen van de project managers en overige betrokkenen kunnen voor een groot deel bepalend zijn voor het succes of mislukken van ICT-gerelateerde projecten.

34

Onderscheid kan worden gemaakt in strak geleide projecten in min of meer stabiele situaties en veranderingstrajecten in situaties met een grote mate van onzekerheid. Volgens de theorie wordt minstens de helft van het projectresultaat bepaald door de omgeving en de andere helft door de manier van beheersing. Uit voorgaande onderschrijven wij de stelling dat risicomanagement het verschil kan betekenen tussen het slagen of falen van ICT-projecten. Voor het beoordelen en/of adviseren ten aanzien van de beheersing rondom complexe of minder complexe IT-projecten en -programma’s dient een normenkader te worden toegepast dat leidt tot herhaalbare resultaten. Op basis van het praktijkonderzoek hebben wij het theoretische model verrijkt met een aantal aspecten die een bijdrage kunnen leveren aan het slagen van projecten. Dit heeft geleid tot het voorgestelde toetsingskader. Voor het inrichten van adequaat risicomanagement rondom projecten biedt het voorgestelde toetsingskader - dat is afgeleid uit theorie en praktijk – de benodigde handvaten. Op basis van de hierin beschreven principes, processen, risicocategorieën, informatiemanagement, verantwoordelijkheden en benodigde soft skills kan adequaat risicomanagement rondom ICT-projecten worden ingericht en daarmee het verkrijgen van (de beoogde) positieve bedrijfswaarde uit IT-gerelateerde investeringen. Dit kader maakt het verder voor de IT-Auditor mogelijk om op een onafhankelijke wijze te toetsen of risico’s rondom projecten adequaat worden beheerst in zijn of haar attestfunctie voor het waarborgen van de kwaliteit van het op te leveren softwareproduct. Daarnaast kan het voorgestelde toetsingskader worden gebruikt door de IT-Auditor om hem of haar te ondersteunen bij het adviseren van projectorganisaties, ten aanzien van het gebruik van richtlijnen bij het implementeren van projectmanagement governance en processen. Op basis van het onderzoek blijkt dat binnen het vakgebied nadere theorieontwikkeling (beste praktijkmethoden) en aandacht benodigd zijn op het gebied van:

a) normenkader voor continu risicomanagement met betrekking tot ICT-projecten; b) focus op KRI management in plaats van KPI management.

5.3 Analyse succes versus mislukking In deze paragraaf wordt op basis van het toetsingskader geanalyseerd wat de verschillen zijn tussen organisaties waar risicomanagement wel heeft geleid tot een goed projectresultaat en de organisaties waar ICT-projecten zijn mislukt. In paragraaf 5.3.1 wordt hierop nader ingegaan waarbij het toetsingskader en de resultaten uit het praktijkonderzoek worden gebruikt om een verschillenanalyse uit te voeren gericht op het slagen en falen van projecten en de relatie tot beheersing/risicomanagement. In paragraaf 5.3.2 worden de verschillen geanalyseerd tussen organisaties in de publieke sector en private sector ten aanzien van beheersing van ICT-projecten.

5.3.1 Verschillen tussen slagen en falen van projecten Op basis van het praktijkonderzoek bij zowel de overheid (hoofdstuk 4) als de uitgevoerde interviews (paragraaf 5.1), is geconstateerd dat de kans op afgedwongen succes van ICT-projecten groter is bij bedrijf A dan bij bedrijf B of de overheid. Dit omdat de volgende slaag/faalfactoren zijn aangetroffen bij deze organisaties: § Zowel bij bedrijf A als bedrijf B moet elk projectvoorstel worden gestaafd door een zakelijke

rechtvaardiging inclusief een haalbaarheidsonderzoek. Echter in tegenstelling tot bedrijf B en de overheid, wordt bij bedrijf A naast de financiële aspecten van de business case tevens de (technische) complexiteit van projecten geadresseerd vanaf de haalbaarheidsonderzoeksfase van het project. Dit laatste maakt een projectvoorstel, inclusief gebruikerswensen en beoogd rendement, veelal minder aantrekkelijk om geselecteerd te worden door het management om tot uitvoering te worden gebracht. De onderzoeksresultaten wijzen erop dat een organisatie beter behoed is tegen het mislukken van projecten, indien deze voor de start van een project ook de risico’s met betrekking tot de technische complexiteit van het project identificeert, analyseert en beschrijft;

§ Bij de overheid vindt te weinig heroverweging van het project inclusief risico’s plaats, waardoor de uitvoering van risicomanagement beperkt blijft tot alleen risicoanalyse. Dit in tegenstelling tot bedrijf A en bedrijf B waar de verantwoordelijkheden voor het continue uitvoeren van risicomanagement bij projecten worden verdeeld binnen deze organisaties. Voorts is het van belang dat bij de verdeling van

35

deze verantwoordelijkheden alle relevante risicogebieden, zoals compliance, beveiliging, performance, beschikbaarheid en interne projectbeheersing, worden geadresseerd;

§ Bij de overheid is vastgesteld dat wanneer wordt gestreefd om politieke doelstellingen te realiseren, dan wordt de relatie tussen ICT en organisatie vaak over het hoofd gezien. Terwijl bij zowel bedrijf A als bedrijf B projectmanagers verantwoordelijk worden gesteld om gedurende de gehele levenscyclus van een project de relatie tussen de business en IT te beheersen;

§ Bij bedrijf A maakt de projectmanager gebruik van een “risk log” om additionele risico’s en ondernomen acties vast te leggen die mogelijk gedurende de uitvoering van een project worden geïdentificeerd. Hiermee kan de besturing van het project plaatsvinden op basis van KRIs in plaats van KPIs. Tevens vindt bij elke fase van het project een Go/No Go-beslissingsmoment plaats waarbij alle betrokken stakeholders moeten deelnemen;

§ Zowel bij bedrijf A als bij bedrijf B wordt vervolgens aangeven dat de projectmanager kennis moet hebben van zowel de organisatie inclusief de informatiebehoeften en de marktontwikkelingen om adequaat te kunnen bemiddelen tussen de business en ICT;

§ Echter in tegenstelling tot bedrijf A wordt bij bedrijf B vanuit de projectenorganisatie geen prestatiemonitoring uitgevoerd op kwaliteit, uitsluitend op planning en budget.

Aan de hand van deze resultaten is de conclusie dat bedrijf A meer aanknopingspunten heeft met het toetsingskader, dan bedrijf B of de overheid.

5.3.2 Verschillen en overeenkomsten tussen publiek en privaat In hoofdstuk 3 zijn de kernproblemen die een rol spelen voor het beheersen van ICT-projecten bij de overheid in kaart gebracht. In paragraaf 5.2 zijn naast de factoren die van belang zijn voor het adequaat beheersen van projecten in het bedrijfsleven, ook de problemen geïdentificeerd die een gevaar vormen voor het slagen van deze projecten. Op basis van een vergelijking tussen beiden geldt dat zowel bij de publieke als bij de private sector er sprake is van dezelfde kernproblemen. Deze zijn: § De planning en definitie van ICT-projecten wordt vaak te ambitieus opgesteld; en § Complexiteit van de projectomgeving, zoals verdeelde stakeholders, de relatie tussen business en ICT,

en technische implicaties (nieuwe ICT moet worden geïntegreerd met oude ICT). Deze bevindingen onderschrijven de stelling dat alle grotere organisaties, ongeacht de sector waarin deze opereren, worstelen met het goed besturen van omvangrijke ICT-projecten. Echter zijn op basis van de vergelijking een aantal verschillen geconstateerd tussen de publieke en private sector. ICT-projecten bij de publieke sector zijn qua omvang en impact vaak groter dan bij bedrijven. Dit kan het gevolg zijn van de diverse betrokken organisaties (organisatorische complexiteit van de hoogste klasse) en/of dynamica als gevolg van wetgeving, lange doorlooptijden en trage besluitvormingsprocessen. Bij de private sector wordt op basis van het praktijkonderzoek veel grip op ICT-projecten vereist vanuit het bestuur van de organisatie (bijv. door middel van een project governance board). Hierdoor vallen ICT-projecten onder eenzelfde beleid en bestuur als overige risicovolle investeringen en wordt in hoge mate gebruik gemaakt van de leercurve. Dit laatste vindt bijvoorbeeld plaats door middel van “risk logs” en benchmarking tussen projecten/programma’s. Daarnaast worden soft skills van betrokkenen specifiek benoemd binnen de private sector als aandachtsgebied voor het slagen van ICT-projecten. Dit in tegenstelling tot de publieke sector waarbij het in onvoldoende mate beschikken over soft skills nog niet als faalfactor is meegenomen voor IT-projecten.

36

6 Conclusie Elementen voor risicomanagement zijn ‘risicoanalyse’, ‘risicobeheersing” en ‘evaluatie en bewaking”. In hoofdstuk 2 zijn een aantal modellen zoals COSO, CobiT, Risk IT, CMMi, Prince2, NIST, Val IT, toegelicht en is aangegeven in welke mate deze modellen invulling geven aan de elementen van risicomanagement. Tevens is de bruikbaarheid van deze modellen bepaald voor de beheersing van risico’s bij ICT-projecten, aan de hand van het Negenvlaksmodel. Met het resultaat hiervan is in hoofdstuk 3 een theoretisch kader samengesteld voor adequaat risicomanagement rondom ICT-projecten. Doorgaans is dit kader getoetst in hoofdstukken 4 en 5 aan de hand van praktijkonderzoek bij zowel de publieke- als de private sector. Dit kader en de resultaten van de toetsing liggen aan de basis van de beantwoording van de centrale vraag:

De verschillen in toepassing van risicomanagement in relatie tot het slagen of falen van ICT-projecten Uit de theorie blijkt dat het belang van risicomanagement specifiek in relatie tot projecten groot is, maar dat veel bedrijven in de praktijk worstelen met het geven van adequate invulling hieraan. Dit blijkt uit theoretische onderzoeken en het aantal berichtgevingen omtrent falende ICT-projecten binnen zowel publieke als private sector. ICT-projecten worden gekarakteriseerd door onder andere sociale, technische en organisatorische complexiteit en projectrisico’s zijn van dynamische aard.

Op basis van het praktijkonderzoek hebben wij het theoretische model verrijkt met een aantal aspecten die een bijdrage kunnen leveren aan het slagen van projecten. Dit heeft geleid tot het voorgestelde toetsingskader. De volgende aspecten zijn op basis van het praktijkonderzoek opgenomen in aanvulling op het theoretische model:

Principes § Betrouwbare en accurate voorspellingen van kosten en uitkomsten, zowel op het gebied van projecten, programma’s als portfolio’s;

§ KPI’s zijn veelal financieel gericht waardoor minder aandacht wordt besteed aan de kwaliteit van het softwareproduct. Door het definiëren en monitoren van KRI’s worden de aspecten (bijv. betrokkenheid van stakeholders) die van invloed kunnen zijn op o.m. de kwaliteit van het product explicieter meegenomen door de projectmanager bij de beheersing van risico’s rondom projecten;

§ Quality Assurance wordt op een continue basis uitgevoerd door een onafhankelijk orgaan. Processen Projecten worden alleen gerealiseerd in overzienbare stappen. Risico-categorieën

Als onderdeel van risicomanagement dient speciale aandacht te worden gericht op veranderingen in weten regelgeving, indien van toepassing.

Verantwoorde-lijkheden

Geïdentificeerde en geanalyseerde risico’s moeten formeel worden beschreven door de projectmanager met behulp van een “risk log”, voor een consistente vastlegging van geïdentificeerde risico’s en ondernomen acties. Prestatiemeting dient te worden uitgevoerd op de planning, budget en kwaliteit door een daartoe onafhankelijk daarin gespecialiseerd orgaan (bijvoorbeeld een Project Review Board) Op financieel gebied dient een centrale projectadministratie te zijn ingericht. Indien derde partijen betrokken zijn dienen duidelijke afspraken te worden gemaakt en deze dienen verantwoordelijk te worden gesteld.

Soft skills De kennis, ervaring en het risicodenkende vermogen van de project managers en overige betrokkenen kunnen voor een groot deel bepalend zijn voor het succes of mislukken van ICT-gerelateerde projecten.

Geen project is hetzelfde en de complexiteit dient op een gepaste wijze te worden beheerst. Principes die aan de basis hiervan liggen zijn bijvoorbeeld accurate voorspellingen van kosten en uitkomsten van

Als gevolg hiervan is het van groot belang risicomanagement uit te voeren als een iteratief, duurzaam en continu proces.

Wat zijn de verschillen in de toepassing van risicomanagement tussen organisaties waar ICT-projecten zijn geslaagd en organisaties waar ICT-projecten zijn mislukt en welke verschillen zijn er tussen de publieke en private sector?

37

projecten, het definiëren en monitoren van KRI’s en aansluiting tussen IT-risico’s en bedrijfsdoelen. Volgens de theorie wordt minstens de helft van het projectresultaat bepaald door de omgeving en de andere helft door de manier van beheersing. Uit voorgaande onderschrijven wij de stelling dat risicomanagement het verschil kan betekenen tussen het slagen of falen van ICT-projecten. Op basis van het praktijkonderzoek is vastgesteld dat risicomanagement modellen/procedures op zichzelf staand niet voldoende zijn voor een adequate beheersing van risico’s. Het blijkt dat soft skills van betrokkenen minstens zo belangrijk zijn. Rondom soft skills is voornamelijk het risicodenkende vermogen van project managers en overige betrokkenen voor een groot deel bepalend voor het slagen/falen. Voor het inrichten van adequaat risicomanagement rondom projecten biedt het toetsingskader (hoofdstuk 5) dat is afgeleid uit theorie en praktijk handvaten. Op basis van de hierin beschreven principes, processen, risicocategorieën, informatiemanagement, verantwoordelijkheden en benodigde soft skills kan adequaat risicomanagement rondom ICT-projecten worden ingericht en daarmee het verkrijgen van (de beoogde) positieve bedrijfswaarde uit IT-gerelateerde investeringen. Het uitgevoerde praktijkonderzoek in de hoofdstukken 4 en 5 bevestigt bovenstaande conclusie. Risicomanagement en risicodenkend vermogen zijn essentiële factoren in het slagen of falen van ICT-projecten. De significante verschillen in de toepassing hiervan tussen organisaties waar ICT-projecten wel zijn geslaagd en organisaties waar ICT-projecten zijn mislukt, zijn: Verschillen tussen de publieke en private sector Op basis van het theoretisch- en praktijk onderzoek is de conclusie dat zowel bij de publieke als bij de private sector sprake is van dezelfde kernproblemen, maar ook sprake is van verschillen tussenbeiden. De identieke kernproblemen die op basis van het onderzoek zijn geconstateerd zijn:

Echter zijn een aantal verschillen geconstateerd tussen de publieke en private sector:

De complexiteit bij de publieke sector is relatief specifiek, mede als gevolg van de diverse organisaties die betrokken zijn en het dynamische karakter van weten regelgeving. Het gat tussen de business en IT bij de overheid is groter. Voorts is de mate waarin betrokkenen bij een project dienen te beschikken over soft skills specifiek aangekaart als succesfactor binnen de private sector. Echter is op basis van het onderzoek bij de publieke sector geconstateerd dat in alle formele rapportage nog geen aandacht hieraan is besteed en dat is opmerkelijk.

§ De planning van ICT-projecten wordt vaak te ambitieus opgesteld; en § Complexiteit van de projectomgeving, zoals verdeelde stakeholders, de relatie tussen

business en ICT en technische complexiteit.

§ De toepassing van risicomanagement zowel voor de start (bij de haalbaarheidsonderzoekfase) als gedurende de gehele levenscyclus van ICT-projecten;

§ Gedurende de uitvoering van risicomanagement zullen naast de risico’s op het gebied van de interne projectbeheersing, ook de risico’s ten aanzien van de (technische) complexiteit van projecten specifiek moeten worden geadresseerd;

§ Het besturen van projecten vanuit KRI’s in plaats van KPI’s; § De kwaliteit van de projectmanager om de relatie tussen de business en ICT te beheersen en

tevens kunnen zorgdragen voor continue betrokkenheid van alle stakeholders tijdens het project;

§ Projectmanagers die beschikken over de benodigde soft skills en deskundigheid om tijdig te signaleren dat er problemen binnen het project.

38

Literatuurlijst § Artikel: Algemene Rekenkamer (2007), Lessen uit ICT-Projecten bij de Overheid Deel A. § Artikel: Algemene Rekenkamer (2008), Lessen uit ICT-Projecten bij de Overheid Deel B. § Artikel: Barrow e.a., APM Risk Specific Interest Group (2008), APM White Paper on Soft Skills in

Risk Management. § Artikel: College (2006), Memo Advies betreffende ICT-beleid om administratieve lasten te

verminderen. § Artikel: Committee of Sponsoring Organizations of the Treadway Commission (2004), Enterprise

Risk Management – Integrated Framework – Management Samenvatting. § Artikel: Digitaal Bestuur (2006), Chris Verhoef, Explosief Mengsel. § Artikel: Elieson (2006), Construction of an IT Risk Framework. § Artikel: Ernst & Young (2007), Managing Information Technology Risk: A Global Survey for the

Financial Services Industry. § Artikel: http://www.cio.com (2008), Tips to an Effective IT Risk Management Plan for Financial

Services. § Artikel: ITGI (2007), The CobiT Framework 4.1. § Artikel: ITGI (2008), The Val IT Framework 2.0. § Artikel: ITGI (2009), The Risk IT Framework, Exposure Draft. § Artikel: MAB (2005), CobiT, opkomst, ondergang en opleving van een raamwerk voor

informatiebeheersing. § Artikel: MAB (2008), De betekenis van IT-auditing voor risicobeheersing en IT-governance. § Artikel: Maes (2003), Informatiemanagement in kaart gebracht. § Artikel: MCA (2007), Projectmanagement: Lessen uit Falende en Succesvolle ICT-Projecten:

Controllers moeten vanaf de Start een Rol spelen. § Artikel: Ministerie van Sociale Zaken en Werkgelegenheid (2008), Tussenrapportage Resultaten

onderzoek Wia-systeem. § Artikel: Symantec (2007), IT Risk Management Report: Trends through December 2006. § Artikel: Symantec (2008), IT Risk Management Report 2: Myths and Realities. § Artikel: Stoneburner e.a., (2002), Risk Management Guide for Information Systems. § Boek: Christiaanse en van Praat (2005), Inrichten en beheersen van organisaties. § Boek: Harmon (2003), Business Process Change. § Boek: Onna e.a. (2007), De Kleine Prince2. § Boek: van Praat en Suerink (2004), Inleiding EDP-Auditing. § Boek: Strijen, B. van en G. Kleyn (1994), Risicomanagement in IT-projecten. § Presentatie: NOREA (2005), Presentatie Hans Donkers, Project Governance en Risk Management

binnen projecten.

http://www.cio.com

39

Bijlagen

Bijlage I. CobiT Framework

Figuur 1 Overall Cobit Framework

40

Bijlage II

Figuur 2 Risk IT domeinen

41

Bijlage II

Figuur 3 Rollen en verantwoordelijkheden en Risk IT

42

Bijlage III Maturity model Investment Management

44

Bijlage IV

Figuur 4 Uitvoering van IT Risk Management (Ernst&Young, 2007). IT Risk Management area Positive trends Areas for improvement

Formalization of programs is underway Program governance and spending IT Risk Management Program Maturity and Effectiveness Investments in programs are increasing Awareness of and education about Risk

Management IT Risk Management functions exist in a majority of the organizations

Taxonomy and common risk languages across all risk functions

Convergence

Need for integration is being recognized Alignment with other Risk Management functions

Increase in process automation investment (efficiencies and process optimization)

Common control libraries and standard reporting processes

IT Risk Management processes

Formal IT Risk framework and assessment processes in place

Risk assessment efficiencies

Tools and technology Spending projections are increasing to assist with optimization and automation

Using tools for optimization after establishing effective processes

Tools and technology enable capabilities More holistic and robust risk reporting to management

Reporting and metrics

Metrics and reporting assist in communicating value

Common reporting framework

Tabel 1. Geconstateerde positieve trends en verbeterpunten (Ernst & Young, 2007).

45

Bijlage V

Figuur 5 Het Negenvlaksmodel (Maes, 2003)

46

Bijlage VI De tabel hieronder weergeeft de modellen die zijn gebruikt voor het samenstellen van de theoretische toetsingskader. COSO CobiT Risk IT Val IT CMMI Prince2 NIST Overige theorie Theoretisch toetsingskader Doel model

Het bieden van ondersteuning aan het bestuur van organisaties bij de beheersing van de bedrijfs-processen van de onderneming.

Zorgdragen voor een adequate beveiliging en beheersing van de informatievoorziening.

Zorgdragen voor adequate processen rondom het managen van bedrijfsrisico’s gerelateerd aan het gebruik van IT.

Zorgdragen voor het verkrijgen van (de beoogde) positieve bedrijfswaarde uit IT-gerelateerde investeringen.

Het verbeteren van de processen ten aanzien van systeem-ontwikkeling.

Waarborgen dat het resultaat van projecten op een beheerste wijze conform de gedefinieerde acceptatiecriteria worden opgeleverd.

De ontwikkeling van een effectief risicobeheersing programma rondom informatiesystemen.

N/A Doel: Adequaat risicomanagement rondom ICT-projecten en daarmee het verkrijgen van (de beoogde) positieve bedrijfswaarde uit IT-gerelateerde investeringen.

Princi-pes

Het analyseren en beheersen van verbanden tussen de ondernemings-risico’s en het interne beheersings-systeem.

Vijf focus-gebieden van IT governance: – Strategic Alignment; – Value Delivery; – Risk management; – Resource Management; – Performance Measurement.

1. Effectieve besturing van IT-risico’s. In alle gevallen dient te worden geborgd dat er een aansluiting tussen IT-risico’s en bedrijfsdoelen plaatsvindt. 2. Effectief management van IT-risico’s; - eerlijke en open communicatie ten aanzien van IT-risico’s; - juiste stimulans vanuit het topmanagement; - uitvoeren van IT risicomanagement als een continu proces en als onderdeel incorporeren in de dagelijkse werkzaamheden.

IT-gerelateerde investeringen: - worden gezien en

gemanaged als portfolio; - omvatten alle activiteiten die

benodigd zijn om de potentiële bedrijfswaarde te realiseren;

- worden gemanaged in de gehele economische levenscyclus.

Value delivery praktijken: - erkennen dat er verschillende

investeringscategorieën bestaan met verschillende typen risico’s;

- definiëren en monitoren de kritieke prestatie indicatoren;

- betrekken alle stakeholders en kennen verantwoordelijkheden toe voor de aanlevering van capaciteiten en de realisatie van bedrijfswaarde;

- worden continu bewaakt,

Binnen CMM zijn een vijftal niveaus van volwassenheid gedefinieerd, inclusief procesdoelen, die een basis vormen voor continue procesverbetering van het systeemontwikkelings-proces:

7 Initial level; 8 Repeatable level; 9 Defined level; 10 Managed

level; 11 Optimizing

level.

Richtlijnen moeten worden opgesteld door de stuurgroep voor het analyseren, beheersen en bewaken van risico’s. Deze richtlijnen dienen verder de verantwoordelijkheden hiervoor te verdelen en dienen in lijn te zijn met het gedefinieerde “risk appetite” en “risk tolerance” van de organisatie te zijn

Een effectief systeem van risicomanagement dient volledig geïntegreerd te zijn met het systeem ontwikkelingsproces. Risicomanagement is een iteratief proces dat kan worden uitgevoerd gedurende elke relevante fase van het systeem ontwikkelingsproces.

N/A Principes: –betrouwbare en accurate voorspellingen van kosten en uitkomsten; –aansluiting tussen IT-risico’s en bedrijfsdoelen; –effectief management van IT-risico’s als continu proces en als onderdeel van de dagelijkse werkzaamheden; –Portfolio Management gericht op potentiële bedrijfswaarde van investeringen en realisatie hiervan; –definiëren en monitoren van KPI’s; –betrekken stakeholders en toekennen verantwoordelijk-heden voor risico-management en voor de beheersing van IT-investeringen; volledige integratie

47

COSO CobiT Risk IT Val IT CMMI Prince2 NIST Overige theorie Theoretisch toetsingskader geëvalueerd en verbeterd waar mogelijk.

risicomanagement met systeem ontwikkelingsproces.

Pro-cessen

ERM: – Interne omgeving; – Doelstelling; – Risico identificatie; – Risico beoordeling; – Risico response; – Controle activiteiten; Informatie en communicatie; Monitoring.

Risicobeheersing: a) IT Risicobeheersing raamwerk; b) Risico context; c) Risico identificatie; d) Risicoanalyse; e) Risicoresponse; f) Onderhoud en bewaking van het actieplan voor risico’s. CobiT definieert een specifieke maatregel voor de beheersing van projecten binnen het proces Planning en Organisatie. Deze maatregel heeft als doel projectresultaten op te leveren binnen de met de business afgestemde tijdslijnen, budget en kwaliteit. Specifieke projectrisico’s dienen te worden geëlimineerd of geminimaliseerd d.m.v. een systematisch proces voor het plannen, identificeren, analyseren, reageren, bewaken en beheersen van de gebieden die een potentiële ongewenste impact op het project kunnen hebben.

a) Risk Governance; waarborgt dat de uitvoering van IT risicomanagement verweven is binnen de organisatie met als doel een optimale “risk-adjusted return” te bereiken. b) Risk Evaluation; waarborgt dat IT-gerelateerde risico’s en kansen worden geïdentificeerd en geanalyseerd en worden gepresenteerd in begrijpelijke bedrijfstermen. c) Risk Response; waarborgt dat IT-gerelateerde risico issues, kansen en gebeurtenissen worden geadresseerd op een kosteneffectieve wijze en in overeenstemming met de bedrijfsprioriteiten.

a) Value Governance; het volwassenheidsniveau van de waardemanagement praktijken binnen de organisatie. b) Portfolio Management; het managen van het portfolio aan IT-gerelateerde investeringen op het gebied van optimale bedrijfswaarde. c) Investment Management; de contributie van individuele IT-gerelateerde investeringen aan optimale bedrijfswaarde. Gedurende het uitvoeren van Portfolio Management en Investment Management speelt risicomanagement (risicoanalyse, evaluatie en response) een grote rol. Het beginpunt van risicomanagement ligt bij het samenstellen van de business case. Bij bijna alle Investment Management processtappen wordt de risicoanalyse heroverwogen en vindt monitoring plaats op het gebied van prestatie (het verkrijgen van positieve bedrijfswaarde uit de investering).

Voor het bereiken van het CMM niveau drie en de daarop volgende niveaus, is het van wezenlijk belang dat risicomanagement in het systeemontwikkelingsproces is geïmplementeerd en verankerd (Elieson, 2006). Dit kan worden bewerkstelligd bij de beheersing van de levenscyclus van het informatiesysteem en de toepassing van een project management methodologie gedurende het proces van systeem ontwikkeling.

Acht hoofdprocessen: – Opstarten; – Initiëren; – Dirigeren; – Beheersen van een fase; – Managen van product oplevering; – Managen van faseovergangen; – Afsluiten; – Opstellen van een plan.

Systeem ontwikkelingsfasen: – Initiatie; – Ontwikkeling of acquisitie; – Implementatie; – Exploitatie en beheer; – Uitfasing.

Risk Management wordt tenminste uitgevoerd bij de volgende mijlpalen: –Project preparation; –Business blueprint; –Realisatie; –Going life; –Post implementatie.

Processen: a) Value/Risk Governance; b) Portfolio Management; c) Investment Management; Risk Analysis, -Evaluation en –Response worden uitgevoerd als onderdeel van Portfolio- en Investment Management. De business case, risicoheroverweging en monitoring staan gedurende de gehele levenscyclus van de investering centraal in het kader van risicomanagement. Voorts wordt risicomanagement tenminste uitgevoerd bij de volgende mijlpalen: –Project preparation; –Business blueprint; –Realisatie; –Going life; –Post implementatie.

48

COSO CobiT Risk IT Val IT CMMI Prince2 NIST Overige theorie Theoretisch toetsingskader Risico-catego-rieën

N/A. Geen specifieke categorieën benoemd t.a.v. risico’s rondom ICT-projecten.

N/A. Algemene noemer die wordt gebruikt is “projectrisico’s”.

Delivery risk—Het risico op het niet leveren van de beoogde capaciteiten. Bijvoorbeeld: - Kwaliteit van het programma en project plan; - Interfaces met bestaande systemen en processen; - Ervaring/kwaliteit van de betrokken project managers en project teams. Benefits risk—Het risico op het niet behalen van de beoogde resultaten/voordelen. Bijvoorbeeld: - Duidelijkheid en aannemelijkheid van gewenste bedrijfsuitkomsten; - Gevoeligheid van de uitkomsten voor timing of externe afhankelijkheden, inclusief wijzigingen in de economie, marktcondities of een specifieke industriesector; - De mate waarin organisatorische verandering is vereist en duidelijkheid omtrent scope. Aan de basis liggen betrouwbare en accurate voorspellingen van kosten, uitkomsten en profijt uit projecten. Het Val IT model bevat een uitgebreide opsomming van mogelijke risico drivers per risicocategorie.

N/A. Geen specifieke categorieën benoemd t.a.v. risico’s rondom ICT-projecten.

Acht specifieke componenten voor het minimaliseren van projectrisico’s: – Organisatie; – Plannen; – Beheersing; – Fasen; – Risicobeheer; – Kwaliteits-beheer; – Configuratie-beheer; – Wijzigings-beheer.

Categorisatie naar de fasen uit het systeem ontwikkelingsproces.

–Projectuitgangssituatie; –Projectdoelstellingen en afstemming op de bedrijfsdoelstellingen; –Sociale/organisatorische complexiteit; –Technische/functionele complexiteit; –Projectmedewerkers; –Projectorganisatie; –Projectbeheer en beheersing; –Projecthulpmiddelen en –technieken; –IT-risico’s security, beschikbaarheid, performance en compliance. De betreffende complexiteit van het ICT-project kan op deze wijze worden beheerst.

Risicocategorieën: a) Delivery risk—Het risico op het niet leveren van de beoogde capaciteiten. b) Benefits risk—Het risico op het niet behalen van de beoogde resultaten/voordelen. Risicocategorieën kunnen worden onderverdeeld op basis van de fasen uit het systeem ontwikkelingsproces. De complexiteit van ICT-projecten dient te worden beheerst op basis van de interne risicocategorieën (bijv. projectbeheer en –beheersing) en de categorieën die worden opgelegd uit de omgeving (bijv. sociale/organisatorische complexiteit).

Benodig-de soft skills

- - De benodigde resources, inclusief project managers, -teams en personen vanuit de business dienen te worden gespecificeerd als onderdeel van de planning. Als onderdeel hiervan dient te worden gespecificeerd wat de basis principes zijn voor het aannemen en toewijzen van competente stafleden en/of contractors aan projecten.

- - - De kennis, ervaring en het risicodenkende vermogen van project managers en overige betrokkenen kunnen voor een groot deel bepalend zijn voor het succes of mislukken van projecten.

Benodigde soft skills: Kennis, ervaring en het risicodenkende vermogen van project managers en overige betrokkenen zijn voor een groot deel bepalend.

Risicomanagement en ICT-projecten - VUrORE · 2012-04-18 · Cobit Risicomanagement en Value...

Documents

Transcript of Risicomanagement en ICT-projecten - VUrORE · 2012-04-18 · Cobit Risicomanagement en Value...