Governance en IT-projecten

Vrije Universiteit Amsterdam IT Audit opleiding

Governance en IT-projecten

Normatief kader voor het opzetten, uitvoeren en monitoren van IT-projecten

Naam: Adres:

E-Mail: Studentnummer: Teamnummer:

drs. J. (Jasper) de Vries Barwerd 12 9746 CT Groningen +31 (0)50 525 8895 +31 (0)6 2908 4522 [email protected] 9981263 838

Werkgever: Telefoonnummer: Fax:

Ernst&Young EDP Audit, Apeldoorn +31 (0)55 529 1400 +31 (0)55 529 1350

Bedrijfscoach E&Y: Begeleider VU:

drs. I.N. (Ivo) Kouters drs. R. (Rob) Christiaanse RA

Telefoonnummer:


Voorwoord

Voorwoord Deze scriptie is geschreven ter afsluiting van de postdoctorale opleiding IT Audit aan de Vrije Universiteit Amsterdam. Het schrijven van deze scriptie is uitdagend en zeer leerzaam geweest waarbij ik het gevoel heb dat mijn kennis van de materie is toegenomen. Met name de samenhang tussen diverse theoretische modellen en de praktijk heeft mij toepasbare kennis en inzicht opgeleverd welke van grote toegevoegde waarde zijn voor het uitoefenen van mijn vak. Graag wil ik vanaf deze plaats als eerste Marieke en Thijmen bedanken voor de ruimte die ze mij de afgelopen jaren maar zeker ook de afgelopen periode thuis hebben gegeven om de studie te volgen en deze scriptie te schrijven. Een bijzonder woord van dank gaat verder uit naar drs. Rob Christiaanse RA en drs. Ivo Kouters voor alle coaching en alle momenten van overleg gedurende het soms moeilijke proces van de totstandkoming van deze scriptie. Verder wil ik drs. Floris de Vries RE, Jolien Wegter en Renate Chen bedanken voor het kritisch meelezen en het leveren van constructief commentaar hetgeen de kwaliteit van deze scriptie ten goede is gekomen. Tenslotte wil ik mijn ouders en schoonouders, collega’s en vrienden bedanken voor hun ondersteuning en support. Groningen, maart 2008

© 2008 - J. de Vries

ii


Inhoudsopgave

Inhoudsopgave Voorwoord

ii

Inhoudsopgave

iii

1

2

Inleiding 1.1

Aanleiding van het onderzoek

1

1.2

Vraagstelling

1

1.3

Afbakening

2

1.4

Aanvullende onderzoeksvragen

2

1.5

Onderzoeksmethode

2

1.6

Leeswijzer

2

Governance en IT-projecten 2.1

3

1

Inleiding

3 3

2.2 Governance elementen 2.2.1 Sturen 2.2.2 Beheersen 2.2.3 Toezicht (houden) 2.2.4 Verantwoorden

3 3 3 4 4

2.3 Corporate Governance 2.3.1 COSO

5 5

2.4 IT Governance 2.4.1 CobiT 2.4.2 Negenvlaksmodel

6 7 8

2.5 Projectgovernance 2.5.1 Projectgovernance en IT-projecten 2.5.2 Kenmerken van (IT-)projecten 2.5.3 Prince2 2.5.4 Invulling Prince2 aan de governance elementen 2.5.5 Invulling Prince2 aan COSO en CobiT

9 9 9 10 11 12

2.6

13

Afsluiting

Succes- en faalfactoren van IT-projecten 3.1

Inleiding

3.2 Succesfactoren in de theorie 3.2.1 Succesfactoren 3.2.2 Succesfactoren ten opzichte van de governance elementen 3.2.3 Succesfactoren ten opzichte van Prince2


14 14 14 14 15 15

iii


4

3.3 Faalfactoren in de praktijk 3.3.1 Faalfactoren 3.3.2 Faalfactoren ten opzichte van de succesfactoren 3.3.3 Faalfactoren ten opzichte van de Prince2 componenten

16 16 17 18

3.4 Faalfactoren: een praktijkcasus 3.4.1 Inleiding 3.4.2 Casusbeschrijving 3.4.3 Faalfactoren

19 19 20 20

3.5

21

6

Afsluiting

Normatief kader Governance IT-projecten 4.1

5

Inhoudsopgave

22

Inleiding

22

4.2 De ‘rode draad’ 4.2.1 Een analyse 4.2.2 Conclusie

22 22 23

4.3 Normatief kader 4.3.1 ‘Planning en fasering’ en ‘Projectorganisatie en besturing’ 4.3.2 ‘Cultuur en gedrag’

23 23 24

4.4

27

Afsluiting

Rol van de IT-auditor binnen IT-projecten

28

5.1

Inleiding

28

5.2

Welke rol dient de IT-auditor te spelen

28

5.3

Afsluiting

29

Conclusie en persoonlijke reflectie

30

6.1

Inleiding

30

6.2

Conclusie

30

6.3

Persoonlijke reflectie

31

Literatuurlijst

II

Bijlage 1 - COSO

IV

Bijlage 2 - CobiT

V

Bijlage 3 - Negenvlaksmodel

VI

Bijlage 4 - Prince2

VII


iv


Hoofdstuk 1 - Inleiding

1

Inleiding

1.1

Aanleiding van het onderzoek

Door bedrijven worden steeds hogere eisen gesteld aan Informatie Technologie, ofwel IT. Jaarlijks worden binnen organisaties dan ook vele IT-projecten gestart. Deze projecten variëren van de aanschaf van nieuwe hardware tot en met de implementatie van nieuwe pakketten of informatiesystemen, waarbij het hart van de organisatie wordt geraakt, bedrijfsprocessen moeten worden aangepast op nieuwe werkwijzen waarbij meerdere partijen, zowel intern als extern, betrokken kunnen zijn. Hoe complexer de materie, des te lastiger is het om projecten tot een goed einde te brengen, zodanig dat uiteindelijk sprake is van een succesvol IT-project. Hoewel in de markt diverse frameworks beschikbaar zijn welke organisaties kunnen helpen in het opzetten, uitvoeren en monitoren van projecten, blijken er in de praktijk veel IT-projecten te ‘mislukken’. Veel zogenaamde IT-projecten zijn geen IT-projecten, maar raken een groot deel van de hele organisatie en moeten daarom niet alleen tot het domein van de IT worden gerekend. Als zulke zogenaamde ITprojecten niet goed gaan hebben de oorzaken vaak niet alleen maar met IT te maken, maar hebben deze een veel breder karakter waarbij de volledige IT-keten, van businessstrategie tot operationele (IT-) processen, geraakt wordt. Het onderwerp van deze scriptie is het in kaart brengen welke succesfactoren bestaan voor IT-projecten en welke faalfactoren er in de praktijk zijn voor het ‘mislukken’ van IT-projecten. Vervolgens worden de faalfactoren uit de praktijk afgezet tegen de succesfactoren en wordt onderzocht in welke mate de governance frameworks COSO, CobiT, het Negenvlaksmodel en Prince2 bijdragen aan de succesfactoren, om tenslotte te komen tot een model in de vorm van een normatief kader, vanuit het perspectief van het management, op basis waarvan IT-projecten kunnen worden opgezet, uitgevoerd en gemonitord. Daarnaast wordt onderzocht of de IT-auditor hierin een rol dient te spelen en welke rol dit dan zou moeten zijn.

1.2

Vraagstelling

Op basis van de in paragraaf 1.1 uiteengezette aanleiding van het onderzoek is de volgende vraagstelling geformuleerd:

Hoe kan een normatief kader voor het opzetten, uitvoeren en monitoren van IT-projecten er vanuit het perspectief van het management uit zien? Welke elementen dienen hier minimaal in te zitten en wat is de rol van de IT-auditor? Figuur 1: Vraagstelling.


1


1.3

Hoofdstuk 1 - Inleiding

Afbakening

Onderwerp van onderzoek zal zijn IT-projecten in het kader van nieuwbouw en implementatie van maatwerk (zelfbouw) systemen.

1.4

Aanvullende onderzoeksvragen

Om een antwoord te kunnen geven op de geformuleerde vraagstelling dienen de volgende deelvragen beantwoord te worden: 1 Wat wordt verstaan onder governance? 2 Welke governance frameworks worden onderscheiden en in welke mate geven de governance frameworks invulling aan het begrip governance? 3 Welke succesfactoren van IT-projecten worden in de theorie en de praktijk onderkend? 4 In welke mate dragen de governance frameworks bij aan de succesfactoren? 5 Hoe kan op basis van de theorie en de praktijk worden gekomen tot een normatief kader voor het opzetten, uitvoeren en monitoren van IT-projecten en welke elementen dienen hier dan minimaal in te zitten? 6 Welke rol dient de IT-auditor te spelen binnen IT-projecten?

1.5

Onderzoeksmethode

Het onderzoek zal worden uitgevoerd door enerzijds literatuuronderzoek en anderzijds door gebruik te maken van beschikbare informatie binnen onze organisatie. Hierbij moet gedacht worden aan het interviewen van collega’s en eigen praktijkervaringen aangaande het onderwerp. Validatie van het normatieve kader zal plaatsvinden na voltooiing van de scriptie door deze voor te leggen aan relevante functionarissen en te toetsen op relevantie en bruikbaarheid in de praktijk.

1.6

Leeswijzer

De opbouw van de scriptie is conform bovengenoemde aanvullende onderzoeksvragen 1 tot en met 5. Hoofdstuk 2 Governance en IT-projecten gaat in op deelvragen 1 en 2. In hoofdstuk 3 Succes- en faalfactoren van IT-projecten wordt nader ingegaan op de deelvragen 3 en 4. Deelvraag 5 wordt vervolgens uitgewerkt in hoofdstuk 4 Normatief kader Governance IT-projecten. De rol van de auditor, deelvraag 6, wordt behandeld in hoofdstuk 5 Rol van de IT-auditor binnen IT-projecten. De scriptie wordt afgesloten met een conclusie, welke zal worden uitgewerkt in het laatste hoofdstuk, hoofdstuk 6 Conclusie en persoonlijke reflectie. Referenties naar literatuur, artikelen en internet sites worden in de tekst aangegeven als een numerieke verwijzing naar de literatuurlijst. De verwijzing is als volgt weergegeven: [1] betekent een verwijzing conform de literatuurlijst naar: Onna, Koning, De Kleine Prince2, Academic Service 2007.


2


Hoofdstuk 2 - Governance en IT-Projecten

2


2.1

Inleiding

Organisaties worden geconfronteerd met veranderingen, die in de praktijk in projectvorm worden uitgevoerd. Deze veranderingen blijken zowel oorzaak als gevolg te zijn van wetenschappelijke en technologische ontwikkelingen die organisaties in al haar facetten tot en met haar volledige maatschappelijke omgeving raken. Veranderingen bieden uiteraard ook kansen voor diezelfde organisaties, maar om die te kunnen grijpen en de daarbij horende risico’s te kunnen beheersen, is het strikt noodzakelijk dat binnen de organisatie een systeem van efficiënte en effectieve Governance wordt opgebouwd. Maar wat is nu eigenlijk governance? Hoewel er meerdere definities van governance zijn, komen vier elementen in iedere definitie terug, die onderling met elkaar samenhangen en met elkaar in balans moeten zijn [6].

Governance gaat over: Sturen; Beheersen; Toezicht (houden); Verantwoorden. Figuur 2: Definitie Governance.

2.2

Governance elementen

Deze vier elementen zijn van belang in het kader van het goed besturen van organisaties en het aantoonbaar maken dat dit ook goed gebeurt. Deze kunnen als volgt nader worden afgebakend.

2.2.1 Sturen Richting gevend aan het realiseren van organisatiedoelen, onder meer door het inrichten van de organisatie en het vormgeven van processen. Op strategisch niveau bevat sturen het proces waarbij het bestuur richting geeft aan het realiseren van vastgestelde beleidsdoelstellingen, onder meer door het inrichten van de organisatie en het vormgeven van processen van beleidsuitvoering.

2.2.2 Beheersen Nadat een organisatie is ingericht, moet een stelsel van maatregelen en procedures worden ingevoerd en gehandhaafd, zodat bestuurders de zekerheid krijgen dat de organisatie blijvend de juiste richting opgaat, dat wil zeggen de vastgestelde beleidsdoelstellingen realiseert.


3



2.2.3 Toezicht (houden) Ten behoeve van alle belanghebbenden moet kunnen worden vastgesteld dat de doelstellingen van de organisatie (op strategisch niveau de vastgestelde beleidsdoelstellingen) worden gerealiseerd.

2.2.4 Verantwoorden Over alle opgedragen taken en gedelegeerde bevoegdheden moet informatie worden verschaft, hieraan is gekoppeld het recht op decharge. Op strategisch niveau betekent dit dat het bestuur naast de verantwoording over de uitkomsten van de uitvoering van het beleid ook over het sturen, beheersen en het houden van toezicht verantwoording moet afleggen. In Figuur 3 is governance in relatie met de vier elementen: Sturen, Beheersen, Toezicht (houden) en Verantwoorden weergegeven.

Figuur 3: Governance in relatie met de elementen: Sturen, Beheersen, Toezicht (houden) en Verantwoorden.

Ten aanzien van governance is een verdere indeling mogelijk in. In het kader van deze scriptie worden de vormen Corporate Governance, IT Governance en Projectgovernance onderscheiden. In de paragrafen 2.3, 2.4 en 2.5 wordt nader ingegaan op deze vormen en wordt een aantal governance frameworks, welke organisaties ondersteunen bij het geven van een goede invulling aan de vier governance elementen, nader beschouwd.


4


2.3


Corporate Governance

Op internationaal niveau en in tal van landen zijn de afgelopen jaren regels en aanbevelingen inzake Corporate Governance opgesteld voor bedrijven. In de Verenigde Staten is de regelgeving over governance vastgelegd in de Sarbanes-Oxley wet. Nederland heeft hiervoor de code Tabaksblat opgesteld. In België werkt men met de code Lippens voor beursgenoteerde bedrijven en de code Buysse voor nietbeursgenoteerde bedrijven. Door Corporate Governance in de wet te verankeren worden organisaties geconfronteerd met en verplicht tot het invoeren van een adequaat stelsel van interne beheersmaatregelen. Maar wat is nu eigenlijk Corporate Governance? De essentie van Corporate Governance is het goed besturen van organisaties en het aantoonbaar maken dat dit ook goed gebeurt [14]. De definitie die door de Organisation of Economic Co-operation and Development (OECD) is ontwikkeld, luidt als volgt [2]:

“Corporate Governance is the system by which business corporations are directed and controlled. The Corporate governance structure specifies the distribution of rights and responsibilities among different participants, such as the board, managers, shareholders and other stakeholders, and spells out the rules and procedures for making decisions on corporate affairs. By doing this, it also provides the structure through which the company objectives are set, and the means of attaining those objectives and monitoring performance”. Figuur 4: Definitie Corporate Governance volgens de OECD.

Ten aanzien van Corporate Governance is het COSO framework het meest bekend. In paragraaf 2.3.1 wordt nader ingegaan op het COSO framework.

2.3.1 COSO Als een organisatie haar doelstellingen wil bereiken dan moet ze omgaan met risico’s en moet ze deze risico's proberen te beheersen. In 1992 is door de Committee of Sponsoring Organizations of the Threadway Commission een rapport gepubliceerd waarin het COSO Internal Control - Integrated Framework werd gepresenteerd. De centrale doelstelling die ten grondslag ligt aan het COSO framework is het bieden van ondersteuning aan het management van organisaties bij de beheersing van de activiteiten van de organisatie. In 2004 is COSO Enterprise Risk Management (ERM) gepubliceerd en staat bekend als COSO II. Het ERM framework is een uitbreiding op het COSO Internal Control - Integrated Framework en is een meer risicogeoriënteerd framework [2]. Het COSO framework identificeert de relaties tussen de ondernemingsrisico’s en het interne beheersingsysteem. Het model geeft in de COSO-kubus de directe relatie weer tussen [22] [32]: de doelstellingen van een organisatie; de controlecomponenten; de activiteiten/eenheden waarvoor de interne controle benodigd is. De COSO-kubus is weergegeven in Bijlage 1 (Figuur 11: COSO - kubus.).


5



COSO hanteert de gedachten dat interne beheersing een proces is dat gericht is op het verkrijgen van een redelijke mate van zekerheid omtrent het bereiken van doelstellingen op het gebied van [22] [32]: Strategisch: bereiken van de strategische doelstellingen; Operationeel: effectiviteit en efficiëntie van bedrijfprocessen; Rapportage: betrouwbaarheid van de financiële informatieverzorging; Toezicht: naleving van relevante weten regelgeving. Vervolgens definieert het model een achttal samenstellende controlcomponenten die in samenhang met elkaar dienen te worden beschouwd [22] [32]: Internal Environment: de mate waarin risico’s worden genomen; Risk Assessment: de risico-inschatting of de beoordeling van de geïdentificeerde risico’s en daarmee de waarschijnlijkheid dat een risico zich zal voordoen en de gevolgen indien het zich voordoet; Control Activities: de getroffen controleactiviteiten; Information and Communication: informatie en communicatie; Monitoring: monitoring van de controleactiviteiten.

2.4

IT Governance

Wat is eigenlijk IT Governance? Er bestaan verschillende definities van IT Governance. De definitie die ontwikkeld is door het IT Governance Institute (ITGI), luidt als volgt [6] [24]:

“IT Governance is the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership and organizational structures and processes that ensure that the organization’s IT sustains and extends the organization’s strategy and objectives”. Figuur 5: Definitie IT Governance volgens de ITGI.


6



De definitie die door de Organisation of Economic Co-operation and Development (OECD) is ontwikkeld, luidt als volgt [2]:

“IT Governance is the system by which IT within enterprises is directed and controlled. The IT Governance structure specifies the distribution of rights and responsibilities among different participants, such as the board, business and IT managers, and spells out the rules and procedures for making decisions on IT. By doing this, it also provides the structure through which the IT objectives are set, and the means of attaining those objectives and monitoring performance”. Figuur 6: Definitie IT Governance volgens de OECD.

IT Governance is direct met Corporate Governance verbonden en gaat over het besturen, beheersen, uitvoeren, verantwoording afleggen over en het toezicht op de informatievoorziening binnen een organisatie. De uitgangspunten van Corporate Governance vertalend naar de betekenis voor IT Governance levert een drietal aandachtsgebieden op [21]: de beheersing van IT-risico’s binnen een organisatie. Het gaat hierbij om het besturen, beheersen en uitvoeren van de informatievoorziening; het aantoonbaar uitoefenen van toezicht op de beheersing van IT-risico’s; het afleggen van verantwoording over de beheersing van IT-risico’s. Informatievoorziening ondersteunt een organisatie bij het realiseren van haar doelstellingen. De toepassing van IT stelt een organisatie in staat producten efficiënter en effectiever te produceren, innovatiever te zijn en processen beter te beheersen. De verwachtingen van een organisatie ten aanzien van de kwaliteit van informatievoorziening, functionaliteit, gebruikersgemak en snelheid van oplevering van nieuwe systemen zijn sterk toegenomen. Daarnaast vragen de snelheid van veranderingen op het gebied van IT en de snelheid van veranderingen binnen organisaties om een adequate beheersing van de IT-risico’s.

2.4.1 CobiT Een belangrijk framework ter ondersteuning van IT Governance is, zoals reeds eerder gesteld, CobiT. Dit framework is vanaf 1994 ontwikkeld door de Information Systems Audit and Control Association (ISACA) en is een open, internationaal gehanteerde standaard voor het gestructureerd inrichten en beoordelen van de geautomatiseerde informatievoorziening. Het framework kan worden gezien als de IT specifieke invulling van het COSO framework. In de huidige, vierde versie van het CobiT framework is een duidelijke verschuiving waarneembaar van ‘control framework’ naar een ‘IT Governance framework’. CobiT (Control Objectives for Information and related Technology) hangt derhalve nauw samen met het begrip IT Governance. Het CobiT framework onderscheidt 318 beheersdoelstellingen, die zijn gerangschikt naar vier domeinen. Deze zijn vervolgens weer onderverdeeld in 34 IT-processen. [14]: Plan and Organise (PO); Acquire and Implement (AI); Deliver and Support (DS); Monitor and Evaluate (ME).


7



Het CobiT framework is weergegeven in Bijlage 2 (Figuur 12: Het CobiT framework.). Hierin is aangegeven hoe de vier domeinen samenhangen met de 34 IT-processen.

2.4.2 Negenvlaksmodel Hoewel het Negenvlaksmodel niet direct een IT-Governance framework is, dient het toch te worden meegenomen in de analyse van beschikbare frameworks en nader te worden onderzocht op een ondersteunende rol ten behoeve van het welslagen van IT-projecten. Het Negenvlaksmodel of het Amsterdams Informatiemanagement model is een hulpmiddel dat praktisch toepasbaar is bij het in kaart brengen van verantwoordelijkheden, rollen, processen en relaties tussen vraag en aanbod binnen organisaties [3] [19]. Zoals immers reeds gesteld in paragraaf 1.1, raken IT-projecten een groot deel van de hele organisatie en moeten daarom niet alleen tot het domein van de IT worden gerekend. Als IT-projecten niet goed gaan, hebben de oorzaken vaak niet alleen maar met IT te maken, maar hebben deze veelal een breder karakter waarbij de volledige IT-keten, van businessstrategie tot operationele (IT-) processen, geraakt wordt. Het Negenvlaksmodel relateert de processen van en de ondersteunende technologie voor (intern en extern) informeren en communiceren aan algemene bedrijfsaspecten. Dit wordt aangeduid middels de drie domeinen in de horizontale dimensie [28]: Bedrijfsdomein: in welke business opereert de organisatie, welke bedrijfsstrategie volgt ze en hoe is ze ingericht; Informatie- / communicatiedomein: op welke wijze vinden informatie- en communicatie processen plaats en in hoeverre faciliteert de informatievoorziening deze processen; Technologiedomein: hoe is de informatievoorziening binnen de organisatie vormgegeven, hoe wordt deze verder ontwikkeld en hoe is het management ervan ingericht. Daarnaast onderscheidt het Negenvlaksmodel drie besturingsniveaus. Deze worden weergegeven in de verticale dimensie [28]: Strategie: strategisch; Inrichting: tactisch; Uitvoering: operationeel. Het Negenvlaksmodel is weergegeven in Bijlage 3 (Figuur 13: Het Negenvlaksmodel.) [28]. Het Negenvlaksmodel maakt duidelijk dat veranderingen in de bedrijfsstrategie vaak veranderingen in de informatiebehoefte teweegbrengen en dat hierdoor veranderingen noodzakelijk kunnen zijn in de inrichting van IT. Nadrukkelijk wordt aandacht geschonken aan de zogenaamde koppelvlakken. Dit betekent dat goede afspraken moeten worden gemaakt over afbakening van taken en verantwoordelijkheden [19].


8


2.5


Projectgovernance

De term Projectgovernance wordt met name binnen de IT gebruikt voor het beschrijven van processen en beheersmaatregelen die minimaal dienen te zijn ingericht voor een succesvol project. Hoewel er geen eenduidige definitie van Projectgovernance bestaat, kan het volgende gesteld worden [7]:

Projectgovernance will: outline the relationships between all internal and external groups involved in the project; describe the proper flow of information regarding the project to all stakeholders; ensure the appropriate review of issues encountered within each project; ensure that required approvals and direction for the project is obtained at each appropriate stage of the project. Figuur 7: Definitie Projectgovernance.

2.5.1 Projectgovernance en IT-projecten Voor het ontwikkelen, grootschalig onderhouden, selecteren en/of invoeren van (delen van) informatiesystemen wordt vaak een project opgestart. Deze IT-projecten zijn vaak risicovol door de omvang en complexiteit van de systemen en de organisatorische context. Om een adequate ondersteuning van de bedrijfsprocessen door IT te kunnen waarborgen, is het slagen van een IT-project tegenwoordig steeds belangrijker. In de literatuur zijn verschillende definities te vinden voor projecten. Binnen de projectmethodiek Prince2 wordt de volgende definitie gehanteerd [1]:

“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”. Figuur 8: Definitie project volgens Prince2.

2.5.2 Kenmerken van (IT-)projecten Binnen de eerder aangehaalde projectmethodiek Prince2 wordt een aantal kenmerken genoemd op basis waarvan een project te herkennen is [1]: Het gewenste projectresultaat is weliswaar niet altijd volstrekt nieuw, maar bevat wel veel nieuwe elementen; Een project heeft een eindige, gedefinieerde levensduur met een vastgestelde start en finish; Er wordt eenmalig een maximale prestatie geleverd;


9



Er worden gedefinieerde producten opgeleverd; Er is een verzameling activiteiten om de producten op te leveren; Een gedefinieerde beperkte hoeveelheid menskracht en andere hulpmiddelen is nodig om het resultaat te bereiken; Er is een organisatiestructuur gedefinieerd met taken, verantwoordelijkheden en bevoegdheden om het project te beheersen; Er vindt continue evaluatie van de gedefinieerde businesscase plaats.

2.5.3 Prince2 Ten einde een project op een beheerste wijze uit te kunnen voeren, wordt veelal gebruik gemaakt van een projectmanagement methodiek. Zoals in hoofdstuk 2 reeds is aangehaald, is Prince2 één van de meest bekende en gebruikte methodieken voor projectmanagement en kan bijdragen aan een goede governance van een IT-project. De naam van de projectgovernance ondersteunende methodiek Prince2 is een samenvoeging van PRojects IN Controlled Environments en is een gestructureerde projectmanagement methode ontwikkeld door het Britse Office of Government Commerce. Sinds de introductie in 1989 is Prince2 een veel gebruikte methode in zowel de publieke als private sector. De methodiek is gebaseerd op bestaande methoden voor projectmanagement en een groot aantal casestudies in Groot-Brittannië. Prince2 is daardoor een integrale en universeel bruikbare bundeling van ‘Best Practices’ en hoewel het in eerste instantie is ontwikkeld voor het managen van IT-projecten, is de methode ook toepasbaar op niet IT-projecten. Prince2 is een proces georiënteerde benadering, waarbij elk proces is gedefinieerd op basis van input en output, gecombineerd met de specifiek te behalen doelen en activiteiten die moeten worden uitgevoerd om deze doelen te bereiken. De methode beschrijft hoe een project is verdeeld in beheersbare fasen, waardoor efficiënt gebruik van middelen en regelmatige monitoring van de voortgang gedurende het project mogelijk is. De volgende acht processen worden binnen het Prince2-procesmodel onderkend [1] [29]: Starting Up a Project: beschrijft de acties voorafgaand aan een project; Initiating a Project: beschrijft de start van de eerste projectfase; Directing a project: beschrijft de rol van projectboard; Controlling a Stage: beschrijft de het dagelijkse werk van de projectmanager; Managing Product Delivery: beschrijft de aanname en oplevering van werkopdrachten; Managing Stage Boundaries: beschrijft de overgang naar een volgende Stage (projectfase); Planning: beschrijft het planningsproces; Closing a Project: beschrijft het zorgen voor een gestructureerd projecteinde. Naast de acht processen worden binnen het Prince2-procesmodel de volgende acht componenten, als onderdelen van projectmanagement en bouwstenen voor de processen, onderkend [1] [29]: Business Case: beschrijft de redenen voor het project en de rechtvaardiging ervan; Organisation: beschrijft de verantwoordelijkheden van de verschillende rollen binnen de projectorganisatie; Plans: beschrijft de plannen die nodig zijn voor de productie van de juiste producten op het juiste tijdstip;


10



Controls: beschrijft de mechanismen om te komen tot rapportage over voortgang en afwijkingen ten behoeve van tijdige bijsturing; Management of Risk: beschrijft zowel handvatten om risicoanalyse en -beheersing uit te voeren als handvatten om beter te anticiperen op bedreigingen; Quality in a project environment: beschrijft hoe kan worden bijgedragen aan het bereiken van kwaliteitsverwachtingen en acceptatiecriteria; Configuration management: beschrijft hoe alle producten, ook de projectdocumentatie, moeten worden beheerd om efficiënt te kunnen werken; Change Control: beschrijft het beoordelen van en het stellen van prioriteiten aan voorgestelde wijzigingen. Dit aan de hand van het effect op het project, gemeten in tijd, geld, kwaliteit, bereik en risico’s.

Het Prince2 Procesmodel is weergegeven in Bijlage 4 (Figuur 14: Het Prince2 Procesmodel.). In paragraaf 2.5.4 zal worden ingegaan op de mate waarin Prince2 invulling geeft aan de governance elementen. In paragraaf 2.5.5 wordt vervolgens ingegaan op de mate waarin Prince2 invulling geeft aan de governance frameworks COSO en CobiT.

2.5.4 Invulling Prince2 aan de governance elementen Uitgaande van de governance elementen, zoals we benoemd hebben in paragraaf 2.2, wordt in onderstaande tabel aangegeven in welke mate de projectmethodiek Prince2 invulling geeft aan deze elementen.

Starting Up a Project Initiating a Project Directing a project Controlling a Stage Managing Product Delivery Managing Stage Boundaries Planning Closing a Project Tabel 1: Mapping governance elementen met Prince2.


Verantwoorden

Toezicht houden

Beheersen

Prince2 proces

Sturen


11



2.5.5 Invulling Prince2 aan COSO en CobiT

CobiT Proces

Prince2

COSO

Om inzicht te krijgen in de diepgang Prince2 als projectmethodiek binnen de governance frameworks, is het interessant te kijken in welke mate Prince2 invulling geeft aan COSO en CobiT. In onderstaande tabel is een door het IT Governance Institute (ITGI) opgestelde mapping opgenomen van CobiT met COSO en Prince2 [15].

Plan and Organise (PO) PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 AI1 AI2 AI3 AI4 AI5 AI6 AI7 DS1 DS2 DS3 DS4 DS5 DS6 DS7 DS8 DS9 DS10 DS11 DS12 DS13

Define a strategic IT plan Define the information architecture Define the technological direction Define the IT processes, organisation and relationships Manage the IT investment Communicate management aims and direction Manage IT human recources Manage quality Assess and manage IT risks Manage Projects Acquire and Implement (AI) Identify automated solutions Acquire and maintain application software Acquire and maintain technology infrastructure Enable operation and use Procure IT recources Manage changes Install and accredit solutions and changes Deliver and Support (DS) Define and manage service levels Manage third-party services Manage performance and capacity Ensure continuous service Ensure systems security Identify and allocate costs Educate and train users Manage service desk and incidents Manage the configuration Manage problems Manage data Manage the physical environment Manage operations


12


ME1 ME2 ME3 ME4

2.6


Monitor and Evaluate (ME) Monitor and evaluate IT performance Monitor and evaluate internal controls Ensure compliance with external requirements Provide IT governance Tabel 2: Mapping CobiT processen met COSO en Prince2.

Afsluiting

In dit hoofdstuk is een aantal frameworks nader toegelicht en is aangegeven in welke mate de frameworks invulling geven aan de governance elementen sturen, beheersen, toezicht houden en verantwoorden. De frameworks hebben een organisatiebreed, danwel meer organisatiespecifiek karakter hetgeen met name tot uiting komt in de diepgang van de frameworks. Het COSO framework identificeert de relaties tussen de ondernemingsrisico’s en het interne beheersingsysteem waarbij een relatie gelegd wordt tussen de doelstellingen van een organisatie, de controlecomponenten en de activiteiten waarvoor de interne controle benodigd is. Het CobiT framework kan worden gezien als de IT specifieke invulling van het COSO framework. Het Negenvlaksmodel is een hulpmiddel dat praktisch toepasbaar is bij het in kaart brengen van verantwoordelijkheden, rollen, processen en relaties tussen vraag en aanbod binnen organisaties en is dus meer kaderscheppend. Prince2 geeft invulling aan COSO en CobiT aan de hand van strikte richtlijnen voor de inrichting, het uitvoeren en het beheersen van IT-projecten, waarbij geen sprake is van een organisatiebreed karakter en niet de volledige IT-keten wordt betrokken.


13


Hoofdstuk 3 - Succes- en faalfactoren van IT-Projecten

3

Succes- en faalfactoren van IT-projecten

3.1

Inleiding

Om een doel te realiseren dat van groot belang is voor de IT binnen een organisatie, wordt een complexe, tijdelijke projectorganisatie opgezet en een reeks van bedrijfsvreemde activiteiten opgestart. Deze zogenaamde IT-projecten spelen zich vaak af in dynamische omgevingen, waar eisen en wensen met betrekking tot het op te leveren eindresultaat gedurende de loop van het project kunnen wijzigen. Een ITproject succesvol afronden vergt vaak een (zeer) forse inspanning. In de praktijk blijkt dat in veel gevallen het IT-project niet leidt niet tot het bereiken van het oorspronkelijke doel. Dit uit zich in uitloop in tijd en kosten of concessies met betrekking tot de kwaliteit van het eindresultaat. De vraag die nu rijst is: Wat zijn volgens de theorie succesfactoren voor IT-projecten en welke risico- en aandachtsgebieden (hierna gemakshalve verder aan te duiden als faalfactoren) worden in de praktijk onderscheiden? In de paragrafen 3.2 en 3.3 wordt hier nader op ingegaan.

3.2

Succesfactoren in de theorie

3.2.1 Succesfactoren In de literatuur is veel geschreven over kritische succesfactoren van IT-projecten. Door Doosje is, op basis van het bestuderen van wetenschappelijke literatuur, onderzoek uitgevoerd naar de factoren die van belang zijn voor het beheersen van processen en projecten. Mede op basis van de door Doosje uitgevoerd studie, is een drietal afgeleide succesfactoren onderkend, te weten [8] [9] [10] [33]: Planning en fasering; Projectorganisatie en besturing; Cultuur en gedrag. Uit de literatuur blijkt, dat besturen en beheersen van projecten niet mogelijk is zonder deze eerst in te richten, waardoor de factor ‘Planning en fasering’ belangrijk is. Verder geldt dat teneinde rollen in het project helder te krijgen en daardoor verantwoordelijkheden goed te kunnen beleggen, de factor ‘Projectorganisatie en besturing’ van belang is. Als laatste komt naar voren dat de factor ‘Cultuur en gedrag’ van belang is omdat de (informele) machtsstructuur, het leiderschapspatroon en de samenwerking, al dan niet versterkt door externe medewerkers, van invloed kunnen zijn op het al dan niet behalen van de uiteindelijke projectdoelen [8] [9] [10] [33].


14



3.2.2 Succesfactoren ten opzichte van de governance elementen In Tabel 3 is weergegeven hoe de in paragraaf 3.2.1 onderkende succesfactoren zich verhouden tot de in paragraaf 2.2 onderkende governance elementen.

Sturen Beheersen Toezicht houden Verantwoorden

Cultuur en gedrag

Projectorganisatie en besturing


Planning en fasering

Succesfactoren

Tabel 3: Succesfactoren ten opzichte van de governance elementen.

3.2.3 Succesfactoren ten opzichte van Prince2 In Tabel 4 is weergegeven hoe de in paragraaf 3.2.1 onderkende succesfactoren zich tot de Prince2 processen verhouden.

Starting Up a Project Initiating a Project Directing a project Controlling a Stage Managing Product Delivery Managing Stage Boundaries Planning Closing a Project


Cultuur en gedrag


Prince2 processen


Succesfactoren

15



Tabel 4: Succesfactoren ten opzichte van de Prince2 processen.

Opvallend in Tabel 3 en Tabel 4 is dat de succesfactor ‘Cultuur en gedrag’ niet te koppelen is aan één van de governance elementen danwel aan één van de processen binnen de projectmethodiek Prince2. Verderop in deze scriptie wordt op dit fenomeen nader ingegaan.

3.3

Faalfactoren in de praktijk

3.3.1 Faalfactoren De Standish Group voert om het jaar empirisch onderzoek uit naar het slagen en mislukken van ITprojecten. Het onderzoek wordt uitgevoerd onder IT-managers in de Verenigde Staten. Hierbij is onderzocht welke projecten geslaagd, minder geslaagd en mislukt zijn en welke oorzaken hieraan ten grondslag liggen. Uit het onderzoek van de Standish Group blijkt dat een projectmatige aanpak geen garantie is voor het succesvol afronden van een IT-project. De belangrijkste geconstateerde faalfactoren van IT-projecten zijn [27]: Gebrek aan gebruikersbetrokkenheid; Gebrek aan managementsponsorschap; Onduidelijkheid aangaande de gebruikerseisen; Gebrekkige en onduidelijke planning; Onrealistische verwachtingen; Gebrek aan korte projectmijlpalen; Onervarenheid van de projectmanager; Onduidelijkheid aangaande functies en verantwoordelijkheden; Onduidelijke doelstellingen van het IT-project; Ongemotiveerde projectleiding en projectteam. In het boek van Onna et al over de projectmethodiek Prince2 worden de volgende faalfactoren van projecten genoemd [1]: Onduidelijkheid over wie de opdrachtgever is; Geen goed projectplan wat betreft opzet en inhoud; Geen goede definiëring van het beoogde projectresultaat, onvoldoende aandacht voor het vastleggen van wat het project wel en wat het niet zal zijn; Slechte planning van ‘resources’ en activiteiten, een te optimistische planning waarin geen rekening is gehouden met mogelijke tegenvallers; Oorspronkelijke eisen en uitgangspunten veranderen tijdens het project; Gebrek aan beheersing van de voortgang, zodat ontsporingen pas worden opgemerkt als het reeds te laat is voor herstel; Onvoldoende meet- en beslispunten; Gebrek aan kwaliteitscontrole, wat resulteert in opgeleverde producten die niet voldoen aan de wensen en eisen van de gebruikers; Te beperkte tijdsbesteding, in verband met hogere prioriteit van het doorgaande werk.


16



Gesteld kan worden dat elk IT-project bepaalde inherente risico’s heeft die onder één van de bovenstaande faalfactoren kan worden geschaard. Een IT-project zonder projectrisico’s bestaat niet, het is de taak van het project management team om een stelsel van maatregelen te treffen om deze risico’s te beheersen. Een IT-project kent meestal een niet-routinematige aanpak, dit in tegenstelling tot de meeste lijnactiviteiten. Een dergelijke aanpak kan vooraf niet honderd procent zijn uitgewerkt. Tijdens een IT-project is de aanpak ervan nog te verfijnen, soms moet een aanpak zelfs drastisch worden herzien. In de praktijk is vaak sprake van tekortkomingen in de projectaanpak. Met dergelijke tekortkomingen - die als projectrisico’s worden aangeduid - dient adequaat te worden omgegaan.

3.3.2 Faalfactoren ten opzichte van de succesfactoren De vraag die nu rijst is of er een relatie bestaat tussen de in de praktijk onderkende faalfactoren en de succesfactoren die op basis van wetenschappelijk onderzoek zijn onderkend. In Tabel 5 is weergegeven hoe de in paragraaf 3.3.1 onderkende faalfactoren volgens respectievelijk de Standish Group en Onna et al zich verhouden tot de in paragraaf 3.2.1 onderkende succesfactoren.

Standish Group Gebrek aan gebruikersbetrokkenheid Gebrek aan managementsponsorschap Onduidelijkheid aangaande de gebruikerseisen Gebrekkige en onduidelijke planning Onrealistische verwachtingen Gebrek aan korte projectmijlpalen Onervarenheid van de projectmanager Onduidelijkheid aangaande functies en verantwoordelijkheden Onduidelijke doelstellingen van het IT-project Ongemotiveerde projectleiding en projectteam Onna et al Onduidelijkheid over wie de opdrachtgever is Geen goed projectplan wat betreft opzet en inhoud Geen goede definiëring van het beoogde projectresultaat, onvoldoende aandacht voor het vastleggen van wat het project wel en wat het niet zal zijn Slechte planning van ‘resources’ en activiteiten, een te optimistische planning waarin geen rekening is gehouden met mogelijke tegenvallers


Cultuur en gedrag


Faalfactoren


Succesfactoren

17



Oorspronkelijke eisen en uitgangspunten veranderen tijdens het project Gebrek aan beheersing van de voortgang, zodat ontsporingen pas worden opgemerkt als het reeds te laat is voor herstel Onvoldoende meet- en beslispunten Gebrek aan kwaliteitscontrole, wat resulteert in opgeleverde producten die niet voldoen aan de wensen en eisen van de gebruikers Te beperkte tijdsbesteding in verband met hogere prioriteit van het doorgaande werk Tabel 5: Faalfactoren volgens de Standish Group en Onna et al ten opzichte van de succesfactoren.

3.3.3 Faalfactoren ten opzichte van de Prince2 componenten In Tabel 6 is weergegeven hoe de faalfactoren volgens respectievelijk de Standish Group en Onna et al zich tot de Prince2 componenten verhouden. Bij het toekennen van faalfactoren aan één of meer van de componenten van Prince2, is de definitie van de componenten gehanteerd zoals deze zijn beschreven door Onna et al [1]. Per faalfactor is vervolgens gekeken, uitgaande van de definitie, aan welke van de componenten deze toe te wijzen is. In sommige gevallen is toewijzing niet mogelijk.

Standisch Group Gebrek aan gebruikersbetrokkenheid Gebrek aan managementsponsorschap Onduidelijkheid aangaande de gebruikerseisen Gebrekkige en onduidelijke planning Onrealistische verwachtingen Gebrek aan korte projectmijlpalen Onervarenheid van de projectmanager Onduidelijkheid aangaande functies en verantwoordelijkheden Onduidelijke doelstellingen van het IT-project Ongemotiveerde projectleiding en projectteam


Change Control

Configuration Management

Quality in a project environment

Management of Risk

Controls

Plans

Organisation

Faalfactoren

Business Case

Prince2 componenten

18



Onna et al Onduidelijkheid over wie de opdrachtgever is Geen goed projectplan wat betreft opzet en inhoud Geen goede definiëring van het beoogde projectresultaat, onvoldoende aandacht voor het vastleggen van wat het project wel en wat het niet zal zijn Slechte planning van ‘resources’ en activiteiten, een te optimistische planning waarin geen rekening is gehouden met mogelijke tegenvallers Oorspronkelijke eisen en uitgangspunten veranderen tijdens het project Gebrek aan beheersing van de voortgang, zodat ontsporingen pas worden opgemerkt als het reeds te laat is voor herstel Onvoldoende meet- en beslispunten Gebrek aan kwaliteitscontrole, wat resulteert in opgeleverde producten die niet voldoen aan de wensen en eisen van de gebruikers Te beperkte tijdsbesteding in verband met hogere prioriteit van het doorgaande werk Onduidelijkheid over wie de opdrachtgever is Tabel 6: Faalfactoren volgens de Standish Group en Onna et al ten opzichte van de Prince2 componenten.

Uit bovenstaande tabel blijkt dat er een ‘rode draad’ is waar te nemen waar het gaat om faalfactoren ten opzichte van de Prince2 componenten. Met name de componenten ‘Organisation’, ‘Plans’ en ‘Quality in a project environment’ zijn terugkerende aandachtsgebieden. In hoofdstuk 4 wordt ingegaan op deze ‘rode draad’ en op de relatie hiervan met het normatieve kader.

3.4

Faalfactoren: een praktijkcasus

In de vorige paragrafen is aangegeven wat, vanuit onderzoeken en de literatuur, de belangrijkste succesen faalfactoren van (IT-) projecten zijn. Aan de hand van een praktijkcasus zal worden geschetst in hoeverre de theorie aansluit op de waarnemingen in de praktijk. In de hiernavolgende casusbeschrijving staat een organisatie in de professionele dienstverlening centraal.

3.4.1 Inleiding De organisatie heeft in 2006 een start gemaakt met een groot IT-project, dat als doel had een veelheid aan gebruikte applicaties te vervangen door een (zelfbouw) maatwerkapplicatie. Daarnaast had het project als doel de op dat moment gehanteerde werkwijze te analyseren en daar waar nodig te herzien. Het betreft hier een ingrijpende verandering voor de organisatie. In 2008 is de organisatie geconfronteerd met het feit


19



dat het project na twee jaar geen tastbaar resultaat had opgeleverd. Kouters heeft, samen met de auteur van deze scriptie, een onderzoek uitgevoerd naar de oorzaken hiervoor. In de volgende paragraaf volgt een korte schets van de casus [19].

3.4.2 Casusbeschrijving Het IT-project is door de organisatie grotendeels uitbesteed aan een externe partij, de projectorganisatie werd derhalve voornamelijk bemand door externen. Aan de kant van de organisatie was een projectmanager benoemd die niet werd gehinderd door enige ervaring op dit vlak en daarnaast te vrij werd gelaten door de directie. Er was een stuurgroep benoemd die slechts in geval van problemen bij elkaar kwam, maar zowel de stuurgroep als de projectmanager signaleerde de problemen niet en liet zich overtuigen door de projectorganisatie (intern en extern) die zaken te optimistisch voorspiegelde. Er waren geen duidelijke afspraken gemaakt met de externe partij, waardoor de organisatie ten onrechte de overtuiging had dat zij een resultaatverplichting was aangegaan met de externe partij. Het contract bleek niet meer dan een inspanningsverplichting. Een plan van aanpak waarin stond wat de doelstelling en de scope van het programma was ontbrak. De aansluiting met de business strategie was door het ontbreken van een plan van aanpak niet duidelijk. Of ‘iets’ af was, was niet eenduidig vast te stellen aangezien het ‘iets’ niet was gespecificeerd, er waren geen acceptatiecriteria vastgelegd. Door het ontbreken van een breed gedragen plan van aanpak waren er verschillende interpretaties van waar het programma over ging. Dit varieerde van een IT systeemvervanging tot een volledige kanteling van de organisatie. Vanuit de klant werd het programma te veel ‘getrokken’ door de IT afdeling. Zij waren voortdurend bezig de externe partij te vertellen wat in hun ogen het gewenste procesverloop was. De functionarissen uit de ‘business’ die wel betrokken waren in het project spraken niet de (IT) taal van de externe partij.

3.4.3 Faalfactoren In bovenstaande casusbeschrijving wordt in kort bestek de achtergrond geschetst waarbinnen het ITproject uitgevoerd moest worden. Het moge duidelijk zijn dat er allerminst sprake is van een stabiele en goed georganiseerde projectomgeving. Daarnaast valt op dat niet alle oorzaken alleen maar met IT te maken hebben, maar een breder karakter hebben. Uit het, door Kouters en de auteur van deze scriptie, uitgevoerde onderzoek is een uitgebreide analyse uitgevoerd op basis waarvan oorzaken zijn benoemd welke hebben gezorgd voor de situatie waarin de organisatie zich uiteindelijk, na twee jaar, bevond. Hieronder volgt een overzicht van oorzaken voor het ‘mislukken’ van het IT-project in de onderhavige casus. Deze oorzaken hebben niet alleen met IT te maken, maar hebben een veel breder karakter waarbij de volledige IT-keten binnen de organisatie geraakt wordt. De genoemde oorzaken onderschrijven de door de Standish Group en Onna et al onderkende oorzaken, zoals beschreven in paragraaf 3.3:

Er was onvoldoende overeenstemming over het doel van het project; Een breed gedragen plan van aanpak waarin met voldoende diepgang staat wat er moet gebeuren ontbrak; Opdrachtgeverschap werd uit handen gegeven zodra het project begon; Projectleiders bleken vaak projectmedewerkers te zijn; Er zaten te veel externen op cruciale posities in het project; Kwaliteitsborging vanuit de ‘business’ vond onvoldoende plaats;


20


3.5


Ontwikkelaars zijn gaan bouwen op basis van documenten die niet overeenkwamen met de wensen van de ‘business’; Stuurgroepen stuurden niet omdat zij het gereedschap daarvoor ontbeerden; Werkgroepen werkten niet omdat ze te veel overlegden en te weinig gestuurd werden; De onderbouwing van kwantitatieve inschattingen was zwak; Communicatie binnen het project was onvoldoende; Taken, bevoegdheden en verantwoordelijkheden binnen het project waren slecht belegd; Projectmedewerkers hadden te weinig tijd: ‘het moest er even bij’; Er was te veel optimisme over de voortgang waardoor te weinig ‘slack’ was ingebouwd; Risico analyses van ‘key bedrijfsprocessen’ waren onvoldoende uitgevoerd; Het gewenste verloop van de bedrijfsprocessen was onvoldoende vastgelegd; daarbij was onvoldoende aandacht voor controlemaatregelen; De ‘doe cultuur’ om het project tot een goed einde te brengen ontbrak; Kennis en ervaring waren onvoldoende aanwezig in de organisatie om IT-projecten goed uit te kunnen voeren en te kunnen managen; Het project werd verstoord doordat (vooral) de leiding met aanvullende wensen kwam, zonder dat de consequenties goed werden doorzien; Er vond geen continue evaluatie plaats van de gedefinieerde businesscase.

Afsluiting

Uit de casusbeschrijving en de onderkende faalfactoren blijkt dat de oorzaken voor het ‘mislukken’ van IT-projecten de door de Standish Group en Onna at al onderkende faalfactoren onderschrijven. Daarnaast blijkt dat de het ‘mislukken’ vaak niet alleen maar met IT te maken hebben, maar een veel breder karakter heeft. Om IT-projecten met succes uit te kunnen voeren is het van belang de gehele IT-keten, van businessstrategie tot operationele (IT-) processen, te beheersen.


21


Hoofdstuk 4 - Normatief kader Governance IT-Projecten

4

Normatief kader Governance IT-projecten

4.1

Inleiding

Zoals gesteld in paragraaf 1.2, luidt de centrale vraag van deze scriptie: “Hoe kan een normatief kader voor het opzetten, uitvoeren en monitoren van IT-projecten er vanuit het perspectief van het management uit zien? Welke elementen dienen hier minimaal in te zitten en wat is de rol van de IT-auditor?”. In dit hoofdstuk wordt antwoord gegeven op de eerste twee vragen van de centrale vraag. De derde vraag met betrekking tot de rol van de IT-auditor, wordt in hoofdstuk 5 beantwoord. Op basis van de in hoofdstuk 2 beschreven governance frameworks en de in hoofdstuk 3 beschreven succesen faalfactoren van IT-projecten, wordt onderzocht of kan worden gekomen tot een normatief kader. Een kader op basis waarvan organisaties kunnen komen tot een situatie waarbij voldoende waarborgen zijn getroffen voor het welslagen van IT-projecten. Daarnaast wordt onderzocht welke elementen dit normatieve kader dan minimaal moet bevatten.

4.2

De ‘rode draad’

In hoofdstuk 3 is een aantal vergelijkingen gemaakt tussen de succesen faalfactoren enerzijds en de governance elementen en Prince2- processen en componenten anderzijds. In deze paragraaf wordt onderzocht of er een ‘rode draad’ is te onderkennen in de vergelijkingen en zo ja, wat deze ‘rode draad’ dan is.

4.2.1 Een analyse In paragraaf 3.2.2 zijn als eerste de drie onderkende succesfactoren ten opzichte van de vier onderkende governance elementen weergegeven. Uit deze weergave blijkt dat de succesfactor ‘Planning en fasering’ in verband is te brengen met de governance elementen ‘Sturen’ en ‘Beheersen’. De succesfactor ‘Projectorganisatie en besturing’ is in verband te brengen met de governance elementen ‘Sturen’, ‘Toezicht houden’ en ‘Verantwoorden’. De succesfactor ‘Cultuur en gedrag’, zo blijkt uit de tabel, is niet in verband te brengen met één van de governance elementen. De verklaring hiervoor is dat de governance elementen ‘Sturen’, ‘Beheersen’, ‘Toezicht houden’ en ‘Verantwoorden’ samenhangen met de fasen uit een management cyclus, zoals bijvoorbeeld de ‘Plan-Do-Check-Act’ cyclus van Deming. Als tweede zijn de drie succesfactoren ten opzichte van de acht Prince2 processen weergegeven in paragraaf 3.2.3. Uit de tabel blijkt dat, evenals bij de governance elementen, de Prince2 processen in verband zijn te brengen met de succesfactoren ‘Planning en fasering’ en ‘Projectorganisatie en besturing’ en dat de succesfactor ‘Cultuur en gedrag’ ook in deze vergelijking onderbelicht blijft.


22



Vervolgens is in paragraaf 3.3.2 een vergelijking gemaakt tussen de succesfactoren enerzijds en de faalfactoren anderzijds. Logischerwijs moeten beide met elkaar samenhangen maar is dit in de praktijk ook daadwerkelijk zo. Uit de tabel blijkt inderdaad dat de succesfactoren en de faalfactoren een duidelijke relatie hebben. Waar in de vergelijking van de succesfactoren met de governance elementen en de Prince2 processen de succesfactor ‘Cultuur en gedrag’ duidelijk onbelicht bleef, blijkt dat in de praktijk zeer zeker faalfactoren bestaan die aan deze essentiële factor voor het welslagen van IT-projecten zijn te relateren en zich kunnen voordoen indien aan ‘Cultuur en gedrag’ onvoldoende aandacht wordt besteed. Als laatste vergelijking zijn in paragraaf 3.3.3 de faalfactoren ten opzichte van de acht Prince2 componenten weergegeven. Uit de tabel blijkt dat veel van de door de Standisch Group en Onna et al onderkende faalfactoren zijn toe te kennen aan de volgende componenten: Organisation Plans Quality in a project environment De component ‘Organisation’ is te relateren aan de succesfactor ‘Projectorganisatie en besturing’. De component ‘Plans’ is te relateren aan de succesfactor ‘Planning en fasering’. De component ‘Quality in a project environment’ heeft betrekking op alle succesfactoren en is dientengevolge niet slechts aan één succesfactor toe te wijzen. Ook hier blijkt duidelijk dat voor de succesfactor ‘Cultuur en gedrag’ onvoldoende aandacht is vanuit de projectmethodiek Prince2.

4.2.2 Conclusie Concluderend kan worden gesteld dat er inderdaad een ‘rode draad’ is te onderkennen. Voor de succesfactoren ‘Planning en fasering’ en ‘Projectorganisatie en besturing’ worden vanuit Prince2 handvatten aangereikt om ervoor te zorgen dat de faalfactoren die zich kunnen voordoen wanneer aan deze twee succesfactoren onvoldoende aandacht wordt besteed, niet zullen optreden. Hierdoor neemt de kans op het slagen van het IT-project toe. Voor de succesfactor ‘Cultuur en gedrag’ is vanuit Prince2 echter geen of onvoldoende handreiking om ervoor te zorgen dat de faalfactoren die samenhangen met deze succesfactor zich in de praktijk niet zullen voordoen.

4.3

Normatief kader

Nu in kaart is gebracht wat de ‘rode draad’ is, kan voor de van belang zijnde factoren, te weten de succesfactoren ‘Planning en fasering’, ‘Projectorganisatie en besturing’ en ‘Cultuur en gedrag’ worden gekeken aan welke aspecten aandacht dient te worden besteed.

4.3.1 ‘Planning en fasering’ en ‘Projectorganisatie en besturing’ Vanuit Prince2 worden, zoals gesteld, handvatten aangereikt om de risico’s die invloed hebben op het al dan niet succesvol zijn van de succesfactoren ‘Planning en fasering’ en ‘Projectorganisatie en besturing’,


23



te kunnen beheersen. In Tabel 7 is een relatie gelegd tussen de acht processen en de acht componenten van Prince2.

DP2

IP2 IP4 DP2

Change Control

Directing a project (DP)

IP2

SU4

Configuration Management

IP3

SU6

Quality in a project environment

Initiating a Project (IP)

SU1 SU2 SU3 IP1 IP6

Management of Risk

SU4

Controls

Organisation

Starting Up a Project (SU)

Prince2 processen

Plans

Business Case

Prince2 componenten

IP1

IP1

SU4 SU5 IP1

Controlling a Stage (CS) CS1 CS1 Managing Product Delivery (MP) MP1 Managing Stage Boundaries (SB) SB1 SB1 Planning (PL) PL PL2 Closing a Project (CP) CP1 Tabel 7: Normatief kader op basis van Prince2 processen en Prince2 componenten.

In matrixvorm is weergegeven welke acties binnen de processen minimaal dienen te worden uitgevoerd met betrekking tot de samenstellende componenten. Gedurende het proces ‘Starting Up a project (SU)’ dienen ten aanzien van de component ‘Organisation’ minimaal de activiteiten ‘SU1’, ‘SU2’ en ‘SU3’ uitgevoerd te worden. Deze activiteiten zijn afkomstig uit Prince2 alwaar ook de specifieke inhoud van de activiteiten staat beschreven. Uit Tabel 7 blijkt dat, evenals uit de vergelijking van de faalfactoren ten opzichte van de acht Prince2 componenten, de componenten ‘Organisation’, ‘Plans’ en ‘Quality in a project environment’ van belang zijn.

4.3.2 ‘Cultuur en gedrag’ Zoals gesteld wordt de succesfactor ‘Cultuur en gedrag’ onderbelicht vanuit Prince2. Toch is een aantal faalfactoren van IT-projecten te relateren aan deze succesfactor, waardoor het inzicht ontstaat dat vanuit de organisatie maatregelen moeten worden getroffen teneinde de faalfactoren in de praktijk niet te laten ontstaan. Maar wat is nu eigenlijk het probleem? Het probleem is dat in de loop der jaren is gebleken dat veel van hetgeen misgaat in (project)organisaties, wordt veroorzaakt door verschillen tussen de


24



doelstellingen van het individu en die van de (project)organisatie, hetgeen tot voor de (project)organisatie ongewenst gedrag leidt. Bij het implementeren van een nieuw systeem speelt mee dat mensen vaak niet willen veranderen. Acceptatie is hierbij een belangrijke factor. Organisaties dienen rekening te houden met weerstand tegen verandering en hiertoe adequate maatregelen te treffen. De theorie uit het vakgebied Management Control zou op de gewenste, adequate wijze ondersteuning kunnen bieden aan het vraagstuk rondom weerstand tegen en acceptatie van verandering en daarmee samenhangend derhalve de succesfactor ‘Cultuur en gedrag’. Management Control wordt in de literatuur als volgt gedefinieerd [11]:

“Het proces met behulp waarvan managers andere leden van de organisatie beïnvloeden teneinde de strategieën van de organisatie uit te voeren”. Figuur 9: Definitie Management Control.

Blijkens de definitie heeft Management Control betrekking op de relatie tussen de manager en een ondergeschikte en bestaat uit een drietal kenmerkende activiteiten [11]: Communiceren: Teneinde te bewerkstellingen dat ondergeschikten effectief kunnen functioneren dienen zij op de hoogte te zijn van de organisatiedoeleinden en van hetgeen van hen verwacht wordt in het licht van de realisatie van deze doeleinden. Dit communicatieproces resulteert uiteindelijk in prestatieafspraken tussen de manager en de ondergeschikte. Motiveren: Communicatie is niet voldoende, ondergeschikten dienen te worden gemotiveerd teneinde de organisatiedoeleinden te bereiken. Evalueren: Het evalueren van de prestaties van ondergeschikten. Teneinde resultaten te kunnen evalueren en ondergeschikten te kunnen motiveren, is prestatiemeting noodzakelijk. Evaluatie van de resultaten betreft het vergelijken van de realisatie met de gemaakte prestatieafspraken. Een Management Control System is, naast de drie kenmerkende activiteiten, tevens gericht is op aspecten als ‘cultuur’, ‘structuur ‘en ‘personeelsmanagement’. De samenhang tussen deze aspecten kan als volgt worden weergegeven [12] [34]:


25



Management Control Systeem

Management controls

Strategie

Organisatie structuur

Personeels management

Prestaties

Cultuur

Figuur 10: Management Control System.

De in Figuur 10 weergegeven aspecten ‘organisatiestructuur’, ‘cultuur’ en ‘personeelsmanagement’ zijn in verband te brengen met één van de acht samenstellende controlcomponenten van het COSO framework, te weten de component ‘Control Environment’. Zowel in het Management Control System als in het COSO framework neemt gedragsbeïnvloeding binnen de ‘Control Environment’ een belangrijke plaats in. Binnen COSO is gedragsbeïnvloeding noodzakelijk om vanuit een BIV-standpunt tot een adequate beheersing van activiteiten te komen. Vanuit Management Control is het een belangrijk middel voor managers om ondergeschikten te laten doen wat van hen verwacht wordt. De voordelen van een Management Control System zijn te vertalen als de toename van de waarschijnlijkheid dat de doelstellingen van een organisatie zullen worden behaald in vergelijking met wat zou behaald worden als er geen Management Control zou zijn. Dit voordeel kan worden omschreven als ‘control tightness’. Om een hogere ‘control tightness’ door middel van gedragsbeïnvloeding te realiseren en daarmee een hogere kans op het behalen van de doelstellingen te verkrijgen, zijn ‘code of conduct’, ‘gedragsrichtlijnen’, ‘the tone is set at the top’, ‘handboek soldaat’ en ‘afspraak is afspraak’ bekende begrippen en uitspraken. Bij deze begrippen en uitspraken dient aan aantal elementen voldaan te worden: Congruentie gewenste resultaten met doelstellingen: de definitie van gewenste resultaten dienen congruent zijn met de doelstellingen van de organisatie, de doelstellingen dienen specifiek te zijn, er moet feedback gegeven worden en er moet gecommuniceerd worden; Meten van prestaties: het meten van prestaties dient te gebeuren op een precieze, objectieve, tijdige en begrijpelijke manier; Verband tussen resultaten en belonen: er dient een duidelijk verband te bestaan tussen behaalde resultaten en beloning danwel straf. De beheersing van het organisatiegedrag vinden wij in het vakgebied Management Control bijvoorbeeld terug in de ‘levers of control’ van Simons. In de theorie van de ‘levers of control’ worden, ten behoeve van het beheersen, een viertal controlsystemen gebruikt. De controlsystemen zijn gericht op het creëren van evenwicht in een drietal spanningsvelden [13] [34]:


26



Waardecreatie: het spanningsveld tussen onbeperkte mogelijkheden en beperkte attentie; Strategievorming: het spanningsveld als gevolg van het zich gelijktijdig voordoen van de zogeheten ‘bottom up’-benadering en de ‘top down’-benadering; Menselijk gedrag: het spanningsveld tussen het gezamenlijke en eigen belang van individuen en groepen, tussen gewenst en feitelijk gedrag. Simons beschrijft dit spanningsveld als de essentie van Management Control.

Om dit evenwicht te bereiken, waarbij het spanningsveld ‘Menselijk gedrag’ centraal staat, wordt een viertal kernaspecten door controlsystemen bewaakt [13]: Beliefs systems: kernwaarden van de organisatie; Boundary systems: te vermijden risico’s; Interactive control systems: strategische onzekerheden; Diagnostic control systems: kritieke succesfactoren (met name ‘Cultuur en gedrag’). De vier controlsystemen creëren tegengestelde krachten. De ‘beliefs systems’ en de ‘interactive control systems’ zijn de positieve krachten (do’s) en beogen de creativiteit en het innovatief vermogen van medewerkers te verhogen. De ‘boundary systems’ en de ‘diagnostic control systems’ daarentegen zijn de negatieve krachten (dont’s). Zij beperken het zoeken naar mogelijkheden en geven richting aan de schaars beschikbare managementaandacht. In het kader van de beheersing van organisatiegedrag en projectmanagement zijn met name de eerste twee kernaspecten van belang, de kernwaarden van de organisatie en de te vermijden risico’s. Deze aspecten moeten beheerst worden door de manager om te waarborgen dat de individuele doelstellingen van medewerkers niet af gaan wijken van de doelstellingen van de organisatie. Enerzijds dient daarvoor het organisatiegedrag zodanig beïnvloed te worden, dat individuele participanten handelen naar de wensen van de organisatie. Anderzijds dient de organisatie duidelijk te maken wat onder gewenst handelen wordt verstaan.

4.4

Afsluiting

In de paragrafen 4.3.1 en 4.3.2 is uitgebreid stilgestaan bij het begrip ‘beheersing’ in relatie met de succesfactoren ‘Planning en fasering’, ‘Projectorganisatie en besturing’ en ‘Cultuur en gedrag’. Vanuit de projectmethodiek Prince2 worden handreikingen gedaan ten einde binnen de organisatie en ten aanzien van de succesfactoren ‘Planning en fasering’ en ‘Projectorganisatie en besturing’ voldoende maatregelen te treffen om ervoor te zorgen dat het risico op het optreden van faalfactoren wordt gemitigeerd. Ten aanzien van de succesfactor ‘Cultuur en gedrag’ worden echter geen handreikingen gedaan om de faalfactoren die bij deze succesfactor behoren, in voldoende mate te kunnen beheersen. Vanuit de literatuur zijn het Management Control System en de ‘levers of control’-theorie van Simons zeer bruikbaar waar het gaat om de beïnvloeding van organisatiegedrag en bieden handreikingen voor het management om ten aanzien van organisatiegedrag de juiste maatregelen te kunnen treffen. In hoofdstuk 5 wordt onderzocht welke rol de IT-auditor hierbij kan spelen.


27


Hoofdstuk 5 - Rol van de IT-auditor binnen IT-Projecten

5

Rol van de IT-auditor binnen IT-projecten

5.1

Inleiding

In dit hoofdstuk wordt ingegaan op de vraag of de IT-auditor een rol kan vervullen ten aanzien van ITprojecten en welke rol dit dan zou moeten zijn.

5.2

Welke rol dient de IT-auditor te spelen

Wat is nu eigenlijk een IT-auditor? NOREA stelt dat een IT-auditor de informatietechnologie in een organisatie beoordeelt. Een gekwalificeerde IT-auditor geeft onpartijdige oordelen en adviezen over de kwaliteitsaspecten van IT. Een bredere definitie is dat de IT-auditor betrokken is bij het beoordelen van en adviseren over de inzet van IT binnen organisaties. Een verbreding van het begrip auditing in de richting van advies is hierbij duidelijk te herkennen. Gesteld kan worden dat de IT-auditor zich bezighoudt met softwarepakketten, projecten, beheersing, beveiliging en, vanuit historisch perspectief, de ondersteuning van de accountant bij de controle van de jaarrekening [20]. Volgens de literatuur kan de IT-auditor gedurende IT-projecten optreden vanuit een attestfunctie of vanuit een adviserende functie [4]: Attestfunctie: De attestfunctie van de IT-auditor houdt in het geven van een onafhankelijk en onpartijdig oordeel over de mate waarin één of meer (bestaande dan wel toekomstige) objecten uit de IT voldoen aan de in de opdracht overeengekomen kwaliteitsaspecten. Daarnaast wordt van de IT-auditor verwacht dat hij niet alleen een oordeel weet te geven omtrent IT-objecten, maar ook in staat is om, mede op basis van zijn werkzaamheden, adviezen te geven ter opheffing van geconstateerde gebreken, zowel gevraagd als ongevraagd (natuurlijke adviesfunctie); Adviesfunctie: De adviesfunctie van de IT-auditor houdt in: het doen van aanbevelingen respectievelijk het geven van raad op het deskundigheidsgebied van de IT-auditor (dat is ontleend aan zijn kennis en ervaring op het gebied van IT). Het essentiële verschil ten opzichte van de attestfunctie zit in het doel van de adviesfunctie, te weten het doen van voorstellen voor het creëren van nieuwe (toekomstige) situaties. Daarnaast verwacht het management dat de IT-auditor zich in deze functie vereenzelvigt met zijn advies en het welslagen van zijn advies in de praktijk. Donkers stelt dat in de praktijk de IT-auditor, ten aanzien van de activiteiten bij de uitvoering van ITprojecten, vooral wordt betrokken om producten te beoordelen vanuit zijn attestfunctie. Niet enkel op aspecten van interne controle, de oorspronkelijke expertise, maar ook op formele aspecten zoals bijvoorbeeld de structuur van de projectorganisatie [18]. Met de verandering van de complexiteit en de organisatorische impact van IT-projecten is ook het aantal mogelijke rollen van een IT-auditor binnen projecten uitgebreid. In het verleden bood een audit op een project het management voldoende zekerheid voor het welslagen van een project. Tegenwoordig


28


Hoofdstuk 5 - Rol van de IT-auditor binnen IT-Projecten

onderkennen eindverantwoordelijken of toezichthouders meer en meer behoefte aan een continue betrokkenheid van IT-auditors gedurende het gehele IT-project. Niet alleen een beoordeling achteraf, maar ook een actieve betrokkenheid van de IT-auditor tijdens het IT-project als bewaker van de kwaliteit wordt gangbaarder. Hiermee wordt tegemoetgekomen aan de Prince2 component ‘Quality in a project environment’ [18]. Door een ‘Quality Assurance (QA)’ rol te vervullen en meer als kwaliteitsbewaker dan als controleur op te treden bij de uitvoering van IT-projecten, heeft de IT-auditor de mogelijkheid om bij het ontstaan van eventuele knelpunten ten aanzien van de succesfactoren ‘Planning en fasering’ en ‘Projectorganisatie en besturing’, deze direct te signaleren, daarover te rapporteren aan verantwoordelijken en toezichthouders en daar waar relevant verbetervoorstellen te doen, waarbij onderscheid gemaakt kan worden in: Audit van het product: voldoet het resultaat van het project, bijvoorbeeld het maatwerksysteem, inhoudelijk aan de vooraf gestelde (kwaliteits)eisen; Audit van het proces: voldoet het proces om te komen tot het resultaat van het project aan de daaraan te stellen eisen, ofwel is er sprake van adequaat projectmanagement. Ten aanzien van de succesfactor ‘Cultuur en gedrag’ is maar zeer de vraag of een IT-auditor de aangewezen persoon is een constructieve bijdrage te kunnen leveren aan deze succesfactor. Waar het gaat om gedrag van individuen, zowel zelfstandig als in groepen, wordt het terrein betreden van de gedragswetenschappers zoals sociologen, psychologen, en sociaal psychologen (andragogen). De ITauditor dient zich idealiter niet op dit terrein te begeven en zich met name te richten op zijn kerntaken ‘audit van het product’ en ‘audit van het proces’.

5.3

Afsluiting

De betrokkenheid van de IT-auditor bij IT-projecten heeft een andere dimensie gekregen door de toenemende complexiteit van IT-projecten. Eindverantwoordelijken of toezichthouders onderkennen meer en meer behoefte aan een continue betrokkenheid van IT-auditors gedurende het gehele traject. De oorspronkelijke ‘ad hoc’ betrokkenheid door middel van het achteraf beoordelen van producten is meer en meer geëvolueerd naar actieve- en proactieve betrokkenheid. Deze actieve- en proactieve betrokkenheid uit zicht in de vorm van het optreden van de IT-auditor als kwaliteitsbewaker gedurende het gehele project. Hierbij dient onderscheid gemaakt te worden tussen enerzijds de succesfactoren ‘Planning en fasering’ en ‘Projectorganisatie en besturing’, waarbij de IT-auditor de rol van kwaliteitsbewaker kan vervullen ten aanzien van zowel het product als het proces, en anderzijds de succesfactor ‘Cultuur en gedrag’ waarbij de IT-auditor vanuit zijn vakgebied een geringere bijdrage kan leveren en dit dient over te laten aan gedragswetenschappers zoals sociologen, psychologen, en sociaal psychologen (andragogen).


29


6

Conclusie en persoonlijke reflectie

6.1

Inleiding

Hoofdstuk 6 - Conclusie en persoonlijke reflectie

In dit hoofdstuk wordt op basis van de afsluitingen in de hoofdstukken 2 tot en met 5 een conclusie getrokken en wordt middels een persoonlijke reflectie een overweging gemaakt aangaande het onderwerp van de scriptie.

6.2

Conclusie

In hoofdstuk 2 is een aantal frameworks, te weten COSO, CobiT, het Negenvlaksmodel en Prince2 nader toegelicht en is aangegeven in welke mate deze frameworks invulling geven aan de governance elementen ‘sturen’, ‘beheersen’, ‘toezicht houden’ en ‘verantwoorden’. De beschreven frameworks hebben een organisatiebreed, danwel meer organisatiespecifiek karakter hetgeen met name tot uiting komt in de diepgang van de frameworks. Het COSO framework identificeert de relaties tussen de ondernemingsrisico’s en het interne beheersingsysteem waarbij een relatie gelegd wordt tussen de doelstellingen van een organisatie, de controlecomponenten en de activiteiten waarvoor de interne controle benodigd is. Het CobiT framework kan worden gezien als de IT specifieke invulling van het COSO framework. Het Negenvlaksmodel is een hulpmiddel dat praktisch toepasbaar is bij het in kaart brengen van verantwoordelijkheden, rollen, processen en relaties tussen vraag en aanbod binnen organisaties en is dus meer kaderscheppend. Prince2 geeft invulling aan COSO en CobiT aan de hand van strikte richtlijnen voor de inrichting, het uitvoeren en het beheersen van IT-projecten, waarbij geen sprake is van een organisatiebreed karakter en niet de volledige IT-keten, van businessstrategie tot operationele (IT-) processen, wordt betrokken. Uit de casusbeschrijving en de onderkende faalfactoren in hoofdstuk 3, blijkt dat de oorzaken voor het ‘mislukken’ van IT-projecten de door de Standish Group en Onna at al onderkende faalfactoren onderschrijven. Daarnaast blijkt dat het ‘mislukken’ vaak niet alleen maar met IT te maken heeft, maar een veel breder karakter heeft. Om IT-projecten met succes uit te kunnen voeren is het van belang de gehele IT-keten te beheersen. In hoofdstuk 4 is uitgebreid stilgestaan bij het begrip ‘beheersing’ in relatie met de succesfactoren ‘Planning en fasering’, ‘Projectorganisatie en besturing’ en ‘Cultuur en gedrag’. Vanuit de projectmethodiek Prince2 worden handreikingen gedaan ten einde binnen de organisatie en ten aanzien van de succesfactoren ‘Planning en fasering’ en ‘Projectorganisatie en besturing’ voldoende maatregelen te treffen om ervoor te zorgen dat het risico op het optreden van faalfactoren wordt gemitigeerd. Ten aanzien van de succesfactor ‘Cultuur en gedrag’ worden echter geen handreikingen gedaan om de faalfactoren die bij deze succesfactor behoren, in voldoende mate te kunnen beheersen. Vanuit de literatuur is het Management Control System en de ‘levers of control’ theorie van Simons zeer bruikbaar waar het gaat om de beïnvloeding van organisatiegedrag en bieden handreikingen voor het management om ten aanzien van organisatiegedrag de juiste maatregelen te kunnen treffen. De betrokkenheid van de IT-auditor bij IT-projecten, zoals beschreven in hoofdstuk 5, heeft een andere dimensie gekregen door de toenemende complexiteit van IT-projecten. Eindverantwoordelijken of


30


Hoofdstuk 6 - Conclusie en persoonlijke reflectie

toezichthouders onderkennen meer en meer behoefte aan een continue betrokkenheid van IT-auditors gedurende het gehele traject. De oorspronkelijke ‘ad hoc’ betrokkenheid door middel van het achteraf beoordelen van producten is meer en meer geëvolueerd naar actieve- en proactieve betrokkenheid. Deze actieve- en proactieve betrokkenheid uit zich in de vorm van het optreden van de IT-auditor als kwaliteitsbewaker gedurende het gehele project. Hierbij dient onderscheid gemaakt te worden tussen enerzijds de succesfactoren ‘Planning en fasering’ en ‘Projectorganisatie en besturing’, waarbij de ITauditor de rol van kwaliteitsbewaker kan vervullen ten aanzien van zowel het product als het proces, en anderzijds de succesfactor ‘Cultuur en gedrag’ waarbij de IT-auditor vanuit zijn vakgebied een geringere bijdrage kan leveren en dit dient over te laten aan gedragswetenschappers zoals sociologen, psychologen, en sociaal psychologen (andragogen). Ten aanzien van de centrale vraag van deze scriptie kan geconcludeerd worden dat, vanuit het management van een organisatie bezien, minimaal aandacht moet zijn voor de succesfactoren ‘Planning en fasering’, ‘Projectorganisatie en besturing’ en ‘Cultuur en gedrag’. Hiertoe kan het normatieve kader, zoals opgesteld in hoofdstuk 4, worden gebruikt, omdat deze ingaat op de aspecten waaraan aandacht dient worden besteed ten einde de onderkende faalfactoren van IT-projecten niet te laten optreden. Maatregelen dienen te worden getroffen ten aanzien van de Prince2 componenten ‘Organisation’, ‘Plans’ en ‘Quality in a project environment’. Daarnaast geeft het normatieve kader aan hoe kan worden omgegaan met de succesfactor ‘Cultuur en gedrag’ en hoe kan worden bewerkstelligd hoe deze factor positief kan bijdragen aan het welslagen van IT-projecten.

6.3

Persoonlijke reflectie

Voorafgaand aan het schrijven dacht ik precies in mijn hoofd te hebben wat ik wilde en ook zou moeten schrijven. Tijdens het schrijven van deze scriptie bleek al snel dat vooraf het verhaal in je hoofd hebben en dan vervolgens concrete bewoordingen aan het maagdelijk witte papier toevertrouwen geen sinecure is. Ten aanzien van het resultaat kan gesteld worden dat deze middels voortschrijdend inzicht tot stand is gekomen, waarbij ik het gevoel heb dat mijn kennisniveau ten aanzien van governance en IT-projecten is toegenomen. Met name de samenhang tussen COSO, CobiT, het Negenvlaksmodel, Prince2 en de toepassing hiervan in de praktijk heeft grote toegevoegde waarde. Voor wat betreft de inhoud en het onderwerp van deze scriptie, waarbij in hoofdstuk 4 een kader is gesteld waaraan door het management van een organisatie, danwel management van een project aandacht besteed dient te worden, is gebleken dat, naast de organisatorische en planmatige aspecten, met name cultuur- en gedragsaspecten een grote rol spelen bij het al dan niet slagen van projecten. Voorafgaand aan het schrijven van de scriptie had ik wel dit vermoeden, maar door de verschillende aspecten eens nader te onderzoeken is dit vermoeden meer dan bevestigd.


31


Literatuurlijst

Literatuurlijst Boeken 1 Onna, Koning, De Kleine Prince2, Academic Service 2007. 2 Brand, Boonen, IT Governance based on CobiT 4.0 - A Management Guide, Van Haren 3 4 5 6 7 8 9 10 11 12 13

Publishing januari 2007. Abcouwer, Gels, Truijens, Informatie management en beleid, Academic Service 2006. Praat, Suerink, Inleiding EDP-auditing, Ten Hagen & Stam uitgevers november 2004. Christiaanse, Praat, Inrichten en beheersen van organisaties, ThiemeMeulenhoff 2005. Grembergen, Haes, IT Governance mechanismen, Kluwer 2004. Renz, Project Governance: Implementing Corporate Governance and Business Ethics in Nonprofit Organizations, Physica-Verl. 2007. Starreveld, Mare, Joëls, Bestuurlijk Informatieverzorging deel 2B - Toepassingen Typologie van bedrijfshuishoudingen, Samsom Bedrijfsinformatie 1997. Beek, Jager, Hoofdlijnen informatiekunde, Wolters-Noordhoff 1993. Horn, Psychologische aspecten van de organisatie, Samsom Bedrijfsinformatie 1994. Lewy, Management Control Regained, Kluwer bedrijfswetenschappen 1992. Anthony, Govindarajan, Management Control Systems, 1995. Simons, Levers of control, How managers use innovative control systems to drive strategic renewal, Harvard Business School Press, 1995.

Artikelen 14 IT Governance Institute, CobiT 4.1 Exerpt - Executive Summary Framework, IT Governance 15 16

17 18 19 20 21

Institute 2007. IT Governance Institute, CobiT Mapping - Overview of international IT Guidance, 2nd Edition, IT Governance Institute 2007. Committee of Sponsoring Organizations of the Treadway Commission, Enterprise Risk Management - Integrated Framework - Management Samenvatting, Committee of Sponsoring Organizations of the Treadway Commission 2004. Donkers et al, IT Governance - Een verkenning, De Kennisgroep IT Governance NOREA juni 2004. Donkers, Oudega, Van projectaudit tot projectcontrol, Compact 2002. Kouters, Beheersing volledige IT keten essentieel, Informatie 2008. Fijneman, IT-auditor: adviseur of controleur?, Automatiseringsgids webeditie (bewerking oratie) 2005. Bommel, Peek, Winterink, De betekenis van IT-auditing voor risicobeheersing en ITgovernance, Maandblad voor Accountancy en Bedrijfseconomie (MAB) 2008.

Internet sites 22 www.coso.org 23 www.isaca.org 24 www.itgi.org 25 www.itgovernance.com 26 www.norea.nl


II


27 28 29 30

Literatuurlijst

www.standishgroup.com www.rikmaes.nl www.twynstragudde.nl www.gartner.com

Overig 31 Donkers, Project Governance en Risk Management binnen projecten, NOREA Presentatie 32 33 34

2005. The Institute of Internal Auditors, Enterprise Risk Management - Integrated Framework, Presentatie Institute of Internal Auditors 2004. Doosje, Beheersing van projectrisico’s - Succesfactoren in projectmanagement, Afstudeerscriptie Accountancy 2005. Littel, Vernieuwend beheersen in turbulente omgevingen, Afstudeerscriptie Accountancy 2002.


III


Bijlage 1 - COSO

Bijlage 1 - COSO

Figuur 11: COSO - kubus.


IV


Bijlage 2 - CobiT

Bijlage 2 - CobiT

Figuur 12: Het CobiT framework.


V




Figuur 13: Het Negenvlaksmodel.


VI


Bijlage 4 - Prince2

Bijlage 4 - Prince2

Figuur 14: Het Prince2 Procesmodel.


VII

Governance en IT-projecten

Recommend Documents