IT-auditing en de praktijk

IT-auditing en de praktijk tweede druk

Redactie Rob Fijneman Edo Roos Lindgreen Kai Hang Ho

Meer informatie over deze en andere uitgaven kunt u verkrijgen bij: Sdu Klantenservice Postbus 20014 2500 EA Den Haag tel.: (070) 378 98 80 www.sdu.nl/service

© 2011 Sdu Uitgevers bv, Den Haag Academic Service is een imprint van Sdu Uitgevers bv. 1e druk 2006 2e druk 2011 Zetwerk: Redactiebureau Ron Heijer, Markelo Omslagontwerp: Carlito’s Design, Amsterdam ISBN: 90 395 2627 9 NUR: 163/982 Alle rechten voorbehouden. Alle auteursrechten en databankrechten ten aanzien van deze uitgave worden uitdrukkelijk voorbehouden. Deze rechten berusten bij Sdu Uitgevers bv. Behoudens de in of krachtens de Auteurswet gestelde uitzonderingen, mag niets uit deze uitgave worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand of openbaar gemaakt in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen of enige andere manier, zonder voorafgaande schriftelijke toestemming van de uitgever. Voorzover het maken van reprografische verveelvoudigingen uit deze uitgave is toegestaan op grond van artikel 16 h Auteurswet, dient men de daarvoor wettelijk verschuldigde vergoedingen te voldoen aan de Stichting Reprorecht (postbus 3051, 2130 KB Hoofddorp, www.reprorecht.nl). Voor het overnemen van gedeelte(n) uit deze uitgave in bloemlezingen, readers en andere compilatiewerken (artikel 16 Auteurswet) dient men zich te wenden tot de Stichting PRO (Stichting Publicatie- en Reproductierechten Organisatie, Postbus 3060, 2130 KB Hoofddorp, www.cedar.nl/pro). Voor het overnemen van een gedeelte van deze uitgave ten behoeve van commerciële doeleinden dient men zich te wenden tot de uitgever. Hoewel aan de totstandkoming van deze uitgave de uiterste zorg is besteed, kan voor de afwezigheid van eventuele (druk)fouten en onvolledigheden niet worden ingestaan en aanvaarden de auteur(s), redacteur(en) en uitgever deswege geen aansprakelijkheid voor de gevolgen van eventueel voorkomende fouten en onvolledigheden. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the publisher’s prior consent. While every effort has been made to ensure the reliability of the information presented in this publication, Sdu Uitgevers neither guarantees the accuracy of the data contained herein nor accepts responsibility for errors or omissions or their consequences.

Inhoud

Voorwoord xi Dankwoord xii Inleiding 1 1

IT-projecten en programma’s 5 1.1 Inleiding 6 1.1.1 Wat is een project? 6 1.1.2 Wat is een IT-project? 7 1.1.3 Wat zijn risico’s? 8 1.2 Projectmanagement 9 1.2.1 Prince2 10 1.3 Programmamanagement 24 1.3.1 Inleiding 24 1.3.2 Programme planning & control 28 1.3.3 Organisation & leadership 31 1.3.4 Businesscasemanagement 33 1.3.5 Risicomanagement & issue resolution 35 1.3.6 Benefitsmanagement 36 1.3.7 Stakeholdermanagement & communicatie 38 1.3.8 Kwaliteitsmanagement 39 1.4 Review van projecten en programma’s 41 1.4.1 Belang van het reviewen van IT-projecten 41 1.4.2 Projectrisico’s 41 1.4.3 Projectreview 43 1.4.4 Categorisatie projectrisico’s 43 1.4.5 Uitvoering projectreview 46 1.4.6 Verschillende vormen van projectreviews 48 1.5 Samenvatting 49

2

Processen en informatiesystemen 51 2.1 Inleiding 52 2.2 Kwaliteitsaspecten 53 2.2.1 Kwaliteit 53 2.2.2 Kwaliteitscriteria volgens ISO/IEC 9126 53 2.2.3 Kwaliteitscriteria voor administratieve systemen 55 2.3 Business process analysis 55

IT-auditing en de praktijk

2.4

2.5

vi

IT application controls 61 2.4.1 Soorten IT application controls 61 2.4.2 Voorbeelden 61 Samenvatting 64

3

ERP-systemen 65 3.1 Inleiding 66 3.1.1 Omschrijving van ERP-systemen 66 3.1.2 Vergelijking met andere informatiesystemen 67 3.1.3 Aanbieders op de markt 68 3.1.4 Geschiedenis en toekomst 69 3.2 Het implementeren van ERP-systemen 69 3.2.1 Het verloop van een ERP-implementatie 70 3.2.2 Kansen en bedreigingen van een ERP-implementatie 73 3.2.3 De rol van de IT-auditor bij ERP-implementaties 76 3.3 Interne beheersing in een ERP-systeem 79 3.3.1 Interne beheersing in regelgeving 79 3.3.2 De relatie tussen ERP en interne beheersing 80 3.3.3 Interne beheersing in het kader van ERP-implementaties 82 3.3.4 Rol van de IT-auditor 84 3.4 Auditing van ERP-systemen 86 3.4.1 Kenmerken van pre- en post-implementatieaudits 86 3.4.2 Aanpak van de post-implementatieaudit 88 3.4.3 Aanpak van de pre-implementatieaudit 92 3.5 Samenvatting 94

4

IT-servicemanagement 95 4.1 Inleiding 96 4.1.1 IT-servicemanagement en professionalisering 96 4.1.2 Evenwicht tussen vraag en aanbod 98 4.2 IT-beheer in relatie tot IT-governance 99 4.2.1 Wat is IT-governance? 100 4.2.2 Waarom IT-governance? 100 4.2.3 IT-governance in relatie tot IT-beheermodellen 101 4.2.4 Van compliance naar performance 101 4.3 IT-beheer in de praktijk 103 4.3.1 Inleiding 103 4.3.2 Code of Practice for IT Service Management 104 4.3.3 ISO 20000: Code of practice for IT Service Management 105 4.4 Audit, normen en rapportage 110 4.4.1 Aanpak 110 4.4.2 Normen 111 4.4.3 Audit van beheerprocessen in de praktijk 112 4.5 Normen in relatie tot groeimodellen 112 4.5.1 Inleiding 112 4.5.2 Opzet volwassenheidsmodellen 113

Inhoud

4.6

4.7

IT-beheer in geval van uitbesteding 114 4.6.1 Inleiding 114 4.6.2 Beslissing sourcing 114 4.6.3 Selectie leverancier 118 4.6.4 Contractbeheer 119 Samenvatting 122

5

Beheersing van IT-kosten 123 5.1 Inleiding 124 5.2 Planning & control 124 5.3 Doorbelasting, costcenter of profitcenter 126 5.4 Total cost of ownership 128 5.5 Benchmarking en marktconformiteit 129 5.5.1 Wat is benchmarking? 129 5.5.2 Appels en peren 130 5.6 Audit, aanpak, normen en rapportage 132 5.6.1 Doelstelling en scope van de audit 132 5.6.2 Normen 133 5.6.3 Kwaliteitsaspecten 133 5.6.4 Rapportage 134 5.6.5 Audit versus advies 134 5.7 Samenvatting 134

6

Informatiebeveiliging 137 6.1 Inleiding 139 6.1.1 Relatie informatiebeveiliging en risicomanagement 140 6.2 Doelstellingen en eisen 141 6.3 Het beleid 142 6.4 Organisatie van informatiebeveiliging 143 6.4.1 Inrichting van de beveiligingsorganisatie 144 6.4.2 De securitymanager 145 6.4.3 Overlegorganen voor informatiebeveiliging 145 6.5 Risicoanalyse 148 6.5.1 Bedreigingen en risicogebieden 148 6.5.2 Aanpak risicoanalyse informatiebeveiliging 150 6.6 Beveiligingsmaatregelen 151 6.6.1 Incidentcyclus 151 6.6.2 Maatregelen 153 6.6.3 De Code voor Informatiebeveiliging 154 6.6.4 Raamwerk voor beveiligingsmaatregelen 157 6.7 Het beveiligingsproces: de managementcyclus 158 6.7.1 Algemene hulpmiddelen – de ‘toolkit’ voor informatiebeveiliging 159 6.7.2 Het controlemodel 161

vii


6.8

6.9

viii

Toezicht 162 6.8.1 Opzet 162 6.8.2 Bestaan en werking 162 6.8.3 Inrichting van toezicht 163 Samenvatting 164

7

Beveiliging van de IT-infrastructuur 165 7.1 Inleiding 167 7.1.1 Wat is een IT-infrastructuur? 167 7.2 De IT-infrastructuur nader bezien 170 7.2.1 De IT-infrastructuur in historisch perspectief 170 7.2.2 De technische componenten van de IT-infrastructuur 172 7.3 De beveiliging van de IT-infrastructuur 178 7.3.1 Beveiligingsaspecten 178 7.3.2 De beveiliging van TCP/IP-netwerken nader belicht 182 7.4 Beoordelen van IT-infrastructuren 184 7.4.1 De audit van de IT-infrastructuur 184 7.4.2 Compliance-monitoring van de IT-infrastructuur 191 7.5 Toekomst 193 7.6 Samenvatting 193

8

IT-auditing en accountantscontrole 195 8.1 Inleiding 195 8.2 Begrippenkader 196 8.3 Wat is accountantscontrole? 197 8.3.1 Ontwikkelingen 197 8.3.2 Risicoanalyse 197 8.3.3 Controledoelstellingen 199 8.3.4 Fasen in de jaarrekeningcontrole 199 8.4 Objecten van IT-audit in de jaarrekeningcontrole 203 8.4.1 Inleiding 203 8.4.2 Beoordelen general IT-controls: opzet en bestaan 204 8.4.3 Beoordelen application controls 206 8.4.4 Beoordelen general IT-controls: werking 207 8.5 Vertaling uitkomsten IT-audit naar bewijs voor de jaarrekeningcontrole 208 8.6 Auditsoftware 210 8.7 Samenvatting 211

9

Corporate governance en IT-governance 213 9.1 Inleiding 214 9.2 Corporate governance en IT-governance 215 9.2.1 Corporate governance 215 9.2.2 IT-governance 216 9.2.3 Normenstelsel COBIT 217

Inhoud

9.3

9.4 9.5

Behoefte aan zekerheid over IT-governance 218 9.3.1 Voorschriften 218 9.3.2 Assurancerapporten 219 9.3.3 Aanpak 221 9.3.4 SAS 70 en ISAE 3402 225 Toekomstverwachtingen 227 Samenvatting 227

Literatuur 229 Over de redactie en de auteurs 235 Register 237

ix

Voorwoord In 2010 verscheen de herziene druk van het boek Grondslagen IT-auditing, het eerste deel van een serie boeken over IT-auditing. Voor u ligt de herziene druk het tweede deel van deze reeks. Het vakgebied IT-auditing heeft de afgelopen jaren een ware opleving meegemaakt. De vraag naar IT-auditors is sterk gestegen. Het werkterrein van de IT-auditor wordt steeds verder uitgebreid met uitdagende adviesopdrachten. Vanuit de auditkerncompetenties (onafhankelijkheid, onpartijdigheid, integriteit) is de IT-auditor uitstekend geëquipeerd om IT-adviesopdrachten uit te voeren. Daarbij moet wel helderheid worden verschaft wanneer de IT-auditor in welke rol optreedt. Nieuwe professionals treden toe tot het vakgebied, in veel gevallen vanuit bestaande disciplines als accountancy, informatiemanagement of operational auditing. Tegelijkertijd geven veel IT-auditors een nieuwe impuls aan hun loopbaan; zij groeien door naar hoge posities binnen de overheid en het bedrijfsleven, hetgeen laat zien dat IT-auditing niet alleen een boeiend vakgebied is, maar ook een goede basis vormt voor een verdere carrière. Reden te meer om kennis te nemen van IT-auditing in al zijn facetten. Wij hopen dat dit boek hieraan een bijdrage kan leveren. Deel 1 kende als focus de grondslagen; dit deel beoogt juist zicht te geven op de diverse objecten van IT-audit en de gevolgde aanpak bij het beoordelen van deze objecten. In het boek wordt door diverse auteurs dieper ingegaan op specifieke aandachtsgebieden binnen IT-auditing. Aan de orde komen projecten en programma’s, informatiesystemen, procesanalyse, ERP-systemen, IT-beheer, kostenbeheersing, informatiebeveiliging, IT-auditing in het kader van de accountantscontrole en IT-governance. Elke auteur geldt als expert op het desbetreffende vakgebied; wij zijn er trots op dat auteurs van dit kaliber een bijdrage aan dit boek hebben willen leveren. Wij wensen u veel leesplezier en houden ons aanbevolen voor opmerkingen en suggesties die de kwaliteit van dit boek verder kunnen verbeteren. Amsterdam, 29 oktober 2010 Rob Fijneman Edo Roos Lindgreen Kai Hang Ho

xi

Dankwoord Dit boek is geschreven door Herman van Gils, Hans Donkers, Hans Moonen, Mark Lof, Ronald Jonker, Mark Meuldijk, Gaston Vankan, Eric Daanen, Paul Overbeek, Arne ter Laak, Peter Kornelisse, Ruben de Wolf, Brigitte Beugelaar, Jaap van Beek en Peter van Toledo. Laat deze auteurs de eer en onze grote dank toekomen. Sylvia Kruk-Troff zijn wij zeer erkentelijk voor haar ondersteuning in de correctiefase. Amsterdam, 29 oktober 2010 Rob Fijneman Edo Roos Lindgreen Kai Hang Ho

xii

Inleiding De fundamenten van het vakgebied IT-auditing zijn reeds aan de orde gekomen in ons boek Grondslagen IT-auditing (tweede druk, 2010), hierna verder kortweg aangeduid als deel 1. Details over het uitvoeren van onderzoeken naar specifieke auditobjecten bleven in dat boek echter nog onderbelicht. In dit tweede deel wordt een aantal bijzondere auditobjecten verder uitgediept langs de lijnen van de levenscyclus van een informatie systeem: van een IT-project tot een operationeel informatiesysteem dat beheerd en beveiligd moet worden, dat geld kost, en waarover uiteindelijk verantwoording moet worden afgelegd. Elk object wordt behandeld in een eigen hoofdstuk waarin het object eerst een uitgebreide toelichting krijgt; aansluitend wordt ingegaan op de wijze waarop het object aan een audit kan worden onderworpen. Prikkelende cases en concrete opdrachten geven een heldere toelichting op de theorie, zodat dit deel zich uitstekend leent voor training en opleiding. Alle hoofdstukken hebben dezelfde opbouw, maar de visies van de auteurs en de hierop gebaseerde invalshoeken geven elk hoofdstuk een eigen karakter. De indeling van dit boek is als volgt. Hoofdstuk 1 – IT-projecten en programma’s In dit hoofdstuk wordt ingegaan op de beheersing van IT-projecten en op de methoden en technieken die daarbij kunnen worden gebruikt, waaronder Prince2 en PMBOK. Tevens wordt ingegaan op programmamanagement en de rol van het programme management office (PMO). Ten slotte komt aan de orde op welke wijze een IT-project kan worden gereviewd. Hoofdstuk 2 – Processen en informatiesystemen In alle organisaties zijn processen ingericht om een effectieve en efficiënte bedrijfsvoering mogelijk te maken. Binnen processen worden gegevens verwerkt om activiteiten te ondersteunen, om andere processen aan te sturen of om verantwoording te kunnen afleggen. Dergelijke processen worden ondersteund door informatiesystemen, waarbij de betrouwbaarheid van deze informatiesystemen tot de kritieke succesfactoren voor het bedrijfsproces zal behoren. In dit hoofdstuk wordt ingegaan op methoden en technieken voor het analyseren en toetsen van processen en informatiesystemen, waarbij bijzondere aandacht wordt besteed aan Business Process Analysis. Hoofdstuk 3 – ERP-systemen In dit hoofdstuk wordt aandacht besteed aan de invloed van de implementatie van enterprise resource planningsystemen (ERP-systemen) op vraagstukken van interne beheersing, beveiliging en auditing. Allereerst wordt ingegaan op de vraag wat een ERP-systeem is, wat het onderscheidt van andere soorten informatiesystemen en wat de belangrijkste ERP-systemen zijn op de huidige markt. Vervolgens wordt aandacht besteed aan de manier waarop ERP-systemen in organisaties kunnen worden geïmplementeerd. Voorts wordt ingegaan op de belangrijkste risico’s van ERP-implementaties en wordt de rol van de IT-auditor tijdens ERP-projecten toegelicht. Vervolgens wordt


de relatie tussen ERP-systemen en interne beheersing besproken. Soorten van interne beheersingsmaatregelen in en om ERP-systemen en de samenhang daartussen worden in dit hoofdstuk verder uitgewerkt. Als afsluiting wordt een verdieping van de aanpak van IT-audits op ERP-systemen behandeld. Hoofdstuk 4 – IT-servicemanagement In dit hoofdstuk gaan de auteurs in op IT-servicemanagement, de procesmatige beheersing van IT. Hiertoe behandelen zij eerst de te onderkennen processen binnen ITservicemanagement en IT-beheer en de diverse modellen die hiervoor bestaan. Daarna gaan zij in op het niveau van volwassenheid van IT-beheer, de noodzaak voor volwassenheid en een aantal volwassenheidsmodellen. In de praktijk zal de IT-auditor geconfronteerd worden met diverse modellen en op maat gemaakte uitwerkingen. Deze modellen zijn bedoeld om structuur aan te brengen in IT-beheer, zodat de IT-dienstverlening effectief en onder controle is. Hoofdstuk 5 – Beheersing van IT-kosten In dit hoofdstuk wordt stilgestaan bij een van de onderwerpen die menig CIO, CEO of IT-manager bezighoudt: het beheersen van de kosten die met IT gepaard gaan, ofwel IT-costmanagement. Om inzicht te krijgen in de verschillende aspecten van IT-cost management wordt allereerst ingegaan op de cyclus planning en control. Vervolgens wordt aandacht besteed aan de onderwerpen doorbelasting, total cost of ownership, contracten, uitbesteding en benchmarking. Het hoofdstuk wordt afgesloten met een beschrijving van de aanpak en aandachtspunten bij de uitvoering van audits naar ITkosten en IT-costmanagement. Hoofdstuk 6 – Informatiebeveiliging Dit hoofdstuk geeft de lezer inzicht in de inhoud en het doel van informatiebeveiliging. Uitgelegd wordt met welke interne en externe eisen rekening gehouden moet worden. De belangrijkste dreigingen worden behandeld, alsmede de belangrijkste te treffen maatregelen, en het proces om dreigingen en maatregelen in het juiste evenwicht te houden. Het hoofdstuk sluit af met een blik op het uitvoeren van audits rond informatiebeveiliging. Hoofdstuk 7 – Beveiliging van de IT-infrastructuur In dit hoofdstuk behandelen de auteurs het fundament van elke geautomatiseerde omgeving, de IT-infrastructuur. Zij gaan in op de karakteristieken van de IT-infra structuur, geven een decompositie van de IT-infrastructuur in een gelaagd model van de bouwstenen van de IT-infrastructuur en gaan vervolgens dieper in op de beveiliging van deze bouwstenen. Het hoofdstuk besluit met een toelichting op de aanpak van enerzijds een IT-audit met als doel de beveiliging van de IT-infrastructuur te beoor delen, en anderzijds compliance-monitoring met als doel periodiek vast te stellen of de IT-infrastructuur nog voldoet aan het beveiligingsbeleid, het -ontwerp en de -standaarden.

Inleiding

Hoofdstuk 8 – IT-auditing en accountantscontrole In dit hoofdstuk gaan de auteurs beknopt in op de functie van IT-auditing in het kader van de accountantscontrole. Hiertoe beschrijven zij op hoofdlijnen wat accountantscontrole is en hoe een IT-audit daarbinnen past. Vervolgens beschrijven zij de onderzoeksobjecten van een IT-audit in het kader van de jaarrekeningcontrole en hoe de normering tot stand komt. Verder besteedt dit hoofdstuk aandacht aan de communicatie met, en de rapportage aan de accountant. Het hoofdstuk besluit met een verwachting over de wijze waarop IT-auditing zich in de komende jaren zal ontwikkelen, mede als gevolg van ontwikkelingen zoals Sarbanes-Oxley en corporate governance. Hoofdstuk 9 – Corporate governance en IT-governance In dit hoofdstuk gaat de auteur in op corporate governance en IT-governance, oftewel behoorlijk ondernemingsbestuur respectievelijk behoorlijk bestuur van de informatie voorziening. Hiertoe wordt eerst in grote lijnen aangegeven wat corporate governance en IT-governance zijn, uit welke componenten IT-governance bestaat, en hoe de governanceregels in de praktijk kunnen worden geëffectueerd. Het hoofdstuk besluit met een verwachting over de wijze waarop IT-governance zich de komende jaren zal ontwikkelen, waarbij bijzondere aandacht wordt besteed aan assurancerapporten en SAS 70 (tegenwoordig ISAE 3402). De hoofdstukken zijn beschouwend van aard. Gedetailleerde werkplannen, normenkaders, voorbeeldrapporten en andere hulpmiddelen die een audit in praktische zin kunnen ondersteunen, maken geen deel uit van dit boek. Hiervoor is bewust gekozen, enerzijds om ervoor te zorgen dat het boek geen opsomming van checklists wordt maar leesbaar blijft, anderzijds omdat de ervaring leert dat gedetailleerde vragenlijsten en andere ondersteunende halffabrikaten in veel gevallen geen recht doen aan de diversiteit die de praktijk eigen is en daarnaast zelden de tand des tijds kunnen doorstaan. Voor actuele praktische hulpmiddelen kan de lezer terecht op internet.

1

IT-projecten en programma’s

Hans Donkers, Hans Moonen en Mark Lof Aan IT-projecten zijn bijzondere risico’s verbonden. Dit hoofdstuk gaat in op de beheersing van IT-projecten en op de methoden en technieken die daarbij kunnen worden gebruikt, zoals bijvoorbeeld Prince2. Tevens wordt ingegaan op programmamanagement en de rol van het programme management office (PMO). Ten slotte komt aan de orde op welke wijze een IT-project kan worden getoetst. Competentiedoelen Na het bestuderen van dit hoofdstuk moet de lezer in staat zijn om aan te geven: V wat projecten programmamanagementmethoden inhouden; V wat de verschillende stadia zijn in een automatiseringsproject; V welke standaarden er zijn voor het beheerst uitvoeren van projecten en programma's, zoals Prince2 en MSP; V aan welke risico’s grote projecten en programma’s worden blootgesteld; V hoe deze risico’s kunnen worden beheerst; V hoe projectreviews zekerheid kunnen geven bij automatiseringsprojecten; V welke aanpak daarbij zou moeten worden gevolgd; V welke normenkaders daarbij kunnen worden gehanteerd; V hoe en wanneer het beste gerapporteerd zou kunnen worden; V welke beperkingen aan projectreviews zijn verbonden; V welke specifieke aandacht er voor uitvoering van een projectreview dient te zijn.

Casus RaamOK, een productieonderneming met een jaaromzet van 120 miljoen euro, bestaat uit drie divisies die elk afzonderlijk bestaan uit enkele werkmaatschappijen. De divisies zijn op dit moment autonoom ten aanzien van de invulling van de informatievoorziening. Er is per divisie één ICT-organisatie die diensten verleent aan de werkmaatschappijen binnen de divisie; de informatievoorziening binnen elke divisie is geüniformeerd naar een of twee systemen. De ICT-organisatie van een van de divisies verzorgt eveneens het technisch beheer voor de holdingsystemen. Op basis van een ontwikkelde langetermijnstrategie van RaamOK is besloten een omvangrijk programma op te starten met als doel de informatievoorziening verder te centraliseren en te uniformeren. Dit betekent niet alleen dat er één centrale ICT-organisatie ingericht dient te worden als een shared-servicecenter, maar ook dat de huidige informatiesystemen dienen te worden gemigreerd naar een nog te selecteren standaardpakket. Het programma heeft een geplande doorlooptijd van drie jaar. Uitgangspunten voor dit programma zijn de metho-


den MSP voor het programmamanagement en Prince2 voor het projectmanagement. Gezien de omvang van de veranderingen, de beoogde snelheid en de daardoor noodzakelijke acceptatie zijn een breed draagvlak en acceptatie van dit programma/project van groot belang. Besloten is de verschillende belanghebbende partijen daar waar mogelijk te betrekken bij dit programma/project en de tussenproducten daarvan.

Opdracht 1.1 Onderken de belangrijkste risico’s van de voorgenomen veranderingen voor RaamOK en voor het programma/project.

1.1

Inleiding

Bij het uitvoeren van een project worden altijd risico’s gelopen. Hoewel de financiële risico’s van een project vaak de aandacht krijgen van projectleiders en eindverantwoordelijken, zijn niet alleen deze risico’s van belang bij een project. Ook risico’s op het gebied van techniek en doorlooptijd verdienen de aandacht. In deze paragraaf wordt beschreven wat wordt verstaan onder het begrip project en de verschillende vormen van IT-projecten. Daarna wordt ingegaan op methoden voor projectmanagement, waarbij uitgebreid wordt ingegaan op de veelgebruikte methode Prince2. 1.1.1

Wat is een project?

In de literatuur worden verschillende definities voor een project gegeven, waaronder: ‘Een geheel van samenhangende activiteiten, uitgevoerd ten behoeve van een vooraf overeengekomen resultaat, met een begin en een einde, gebruikmakend van begrensde middelen en menskracht en meestal eenmalig van aard.’ (Aken, 1997) ‘Een project is een eenmalig uit te voeren reeks van activiteiten met vooraf vastgestelde doelstellingen. Het project kan onderverdeeld worden in verschillende taken, die uitgevoerd moeten worden om de projectdoelstellingen te behalen. De taken dienen onderling gecoördineerd te worden om de tijds-, prioriteits-, kosten- en resultaataspecten van het project te beheersen.’ (Mantel, 1995) ‘Projecten zijn tijdelijke, resultaatgerichte samenwerkingsverbanden tussen mensen, waarbij gebruik wordt gemaakt van schaarse middelen.’ (Renes, 1996)

Hoofdstuk 1 – IT-projecten en programma’s

‘Een gecreëerde managementomgeving met als doel het opleveren van een of meer organisatorische producten volgens een specifieke businesscase.’ (OGC, 2002) Hoewel deze definities het begrip project allemaal op een andere wijze beschrijven, kan worden geconcludeerd dat een project een geheel van samenhangende activiteiten is om een vooraf bepaald organisatorisch doel te bereiken, waarbij rekening moet worden gehouden met een vooraf bepaalde kwaliteit en beperkte tijd en budget voor de realisatie van dit doel. 1.1.2

Wat is een IT-project?

Informatietechnologie heeft zich ontwikkeld van een eenvoudig hulpmiddel voor efficiency- en effectiviteitsverhoging tot een essentieel instrument voor de ondersteuning van de strategie en de vernieuwing van processen, producten en cultuur (Roelofs, 1996). De meeste IT-toepassingen worden projectmatig ontwikkeld en ingevoerd. Wanneer het gaat om de invoering van een standaardpakket, zoals Exact of SAP, is er niet echt sprake van ontwikkeling. Wel kan het zijn dat zo’n standaardpakket moet worden aangepast, bijvoorbeeld als het pakket niet voldoende of niet de juiste functionaliteit biedt. Ofschoon daarbij strikt genomen wel sprake is van ontwikkeling, worden zulke aanpassingen meestal tot de implementatiefase gerekend. IT-auditors worden regelmatig geconfronteerd met de problematiek rondom het beheersen van IT-projecten. Het kan daarbij onder meer gaan om een softwareontwikkelingstraject, een implementatie van een financieel of administratief ondersteunend systeem of de aanleg van een netwerk. IT-projecten kunnen zeer uiteenlopen wat betreft hun invloed op de organisatie en hun bijdrage aan de bedrijfsprocessen. Daarom is het nuttig een indeling van IT-projecten te hanteren. Kleyn (1994) geeft een indeling voor IT-projecten waarbij het type IT-project afhankelijk is van de invloed die het project heeft op de organisatie. V IT als hulpmiddel: optimalisatie van doelmatigheid (efficiency) van routinematige werkzaamheden binnen bestaande processen. ‘We deden iets met de hand en nu doen we hetzelfde, maar alleen sneller met behulp van de computer.’ Er wordt uitgegaan van bestaande werkprocessen en organisatorische structuren. V IT als beheersingsmiddel: afstemming en beheersing van bestaande processen, door geïntegreerde systemen over afdelingen heen. Deze projecten ontstaan omdat de huidige informatievoorziening oud, ongedocumenteerd en dus slecht te onderhouden is en de IT-afdeling niet meer de gewenste aanpassingen kan uitvoeren. V IT als verbeterinstrument: naast het ontwikkelen van systemen wordt ook naar bestaande processen gekeken, deze worden verbeterd, gestroomlijnd of zelfs volledig herontworpen. In het algemeen wordt daarbij wel uitgegaan van bestaande organisatiestructuren. V IT als strategisch wapen: het functioneren van de gehele organisatie en haar afstemming op de omgeving fundamenteel verbeteren. Vanuit de strategische doelstelling, rekening houdend met mogelijkheden van IT, worden de processen opnieuw opgezet.


In principe geeft deze indeling alleen inzicht in de invloed van de projecten op de bestaande processen en het doel van de inzet van IT. Deze indeling kan echter worden aangevuld met een aantal karakteristieken voor de verschillende categorieën ITprojecten. Daarmee wordt meer concrete informatie gegeven over de doorlooptijd, de complexiteit, de kosten, de risico’s en de participatie van de gebruiker bij het project. Tabel 1.1 geeft een overzicht van de karakteristieken van IT-projecten, gebaseerd op de indeling van Kleyn, aangevuld met enkele voorbeelden. Tabel 1.1 Overzicht soorten IT-projecten Karakteristiek

IT als hulpmiddel

IT als beheersings middel

IT als verbeter instrument

IT als strategisch wapen

Voorbeeld

Het automatiseren van ‘kaartenbakken’ en vergelijkbare administratieve processen

Implementatie van een uitgebreid financieel pakket met mogelijkheden voor het genereren van managementrapportages

Invoering van een ERP-systeem

E-businesstoepassingen

Doelstelling

Efficiëntieverbetering

Verbetering van de informatievoorziening

Verbetering van bedrijfsprocessen en informatievoorziening

Structurele ver betering van de bedrijfsvoering

Schaalgrootte

Klein

Middelgroot

Groot

(Zeer) groot

Doorlooptijd (schatting)

Aantal maanden

Aantal maanden tot een jaar

Half jaar tot anderhalf jaar

Een tot drie jaar

IT-complexiteit

Gering

Redelijk

Groot

(Zeer) groot

Organisatorische en sociale complexiteit

Gering

Beperkt

Groot

(Zeer) groot

Faalkans

Klein

Matig

Groot

(Zeer) groot

Faalkosten

Beperkt

Redelijk

Hoog

Extreem hoog

Rol van de gebruiker

Gering

Op verzoek bij ontwerp en acceptatie

Actieve participatie

Analist en ontwerper

De projecten waarbij IT als verbeterinstrument of strategisch wapen wordt ingezet, zijn dus omvangrijk, complex en van vitaal belang voor de organisatie. Een adequate projectbeheersing is bij deze projecten van groot belang, maar juist deze projecten zijn zeer lastig te beheersen. 1.1.3

Wat zijn risico’s?

In hoofdstuk 2 van deel 1 is risico gedefinieerd als een functie van de kans op het optreden van een dreigende gebeurtenis en de negatieve impact ofwel schade van die gebeur-


tenis. Men spreekt van projectrisico’s indien er sprake is van risico’s die een bedreiging vormen voor een goede uitkomst van een project, of risico’s die van invloed zijn op activiteiten binnen een project. In veel gevallen zijn dit risico’s die uiteindelijk de doorlooptijd, de kosten of de kwaliteit van het eindproduct van een project beïnvloeden.

1.2

Projectmanagement

Zoals in de inleiding van dit hoofdstuk is aangegeven, worden veel projecten niet gerea liseerd binnen de vooraf gestelde tijd, het vooraf vastgestelde budget en met de vooraf bepaalde kwaliteit van het eindproduct. Hoewel een methode voor projectmanagement geen garantie biedt voor het slagen van een project, is het gebruik hiervan een voorwaarde voor een goede sturing en beheersing van een project. Om deze reden zijn er ook diverse methoden beschikbaar voor het managen van een project. Enkele voorbeelden hiervan zijn: V PRojects IN Controlled Environments (Prince2); V Project Management Body Of Knowledge (PMBOK) van het Project Management Institute; V applicatiespecifieke projectmanagementmethoden, zoals customer development method voor de implementatie van Oracle en Accelerated SAP voor de implementatie van SAP. Hoewel de beschikbare methoden allemaal verschillen qua ondersteunde functies, benaderingswijze, beschikbare tools en volledigheid, hebben alle methoden de volgende kenmerken: V De aandacht is met name gevestigd op het creëren van een goede planning. V Het project wordt in meerdere componenten gesplitst, waarbij de fasering is gebaseerd op het tijdsaspect of het productaspect. V Er zijn meerdere tools beschikbaar voor de ondersteuning van de projectleider, met name checklists en voortgangsrapportages. V De methode richt zich primair op de componenten tijd en budget. Naast het gebruik voor de sturing van een project op verschillende gebieden, worden de methoden bijvoorbeeld ook vaak gebruikt voor het bieden van een gestructureerde en weloverwogen set van activiteiten aan het projectteam, het duidelijk specificeren van taken en bevoegdheden van projectmedewerkers en het bieden van een uniforme werkwijze. Uiteindelijk zal professioneel projectmanagement ervoor moeten zorgen dat het project op een adequate manier wordt gestuurd en dat de juiste activiteiten worden uitgevoerd om het gewenste resultaat te bereiken, namelijk de oplevering van de juiste producten die voldoende bijdragen aan de doelstellingen van de organisatie binnen het hiervoor beschikbare budget en de tijdslimiet (Onna, 2002). In Nederland is een veel gebruikte projectmanagementmethode Prince2. Deze methodiek wordt zowel verguisd als geprezen. Verguisd als een methode waarmee organi-


saties zich tegen klachten achteraf kunnen indekken, geprezen als nuttig hulpmiddel voor de beheersing van projecten. Feit is wel dat Prince2 steeds vaker wordt gebruikt voor verschillende soorten projecten in zeer verschillende sectoren. Hierna wordt, na een korte positionering van Prince2, het begrip projectmanagement aan de hand van deze methode verder beschreven. 1.2.1

Prince2

Prince2 is oorspronkelijk ontworpen door de Central Computer and Telecommunication Agency (CCTA). De CCTA is later overgegaan in het Office of Government Commerce (OGC), dat verschillende verbeteringen aan de methode heeft aangebracht. Prince2 is een procesgeoriënteerde methode en algemeen toepasbaar voor verschillende typen projecten. De methode is gebaseerd op praktijkervaringen en praktijkvoorbeelden van allerlei verschillende projectmanagementmethoden en stelt ‘best practice’-werkwijzen op, ondersteund door verschillende soorten richtlijnen en checklists. De methode is begonnen als de standaard voor projecten binnen de Britse overheid, maar wordt in steeds meer landen toegepast. Zoals gezegd kenmerkt Prince2 zich door een procesmatige benadering. Een proces wordt hierbij gedefinieerd als een serie van samenhangende activiteiten die een bepaald doel nastreven. Prince2 kent acht hoofdprocessen, ieder met een aantal eigen activiteiten. Deze processen worden hieronder beschreven. Naast de acht hoofdprocessen kent Prince2 ook acht componenten als onderdelen van projectmanagement. De componenten kunnen worden beschouwd als bouwstenen voor de processen. Deze componenten worden daarna beschreven. Ten slotte zijn er nog drie Prince2-specifieke technieken die kunnen worden toegepast voor de beheersing tijdens de loopduur van een project; deze worden behandeld aan het eind van deze paragraaf. De samenhang tussen al deze elementen is weergegeven in figuur 1.1.

Change Control

Processen + Componenten + Technieken

Business Case

Directing a project

Configuration Management

Organisation Initiating a Project

Starting up a Project

Controlling a Stage

Managing Stage Boundaries

Closing a Project

Managing Product Delivery

Quality

Plans Planning

Management of Risk

Controls

Figuur 1.1 Samenhang tussen componenten Prince2

10

– Product-based planning – Change control approach – Quality review


Alle processen, componenten en technieken kunnen worden gebruikt voor een project. Er moet echter een afweging worden gemaakt of dit ook daadwerkelijk nodig is. Hiermee wordt voorkomen dat een project enerzijds te bureaucratisch wordt en anderzijds dat er te veel tijd en geld in projectmanagement gaat zitten, omdat de gehele methode te uitgebreid is voor het betreffende project. Deze afweging zal voornamelijk gebaseerd zijn op factoren als de complexiteit en grootte van een project, en de aan het project verbonden risico’s (Onna, 2002). Procesmodel Ieder proces van Prince2 bestaat uit een aantal activiteiten/subprocessen die bepaalde producten tot eindresultaat hebben. Deze processen hebben als doel het project beheerst te laten verlopen. Figuur 1.2 biedt een overzicht van de beschikbare processen binnen Prince2. Zoals inzichtelijk is in deze figuur, sluiten de verschillende processen goed aan bij de fasen van een project. De processen worden hieronder kort toegelicht. Voor een uitgebreide beschrijving van de processen, alle subprocessen, activiteiten en opgeleverde producten wordt verwezen naar (CCTA, 1999), (OGC, 2002), en (Onna, 2002). Projectboard

Directing a project

Initiating a Project

Projectmanager

Starting up a Project

Teammanager(s)

Projectmanager

Controlling a Stage

Managing Stage Boundaries

Closing a Project

Managing Product Delivery

Planning

Figuur 1.2 Processen binnen Prince2

Starting up a project (SU) Het proces ‘starting up a project’ is een preprojectactiviteit en vindt voorafgaand aan de uitvoering van een project plaats. De doelstelling is het waarborgen dat alle vereisten om een project te starten beschikbaar zijn. Dit omvat het vaststellen van het managementteam en de verdere projectorganisatie, inclusief alle taken en verantwoordelijkheden van de personen, het opstellen van een aanpak voor de oplevering van het uiteindelijke product, het vaststellen van de verwachtingen van de klant respectievelijk de business, het verduidelijken van de redenen en doelstellingen van het project en een eerste risico-inventarisatie. De resultaten van dit proces zijn de projectbrief, de project

11


aanpak, de projectorganisatiestructuur, het initiatiefaseplan (‘initiation stage plan’) en de risicolog. Directing a project (DP) Directing a project’ is het proces dat is gericht op de stuurgroep (‘project board’) van het project. Een stuurgroep bestaat uit beslissingsbevoegde managers die de business, de gebruikers en de leverancier vertegenwoordigen. Deze stuurgroep stuurt bij op basis van uitzonderingen, bewaakt voortgang via rapportages en bestuurt het project op basis van een aantal beslispunten. De aandachtsgebieden voor de stuurgroep betreffen met name de initiatie van een project, waarbij vooral wordt ingeschat of het project het waard is om een investering te doen en of er een valide businesscase is die past binnen de strategie van de organisatie, het afsluiten en opstarten van fasen binnen een project, het geven van ad-hocsturing door middel van beslissingen en het afsluiten van het project. Een stuurgroep wordt over het algemeen gezien als een belangrijk onderdeel van een project en wordt dan ook vaak ingezet. Echter, een stuurgroep is allerminst een garantie voor het slagen van een project. Hiervoor zullen de taken en bevoegdheden van een stuurgroep duidelijk omschreven moeten zijn en moet de stuurgroep voldoende participeren in een project (Lof, 2002). Het proces ‘directing a project’ speelt een rol gedurende de hele levensduur van een project. Initiating a project (IP) ‘Initiating a project’ is het proces dat ervoor moet zorgen dat de definitieve (rand)voor waarden van een project gecreëerd en geaccordeerd worden. Het legt hiermee een fundament voor een project. Het proces zal zich dan ook richten op het vaststellen hoe de verlangde productkwaliteit geleverd gaat worden, het plannen en budgetteren van het project, het documenteren en accorderen van de businesscase, het verzekeren dat de te leveren inspanning voor het project is geaccordeerd, het verantwoordelijk stellen van de stuurgroep voor het project, het leggen van een basis voor het besluitvormings proces en de beheersingsmaatregelen voor de duur van het project en de accordering van de benodigde resources. Al deze punten zijn beschreven in het uiteindelijke resultaat van dit proces, het beslis- en referentiedocument van het project. Dit wordt ook wel het project initiation document (PID) genoemd. Een van de belangrijkste onderdelen van het PID is het projectplan, dat in het proces ‘planning (PL)’ wordt opgesteld. Hier wordt later op ingegaan. Controlling a stage (CS) Het proces ‘controlling a stage’ betreft de beheersingsactiviteiten die de project manager dient uit te voeren om de projectactiviteiten binnen een fase van een project in goede banen te leiden. Dit proces vormt de kern van de activiteiten van een projectmanager. Elke projectfase wordt gekenmerkt door de volgende beheersingsactiviteiten: het toewijzen van uit te voeren werkzaamheden, het verzamelen van voortgangsinformatie, het signaleren van veranderingen, het beoordelen van de voortgang, de issues en de risico’s van de huidige situatie, het rapporteren van resultaten en excepties aan de belanghebbenden en het bijsturen van werkzaamheden.

12


Managing product delivery (MP) Het proces ‘managing product delivery’ richt zich op het projectmanagement. Dit proces is van belang bij de operationele uitvoering van activiteiten binnen het project en zal veelal worden gebruikt door teamleiders in plaats van projectmanagers. Uiteraard is er wel afstemming met het projectmanagement en dus grote verbondenheid met het proces ‘controlling a stage’. De doelstelling van dit proces is om er zeker van te zijn dat de geplande producten zijn opgeleverd door te controleren of het gealloceerde werk aan een bepaald team is geautoriseerd en geaccordeerd, vast te stellen dat het werk is uitgevoerd, voortgangscontroles uit te voeren, te waarborgen dat opgeleverde producten voldoen aan de kwaliteitscriteria en specificaties en goedkeuring te verkrijgen voor de opgeleverde (deel)producten. De producten van dit proces zijn teamplans, updates van de kwaliteitslog, een overzicht van issues binnen een onderdeel van het project, een aangepaste risicolog en checkpoint reports van de teamleider aan de projectmanager. Managing stage boundaries (SB) De hiervoor beschreven processen ‘controlling a stage’ en ‘managing product delivery’ richten zich op de beheersing van een fase van een project, waarbinnen bepaalde producten op tijd, binnen budget en conform de opgestelde kwaliteitseisen worden opgeleverd. Het proces ‘managing stage boundaries’ omvat activiteiten die nodig zijn voordat er met de volgende fase van een project kan worden begonnen. De stuurgroep zal een beslissing moeten nemen over het wel of niet doorgaan met het project. Dit proces levert informatie voor de stuurgroep voor ondersteuning van het besluitvormingsproces. De doelstellingen van dit proces zijn het verzekeren van de stuurgroep van het feit dat de op te leveren producten, zoals opgenomen in de planning, zijn opgeleverd, de stuurgroep voorzien van informatie omtrent de levensvatbaarheid van het project, het voor de stuurgroep inzichtelijk maken in hoeverre er op verantwoorde wijze kan worden begonnen aan de volgende fase van het project en het vastleggen van meetresultaten en/of andere ervaringen die kunnen helpen bij de voortgang van het project en/of andere projecten. De producten van dit proces zijn verschillende plannen (end-stageplan, current-stageplan en een next-stageplan) en aanpassingen aan het projectplan, de risicolog en de businesscase. Closing a project (CP) De doelstelling van dit proces is het beheerst afronden van het project. Het merendeel van de activiteiten is er dan ook op gericht om informatie te verzamelen voor de besluitvorming over de afronding van het project door de stuurgroep. Hiervoor zal moeten worden bepaald in hoeverre de doelstellingen zijn verwezenlijkt, of de opdrachtgever akkoord is met de opgeleverde producten en of deze geaccepteerd zijn, en zal moeten worden vastgesteld of operationele voorzieningen inclusief onderhoud en trainingen aanwezig zijn. Tevens zullen enkele meer administratieve taken moeten worden voltooid, zoals het opstellen van aanbevelingen inzake toekomstig werk en/of veranderingen, het vastleggen van de ‘geleerde lessen’ uit het project, het voorbereiden, opleveren en archiveren van een projectrapport, en het archiveren van de overige

13


projectdocumentatie. Ten slotte zal een beoordelingsplan moeten worden opgesteld en dient de organisatie op de hoogte te worden gebracht van de afronding van het project. Dit proces zal niet alleen moeten worden uitgevoerd bij het succesvol afronden van een project, maar ook bij het voortijdig beëindigen van een project, aangezien dan de geleerde lessen van het project van belang zijn. Planning (PL) Het proces ‘planning’ is een continu proces dat een belangrijke rol speelt in andere processen en fasen van een project. Bij ieder project is planning namelijk een basis voor het effectief uitvoeren en beheersen van een project. Tevens voorziet het alle betrokkenen bij een project van informatie over wat er moet worden gedaan, hoe, wanneer en door wie en welke middelen moeten worden ingezet. Binnen Prince2 worden verschillende soorten planningen opgesteld, namelijk een planning van de initiatiefase (initia tion-stageplan), een (globale) planning van het project zelf (projectplan), een meer gedetailleerde planning van een afzonderlijke fase (stageplan), planning van een team (teamplan) en een planning die moet worden uitgevoerd bij excepties (exceptionplan). Prince2 maakt gebruik van product-basedplanning, waarbij een planning wordt opgesteld aan de hand van producten van activiteiten (mijlpalen). Dit proces bevat activiteiten voor het definiëren van producten, het schatten van inspanningen en kosten, het analyseren van risico’s en het opstellen van een planning. Componenten Naast de bovengenoemde processen van Prince2 bestaat de methode ook uit verschillende componenten voor de beheersing van projecten. Deze componenten kunnen worden beschouwd als bouwstenen voor de processen. Er is dan ook een sterke samenhang tussen de processen en de componenten. Gedurende de processen worden de componenten ontworpen, ingericht, aangepast en uitgevoerd. Figuur 1.3 geeft een overzicht van de componenten van Prince2, die daarna kort worden toegelicht. Business Case De businesscase is de basis voor de uitvoering van een project. In deze businesscase staan de redenen voor de uitvoering van het project vermeld samen met de verantwoording van het project in termen van geschatte kosten en verwachte baten. Tevens zijn hierin de risico’s van het project vermeld. Voor aanvang wordt er een globale business case opgesteld met de wijze waarop het project bijdraagt aan de doelstellingen van de organisatie. Op basis hiervan wordt beslist of er wordt begonnen met het project. Tijdens de eerste fase van een project wordt de businesscase verder uitgewerkt, met name de scope en het risicoprofiel van het project. De scope behandelt alle veranderingen in de business die door de uitvoering van het project worden bereikt. In het risicoprofiel van het project wordt een eerste inventarisatie van de belangrijkste risico’s gemaakt. Deze onderdelen worden eveneens tijdens de uitvoering van het project geëvalueerd en bijgesteld. Wanneer er geen geldige businesscase voor een project meer is, wordt het project (tijdelijk) gestopt.

14


Change Control

Business Case

Configuration Management

Organisation

Quality

Plans

Management of Risk

Controls

Figuur 1.3 Componenten van Prince2

Een businesscase kan per project verschillen in omvang. Een project met weinig impact op de business zal veelal een kleinere businesscase hebben dan een project met een zeer grote impact. Het verschil zal zich met name uiten in de mate van detaillering. In de praktijk blijkt iedere businesscase veelal de hierboven vermelde onderdelen te bevatten. Organisation Deze component beschrijft de projectorganisatie. Dit betreft de verschillende functies inclusief de taken en verantwoordelijkheden en de onderlinge samenhang tussen de functies. Door een heldere omschrijving van de organisatie is voor alle projectmedewerkers duidelijk wat er van hen wordt verwacht en waarvoor zij verantwoordelijk zijn. Een effectieve projectorganisatie is cruciaal voor het succes van een project. Bij ieder project is namelijk communicatie en sturing van groot belang. De projectorganisatie van Prince2 is gebaseerd op de zogenaamde klant/aanbiederstructuur. Hierbij wordt verondersteld dat ieder project een klant en een aanbieder kent. Een klant specificeert het eindproduct, maakt gebruik van het eindproduct en betaalt hier ook voor. De aanbieder zal het project uitvoeren en de resources en kennis leveren om het eindproduct te realiseren. De klant en aanbieder kunnen zich in dezelfde organisatie bevinden of geheel onafhankelijk zijn. Een projectorganisatie kan per project zeer verschillen, maar dient wel alle belanghebbenden bij dat project te betrekken. In veel gevallen zijn dit de projectmanager, de teamleiders, de projectmedewerkers, een stuurgroep en een projectbureau. Deze personen dienen over de specifieke kennis en vaardigheden van de rollen te beschikken.

15


Figuur 1.4 geeft een voorbeeld van een standaard Prince2-projectorganisatie (Hedeman, 2000). Project Board / Stuurgroep

Projectbureau

Project Assurance

Projectmanager

Teamleider

Teamleider

Projectmedewerkers

Figuur 1.4 Standaard Prince2-projectorganisatie

Wanneer sprake is van meerdere projecten binnen een organisatie, kan ook nog een programmamanager aan de organisatie worden toegevoegd. Het programmamanagement kan worden omschreven als het gecoördineerd managen van een verzameling projecten binnen een organisatie die veranderingen willen doorvoeren die van strategisch belang zijn. Het onderdeel programmamanagement valt niet expliciet binnen de scope van dit boek, hoewel het onderwerp soms zijdelings kan worden aangehaald. Een verdere beschrijving is te vinden in Hof (2002). De stuurgroep geeft sturing aan het project en kan als klankbord dienen voor de projectmanager. In de stuurgroep zitten mensen vanuit de business, (eind)gebruikers en leveranciers. Het is belangrijk dat de stuurgroep voldoende beslissingsbevoegdheid heeft, aangezien zij beslissingen zal moeten nemen over het project. Veelal zullen dit dan ook personen zijn op seniormanagementniveau. De stuurgroep geeft sturing in het geval er uitzonderingen zijn op de normale voortgang van het project, het zogenaamde ‘management by exception’. Tevens zullen zij bij een overgang naar een volgende fase in het project beslissingen nemen en goedkeuring geven. De projectassurance dient voor de quality-assurance in een project. Dit onderdeel zal dan ook veelal controleren of het project op een beheerste wijze wordt uitgevoerd en of het project en de (tussen)producten voldoen aan de vooraf gedefinieerde kwaliteits eisen. Vervolgens wordt dit gerapporteerd aan de stuurgroep (‘project board’). Ten slotte geeft de projectmanager dagelijkse sturing aan het project, die hij op zijn beurt weer kan delegeren aan teammanagers van verschillende onderdelen binnen de projectorganisatie. De projectmanager is verantwoordelijk voor het managen van het project en zal zelf dus geen operationele werkzaamheden moeten verrichten.

16


Het gehele project kan op administratief gebied worden ondersteund door de project support. Dit kan veel verschillende taken omvatten, zoals administratieve verwerking van gegevens tot ondersteuning bij het gebruik van tools voor planning. Niet alleen werken personen in de organisatie fulltime voor een project, ook zullen er personen zijn die slechts een gedeelte van hun beschikbare tijd aan het project besteden. Tevens kunnen personen uit verschillende afdelingen van een organisatie zich in de projectorganisatie bevinden. Op deze wijze kunnen geheel diverse soorten projectorganisaties ontstaan. Plans Bij ieder project zijn plannen een basis voor het effectief uitvoeren en beheersen van een project. Het maken van plannen is dan ook een ‘verplicht’ onderdeel van een project. Zonder deze plannen is beheersing van een project bijna niet mogelijk. Plannen moeten ervoor zorgen dat de juiste producten op de juiste tijdstippen worden opgeleverd door de juiste personen tegen de juiste kwaliteit en kosten. Onderdelen van een plan zijn dan ook: V de te realiseren (tussen)producten, ook wel mijlpalen genoemd; V de activiteiten om deze (tussen)producten te realiseren; V de activiteiten om de kwaliteit van de opgeleverde (tussen)producten te controleren; V de benodigde doorlooptijd om de activiteiten uit te voeren; V de aanvangstijd en eindtijd van een activiteit; V de benodigde resources om de activiteiten uit te voeren, inclusief de kennis en kunde van de resources; V de afhankelijkheden tussen de activiteiten; V externe afhankelijkheden van het aanleveren van informatie, producten of resources; V punten waarop de voortgang van het project wordt gemeten en gecontroleerd; V afgesproken toleranties. Zoals vermeld bij het proces ‘planning’ maakt Prince2 gebruik van meerdere soorten plannen, zoals een projectplan, een stageplan en een eventueel teamplan. Deze plannen verschillen in de mate van detaillering. Het projectplan bevat een planning voor het gehele project en is meestal op hoofdniveau weergegeven. Een stageplan is een detailplanning per fase van het project en wordt bij aanvang van een fase opgesteld. Wanneer dit nodig blijkt, wordt de globale planning van een project aangepast aan het voortschrijdend inzicht dat vaak ontstaat bij het opstellen van een stageplan. Tevens kan er ook nog een exceptionplan worden gebruikt. Dit plan zal gebruikt gaan worden wanneer de oorspronkelijke planning buiten de toleranties dreigt te lopen. Het aantal plannen en de mate van detaillering hangt in veel gevallen af van de omvang van het project. Plannen zullen moeten worden goedgekeurd door de stuurgroep en moeten voldoende informatie bevatten voor de rapportage aan de stuurgroep. Dit betreft niet alleen voortgangsinformatie, maar ook kwaliteitseisen, veronderstellingen, voorwaarden, etc.

17


Controls Het onderdeel controls zorgt voor het nemen van beslissingen binnen een project en de beheersing van een project. Het doel van controls is het geven van een waarborg dat het project de juiste eindproducten oplevert tegen de juiste kwaliteitseisen, wordt uitgevoerd binnen de beschikbare tijd en het beschikbare budget en blijft voldoen aan de businesscase. Deze component zorgt ervoor dat iedere laag binnen de projectorganisatie: V de voortgang kan bewaken; V uitkomsten kan vergelijken met de planning; V planningen en alternatieven kan afwegen, rekening houdend met voortschrijdend inzicht; V problemen kan detecteren; V correctieve acties kan initiëren; V verdere werkzaamheden kan toebedelen. Na het monitoren en detecteren zal de planning moeten worden aangepast aan de nieuwe situatie. Er zijn twee soorten controls binnen Prince2, namelijk ‘event driven’ en ‘time driven’. Eerstgenoemde controls worden uitgevoerd bij een bepaalde gebeurtenis, bijvoorbeeld bij het afsluiten van een fase of het zich voordoen van een uitzondering (management by exception). Laatstgenoemde controls worden op een vast tijdstip uitgevoerd, zoals een wekelijkse voortgangsrapportage. Er zijn vele verschillende controls beschikbaar binnen Prince2, zoals toleranties, rapportages, changecontrol (veranderingsbeheer) en checkpoints. Deze kunnen worden gebruikt binnen alle processen en fasen van een project. Management of Risk De component risicobeheersing (management of risk) bevat handvatten voor de beheersing van de risico’s van het project. Zoals vermeld in dit hoofdstuk zijn er veel risico’s aan een project verbonden en deze zullen op enige wijze moeten worden beheerst. Hierdoor kan er beter worden geanticipeerd op bedreigingen. Voor het beheersen van risico’s is het volgende nodig: V toegang tot betrouwbare, recente informatie over projectrisico’s; V risicoanalysemethoden voor de definitie van risico’s; V processen voor het monitoren van risico’s; V processen voor het nemen van beslissingen naar aanleiding van de vastgestelde en opgetreden bedreigingen. Risicomanagement moet ervoor zorgen dat het aantal ongewenste uitkomsten binnen een project tot het minimum beperkt blijft. Dit is zowel een taak voor de stuurgroep (‘project board’) als de projectmanager. Zij zullen beiden afwegingen moeten maken over het te tolereren risico.

18


Aan ieder risico wordt een eigenaar verbonden die de bedreiging monitort en actie onderneemt wanneer de bedreiging optreedt. Gedurende de verschillende fasen van het project zal er een rapportage moeten plaatsvinden met betrekking tot bedreigingen. Risico’s zijn opgenomen in de risicolog, een overzicht van de belangrijkste risico’s voor een project. Hierbij is eveneens de kans van optreden en de impact van de bedreiging vermeld. Gedurende het project wordt de risicolog diverse keren aangepast aan de actue le situatie. Zo zullen tijdens de overgang naar een nieuwe fase in het project de risico’s opnieuw worden geanalyseerd, waarna de risicolog wordt aangepast. Echter, niet alleen de component risicobeheersing zorgt voor de beheersing van risico’s van projecten. Ook de andere componenten en processen kunnen hiervoor worden gebruikt. Deze component is echter de bindende factor. Quality Kwaliteit wordt volgens de ISO-standaard als volgt gedefinieerd: ‘total of characteristics of an entity which bears on its ability to satisfy stated and implied needs’ (ISO/ IEC, 2001). Voordat een (tussen)product van een project officieel wordt opgeleverd, zal dit moeten voldoen aan een bepaalde kwaliteit. Tijdens een project worden kwaliteitseisen opgesteld, die onder andere zijn gespecificeerd in de businesscase en de zogenaamde product descriptions (een beschrijving van een op te leveren product inclusief eisen). Een product is pas gereed wanneer het aan deze eisen voldoet. Op deze manier wordt voorkomen dat producten niet aan de verwachtingen van belanghebbenden, de business- of projectmedewerkers voldoen. Om dit geheel te beheersen maakt Prince2 gebruik van kwaliteitsbeheersing. Vaak zal dit zijn aan de hand van een bestaand kwaliteitssysteem dat binnen de organisatie gangbaar is. Een dergelijk kwaliteitssysteem bevat procedures en standaarden waarmee de kwaliteit wordt bereikt en gemeten. Hierbij kan worden gedacht aan vaste documentstructuren en checklisten. Standaarden kunnen eigen interne standaarden zijn, maar ook externe standaarden en normen zoals de ISO-standaarden. Een kwaliteitssysteem is dus veelal de ‘omgeving’ die het mogelijk maakt om kwaliteit te garanderen. Om na te gaan of de werkzaamheden daadwerkelijk worden uitgevoerd volgens het kwaliteitssysteem, wordt gebruikgemaakt van quality-assurance (QA). Deze rol wordt in de meeste gevallen vervuld door een externe partij, aangezien hiermee de onpartijdigheid en onafhankelijkheid wordt gewaarborgd. Naast een controlerende rol heeft de QA ook een adviserende rol. Ten slotte is er het onderdeel kwaliteitsplanning. Dit onderdeel beschrijft de kwaliteitseisen van het project en de activiteiten die benodigd zijn om deze eisen te realiseren, inclusief de middelen die hiervoor moeten worden gebruikt. Deze eisen worden met name bepaald door de opdrachtgever en eventuele leveranciers. Wanneer de eisen officieel zijn bevestigd, zullen deze in principe niet meer wijzigen.

19


Eisen kunnen op verschillende gebieden worden opgesteld, zoals beveiliging, flexibiliteit, kosten, betrouwbaarheid en performance. Deze eisen kunnen zijn afgeleid uit de standaarden van het kwaliteitssysteem, maar kunnen ook aanvullend zijn, of opgelegd door de externe omgeving. Wanneer wordt geconstateerd dat wordt afgeweken van de eisen, spreekt men van een issue. Dit issue wordt gerapporteerd aan de projectleider, die actie dient te ondernemen. Indien het issue een grote impact heeft op het project, dan zal het issue met de stuurgroep en opdrachtgever worden besproken. Naast issues met betrekking tot kwaliteit, zijn er nog allerlei andere projectissues. Deze worden verder beschreven bij de component veranderingsbeheer (‘change control’). Een techniek om ervoor te zorgen dat de kwaliteitseisen worden bereikt en om te controleren of dit daadwerkelijk het geval is, is Quality Review. Dit wordt hieronder verder beschreven. Configuration Management Tijdens een project worden vaak zeer veel verschillende (tussen)producten opgeleverd, die allen onderdeel zijn van het uiteindelijke product van het project. Om goed inzicht te krijgen in deze producten kan gebruik worden gemaakt van configuratiemanagement (‘configuration management’). Deze component wordt gebruikt voor: V het beheersen van informatie over producten (versies, status, verantwoordelijke, actiehouders); V het beheersen van toegang tot producten om ongeautoriseerde toegang en wijzigingen te voorkomen; V het controleren of de informatie van een product een daadwerkelijke weergave van de werkelijkheid is. De werkzaamheden voor configuratiemanagement worden vaak uitgevoerd door een speciaal hiervoor aangestelde persoon. Deze zal naast bovengenoemde taken vaak ook een systeem moeten opzetten voor configuratiemanagement, zoals een eventuele database, wijze van versienummering, etc. Ook het opslaan van alle documentatie behoort tot zijn taken. Een van de meest uitgebreide taken is echter het opstellen van een overzicht van alle relaties tussen producten. Wanneer een product dan wordt aangepast, kan direct inzichtelijk worden gemaakt op welke producten en bijbehorende informatie en documentatie de wijziging nog meer invloed heeft. Change Control Veranderingen in een project kunnen funest zijn voor de uitkomst van een project. In de praktijk zijn veel voorbeelden van projecten te vinden die door veranderingen in bijvoorbeeld de scope uiteindelijk niet zijn geslaagd. Het is echter onmogelijk om te zeggen dat er geen enkele verandering tijdens de uitvoering van een project mag plaatsvinden. Het is echter van belang deze veranderingen op een beheerste wijze uit te voeren. Hierbij kan gebruik worden gemaakt van veranderingsbeheer (‘change control’).

20


Veranderingsbeheer maakt gebruik van projectissues. Alle veranderingen binnen een project worden gezien als een issue. Dit betreft niet alleen veranderingen in producten van een project (een scope, een PID, etc.), maar ook bijvoorbeeld: V een verandering in eisen; V een verandering in de omgeving van een product (strategiewijziging, nieuwe leverancier, andere projectorganisatie); V een verandering in projectrisico’s of het optreden van een projectrisico; V een probleem tijdens de uitvoering van een activiteit waardoor een andere werkwijze moet worden gehanteerd. Deze projectissues kunnen door iedereen in een project of door externe partijen worden opgeworpen. Het issue zal worden vastgelegd in de zogenaamde issuelog. Het issue zal worden voorgelegd aan de persoon of instantie die bij het opstellen van de projectorganisatie is geautoriseerd om veranderingen te accepteren. In veel gevallen is dit de stuurgroep van het project, aangezien deze zich bij aanvang van het project aan het project heeft gecommitteerd. Uiteraard zullen bij deze afweging de kosten en doorlooptijd worden afgewogen tegen de noodzaak en het voordeel van de verandering. Als er goedkeuring wordt gegeven om de verandering uit te voeren, zal vervolgens het issue worden geanalyseerd en de te ondernemen activiteiten onderkend. Deze activiteiten zullen door de projectgroep worden uitgevoerd. Indien een verandering zich binnen de toleranties van het project bevindt, zal een projectleider het issue niet aan de stuurgroep hoeven te melden, maar kan hij zelf uit te voeren activiteiten initiëren. Technieken Ten slotte omvat de Prince2-methode enkele technieken voor de beheersing van projecten. Deze technieken kunnen worden gebruikt voor de ondersteuning van bovengenoemde componenten. Dat wil zeggen dat bijvoorbeeld voor de component ‘planning’ de techniek ‘product-basedplanning’ kan worden gebruikt. In deze paragraaf zullen deze technieken worden beschreven. Er dient opgemerkt te worden dat de behandelde technieken worden voorgeschreven door Prince2. Het is echter geen voorwaarde, dat wil zeggen dat componenten ook door andere technieken kunnen worden ondersteund, zoals bijvoorbeeld organisatiespecifieke componenten. Deze zullen hier echter niet behandeld worden. Product-based planning Bij ieder project zijn planningen een basis voor het effectief uitvoeren en beheersen van een project. Deze zorgen ervoor dat een projectmanager de voortgang van het project eenvoudig kan bewaken. Prince2 maakt gebruik van de methode ‘Productbased planning’. Hierbij worden de door het project op te leveren (tussen)producten als basis gebruikt voor de planning van een project. Deze op te leveren (tussen)producten worden ook wel mijlpalen genoemd. Door de producten als basis van een planning te nemen, wordt het eenvoudig de oplevering van de producten te managen, waarbij eveneens de vooraf afgesproken kwaliteit van de producten kan worden gecontroleerd. Tevens zorgt een gedetailleerd overzicht van alle op te leveren producten voor een

21


duidelijker en gemeenschappelijker beeld van het eindproduct bij de projectmedewerkers. Een product-basedplanning bestaat uit drie verschillende onderdelen, namelijk: V product breakdown structure (PBS); V product descriptions (PD); V product flow diagram (PFD). Een PBS beschrijft de samenhang tussen alle op te leveren (tussen)producten van een project. Dit is weergegeven in een hiërarchisch overzicht. Uitgangspunt is het eindresultaat van het project. Dit eindresultaat is weer onderverdeeld in onderliggende producten, die wederom zelf weer onderverdeeld kunnen zijn. Deze onderverdeling kan worden doorgevoerd tot het gewenste niveau van detaillering. Deze kan voor verschillende projectmedewerkers verschillend zijn. Een projectmanager zal veelal willen sturen op globale producten, een teamleider op gedetailleerde producten. Deze decompositie van het eindresultaat in onderliggende producten bestaat uit verschillende soorten producten, namelijk specialist products en management products. Specialist products zijn de daadwerkelijke (tussen)producten die worden opgeleverd door het project aan de organisatie. Dit kunnen zowel interne als externe producten zijn. Denk hierbij bijvoorbeeld aan de levering van hardware voor een project. Hoewel dit een tussenproduct van het project is, zal dit voornamelijk worden gerealiseerd door externe partijen. Management products zijn speciaal bedoeld voor het projectmanagement, zoals bijvoorbeeld een voortgangsrapportage. Het is van groot belang ook deze producten in de planning op te nemen om ervoor te zorgen dat deze onderdelen ook daadwerkelijk worden opgeleverd. Aan de producten in een PBS kunnen in de planning vervolgens data voor de oplevering worden opgenomen, die als direct stuurmiddel voor het projectmanagement gelden. Een PD is een verdere definitie van de in het PBS genoemde producten. Hierin worden onder andere de productnaam, het identificatienummer, het uiterlijk, de verantwoordelijke voor oplevering en de kwaliteitscriteria van een product vermeld. Behalve deze zaken schrijft Prince2 nog meer onderdelen voor in de PD. Een PD is dan ook vaak de basis voor configuratiemanagement. Een goede PD zorgt ervoor dat er een gezamenlijk beeld ontstaat over het product. Ten slotte geeft een PFD de logische volgorde van de oplevering van de gedefinieerde producten weer in een diagram. Hierbij is de samenhang tussen de producten weergegeven in de loop van de tijd. In het begin van de PFD staan de eerste producten vermeld en het eindproduct staat als laatste vermeld. In deze PFD kunnen daarom goed de fasen van een project worden vermeld. Wanneer er al data gekoppeld zijn aan de oplevering van producten, kan niet alleen de logische volgorde worden aangegeven in het overzicht, maar ook de daadwerkelijke opleverdata van de producten.

22


Voor de oplevering van een product zijn bepaalde activiteiten noodzakelijk. Wanneer deze zijn gedefinieerd, kunnen zij ook worden opgenomen in een PFD. Hierdoor ontstaat een groot netwerkoverzicht van alle producten, activiteiten en hun onderlinge samenhang. Vaak wordt hiervoor een Gantt-chart gebruikt. Change control approach De aanpak voor veranderingsbeheer (‘change control approach’) is een ‘techniek’ die de werkwijze weergeeft die gevolgd moet worden in het kader van veranderingsbeheer. Uiteraard kan een organisatie een eigen werkwijze hebben. Zoals al beschreven bij de component veranderingsbeheer, zal een issue worden opgenomen in de issuelog. Na de analyse van het issue wordt er een prioriteit toegekend. Indien de verandering zich binnen de toleranties van het project bevindt, kan de projectleider zelf toestemming geven voor het issue, en de vervolgactiviteiten in gang zetten. Zo niet, dan zal het issue worden geëscaleerd naar de stuurgroep via een rapportage. Wanneer goedkeuring wordt gegeven aan de verandering, zal er een nieuwe planning moeten worden opgesteld (exceptionplan), waaraan eveneens goedkeuring wordt gegeven door de stuurgroep. Deze planning zal vervolgens worden uitgevoerd om de verandering te implementeren. Quality review Een kwaliteitsreview is een gestructureerde techniek om te beoordelen of een bepaald product van het project voldoet aan de hiervoor gestelde kwaliteitseisen. De kwaliteitsreview bestaat globaal uit de volgende stappen: V De voorbereiding van de review Tijdens deze stap wordt het te analyseren product gedefinieerd, worden de personen die het product moeten beoordelen ingelicht, worden de kwaliteitseisen vastgelegd en wordt het product verspreid onder de beoordelaars. V Het uitvoeren van de review Vervolgens zullen de beoordelaars het product reviewen tegen de hiervoor geldende kwaliteitseisen. Alle afwijkingen en eventuele vragen zullen worden genoteerd. Deze worden in de volgende fase besproken. Alle opmerkingen worden centraal verzameld, waarna een plan voor de meeting wordt opgesteld. V Een meeting naar aanleiding van de review Tijdens de meeting zullen alle punten van de beoordelaars worden besproken. Na een discussie zullen relevante punten vastgelegd moeten worden. Voor de afwijkingen zullen acties worden opgesteld om de kwaliteit te verbeteren. Als er geen afwijkingen zijn geconstateerd, zal de review officieel worden afgesloten. V Een follow-up van de beoordeling Indien afwijkingen van de kwaliteitseisen zijn geconstateerd, zullen er acties uitgevoerd moeten worden om de kwaliteit te verbeteren. Na het uitvoeren van deze acties zal wederom gecontroleerd moeten worden of het product nu wel voldoet aan de eisen. Wanneer tijdens deze follow-up blijkt dat dit inderdaad het geval is, zal het product officieel worden goedgekeurd. Wanneer het product nog steeds niet voldoet, zullen opnieuw acties moeten worden gedefinieerd en uitgevoerd.

23


Tijdens de uitvoering van een kwaliteitsreview zijn er verschillende rollen aanwezig. Dit betreft onder andere: V een voorzitter van de review, verantwoordelijk voor de goede organisatie van de review, het voorzitten van de meeting, het tijdig informeren van de projectmanager en het officieel goedkeuren van de review; V de verantwoordelijke van het product, die alle leden van de review moet voorzien van informatie, alle vragen van de beoordelaars moet beantwoorden, gedefinieerde acties moet goedkeuren en moet toezien op de uitvoering van deze acties; V de beoordelaars, die de daadwerkelijke review uitvoeren; V de secretaris, die de voorzitter ondersteunt, aantekeningen maakt tijdens de meeting en notulen hiervan verspreidt. Uiteraard zijn er ook raakvlakken met andere onderdelen van het project, zoals de projectmanager die de kwaliteitsreviews plant en de QA-rol, die de kwaliteit van de kwaliteitsreview controleert (zoals de kwaliteit van de reviewers en het naleven van de procedures van de review). Opdracht 1.2 U bent projectmanager van het project bij RaamOK. a De stuurgroep vraagt u een projectstructuur te definiëren waarin u de risico’s van de eerste opdracht adresseert. b Onderken de verschillende projecten waarvoor u een PID zou willen uitwerken. c Werk voor één project het PID uit.

1.3

Programmamanagement

1.3.1

Inleiding

In een eerdere paragraaf is beschreven hoe projectmanagement is gericht op met name realisatie van activiteiten en deliverables binnen vooraf vastgestelde grenzen van tijd, geld en kwaliteit. Inmiddels wordt bij veel organisaties onderkend dat dit op zich niet voldoende is om effectief en efficiënt veranderingen te realiseren. Een populair argument hiervoor is de toenemende dynamiek rondom organisaties waardoor de behoefte aan verandering steeds grotere en complexere vormen aanneemt. Informatietechnologie vormt een driver voor deze trend. Organisaties zetten gemiddeld genomen steeds grotere investeringen in om veranderingen te realiseren. De term die in het algemeen verbonden wordt aan de realisatie van grote veranderingen en het beheren van de benodigde investeringen is programmamanagement. In vergelijking met de inrichting van projectmanagement, verschilt de invulling van programmamanagement per organisatie en zijn best practices voor deelaspecten ervan nauwelijks herkenbaar of nog sterk in beweging (KPMG, 2004). Hieronder wordt op basis van huidige trends getracht een kader te schetsen van programmarisicomanagement.

24

IT-auditing en de praktijk

Recommend Documents