Soorten Projectaudits

5314 -

Informatiesystemen

Soorten Projectaudits drs. P.A. Hartog CIA

Dit hoofdstuk geeft een overzicht van de diverse soorten projectaudits die een auditor zou kunnen uitvoeren. In paragraaf 1 wordt een korte inleiding gegeven. In paragraaf 2 wordt kort beschreven wat onder projectauditing wordt verstaan en wordt de context van deze audits geschetst. In paragraaf 3 wordt een overzicht gegeven van mogelijke (soorten) projectaudits. In paragraaf 4 wordt vervolgens nader ingegaan op de selectie van relevante projecten. Vervolgens worden de soorten projectaudits nader uitgewerkt. In paragraaf 5 wordt de audit van het projectmanagement beschreven, terwijl in paragraaf 6 wordt ingegaan op audits van diverse mijlpaalproducten. In de bijlagen is een tweetal normenkaders nader uitgewerkt. Aan het slot is een literatuuropgave opgenomen. Dit hoofdstuk wordt specifiek aanbevolen voor (IT-)auditors. De Redactie

1.

Inleiding

Projecten en (veranderings)programma’s worden steeds meer een normaal object van auditing. Wel bestaat er in de praktijk een grote diversiteit aan projectaudits en de rol die auditors daarin spelen. Zodoende wordt in het Handboek EDP-auditing in dit hoofdstuk aandacht besteed aan de volgende centrale vraag: Welke soorten projectaudits kunnen worden onderkend en welke audit, met welke scope is in welke situatie het meest zinvol? Dit hoofdstuk geeft een overzicht en zal in een later stadium mogelijk worden aangevuld met vervolg hoofdstukken die dieper zullen ingaan op de diverse aspecten van projectauditing of soorten audits. Dit hoofdstuk beoogt dus een overview te geven van de diverse soorten projectaudits die een auditor zou kunnen uitvoeren alsmede handvatten te bieden om voor een bepaald project de meest relevante projectaudit(s) te kunnen benoemen. Hierbij wordt opgemerkt dat bij projecten niet alleen aan pure ICT-projecten moet worden gedacht, maar ook aan bredere organisatieveranderingen. Deze hebben vrijwel altijd ook een belangrijke ICT-component in zich. Omgekeerd leiden belangrijke ICT-projecten veelal ook tot substantie¨le organisatieveranderingen en gaat het daarbij niet alleen om de ontwerpen realisatiefase, maar ook om de implementatie van de geautomatiseerde systemen. In paragraaf 2 wordt kort beschreven wat onder projectauditing wordt verstaan en wordt de

afl. 43 (juni 2012)

5314-1

context van deze audits geschetst. Omdat de´ projectaudit niet bestaat, wordt in paragraaf 3 eerst een overview gegeven van mogelijke (soorten) projectaudits. In paragraaf 4 wordt vervolgens nader ingegaan op de vraag bij welke projectomstandigheden projectauditing relevant is. Daarna worden de soorten projectaudits nader uitgewerkt. In paragraaf 5 wordt de audit van het projectmanagement beschreven, terwijl in paragraaf 6 wordt ingegaan op audits van diverse mijlpaalproducten en de vraag hoe te bepalen welke van de vele mijlpaalproducten zinvol zijn om te auditen.

2.

Projectauditing?

2.1

Wat is projectauditing

Projectauditing wordt in dit hoofdstuk gedefinieerd als een onafhankelijke toets van de beheersing en/of resultaten van het project, met als doel extra zekerheid te krijgen over de realisatie van de doelstellingen van het project. Dit gebeurt in aanvulling op de reguliere beheermechanismen in het project, zoals het gebruik van standaarden, voortgangsrapportages en de reviews en acceptaties binnen het project. Ten opzichte van de waaier van mogelijke rollen die in hoofdstuk 5313 ‘Rol(len) van de (IT-)auditor in projecten’ door Sam Huibers is beschreven, betreft dit de assurancerol (d.w.z. het geven van aanvullende zekerheid aan de opdrachtgever) en dus niet de adviesrol. Daarbij geldt dat projectauditing in dit hoofdstuk wordt gedefinieerd als een in de tijd begrensd onderzoek resulterend in een rapportage met een conclusie. In de praktijk ziet men ook regelmatig auditors die een min of meer permanente klankbordrol vervullen door het project continu te volgen, door gedurende het project de rapportages te ontvangen en projectoverleggen bij te wonen. Deze invulling wordt in dit hoofdstuk buiten beschouwing gelaten. Auditing kent altijd drie partijen: de opdrachtgever, de auditee (degene die verantwoordelijk is voor object van onderzoek) en de auditor. Toegepast op projectauditing is de Raad van Bestuur dan wel de directie of de stuurgroep van het project over het algemeen de opdrachtgever, terwijl de projectleider de auditee is. Hierbij wordt opgemerkt dat in dit hoofdstuk wordt gesproken over de activiteit projectauditing in plaats van de organisatorische (externe of interne) functie audit. De projectaudits kunnen aldus door diverse (van het project onafhankelijke) functionarissen worden uitgevoerd. Overeenkomstig Prince2 is in veel projecten een Project- of Quality Assurance-functie (QA) aanwezig. Ook de QA voert, in dat geval in opdracht van de stuurgroep, projectaudits uit. Vanzelfsprekend is het niet de bedoeling dat meerdere functionarissen in eéń project dezelfde audits uitvoeren. Indien overlap in werkzaamheden dreigt, bijvoorbeeld doordat de Interne Audit Dienst (IAD) de opdracht heeft een project te auditen en ook de QA projectaudits uitvoert, dienen vooraf zodanige afspraken te worden gemaakt dat de IAD zich zoveel mogelijk kan baseren op de door QA uitgevoerde werkzaamheden.1 Nadrukkelijk wordt opgemerkt dat een projectaudit niet alleen een instrument is voor opdrachtgevers, maar ook voor projectleiders. Audits worden in dit kader niet zozeer gezien als instrument

afl. 43 (juni 2012)

5314-2

om de projectleider te controleren of als een ‘afrekenmechanisme’, maar als verbeterinstrument voor alle bij het project betrokkenen, inclusief de stuurgroep.

2.2

Waarom projectauditing?

Het is gebruikelijk dat in de opzet en uitvoering van de projecten al veel wordt gedaan om te zorgen dat het project goed zal verlopen, zowel preventief (zoals het gebruik van standaarden en templates) als detectief in de vorm van reviews en acceptaties. De vraag is dan al snel of dit niet voldoende is en of dus een projectaudit niet overbodig is. Gezien de praktijk luidt het antwoord nee, vaak niet, omdat niet altijd de getroffen maatregelen adequaat zijn of naar behoren werken. Helaas is het moeilijk vooraf te voorspellen welke projecten wel en welke niet goed zullen verlopen. Dat is reden om voor risicovolle projecten extra zekerheid te willen. Projecten kunnen risicovol zijn hetzij vanwege de kans dat het niet goed zal gaan, hetzij vanwege de consequenties als dat het geval zou zijn. In die situaties kan een investering in projectauditing gezien worden als een verzekeringspremie. Overigens betekent ‘extra zekerheid’ niet dat de projectauditor dezelfde reviews e.d. nogmaals doet, maar meer dat deze de effectiviteit daarvan beoordeelt. Ten aanzien van de grootte van het risico geldt het volgende. Organisaties kiezen er voor om sommige activiteiten als project uit te voeren, omdat zij inschatten dat het realiseren van bepaalde veranderingen alleen lukt met de specifieke vorm van beheersing die projectmanagement biedt. Zeker als het om grote projecten gaat, betreffen dit vaak veranderingen die van strategisch belang zijn en waar veel geld en energie in wordt gestoken. Juist vanwege de omvang en de complexiteit van de veranderingen (bijvoorbeeld in termen van betrokken organisatorische eenheden, processen, applicaties en ICT-infrastructuur) en vanwege het feit dat er veelal (ook) een gedragsverandering nodig is, zijn de risico’s waaraan een dergelijk project is blootgesteld groot. Dit geldt des te meer, omdat voor veel organisaties geldt dat er relatief weinig ervaring is met het werken in grote projecten. Zodoende zijn grote dan wel voor de organisatie belangrijke projecten een interessant object van auditing. Het besluit tot een projectaudit is daarom geen motie van wantrouwen of signaal dat de projectleider zijn werk niet goed doet. Het is slechts een extra waarborg vanwege het belang van het project voor de realisatie van de bedrijfsdoelstellingen.

2.3

Projecten versus programma’s

Hoewel in dit hoofdstuk steeds wordt gesproken over projecten en projectauditing, is veel ook toepasbaar voor programma’s en het auditen daarvan. Er is soms wat verwarring over de vraag wat er nu eigenlijk onder een project en een programma moet worden verstaan. De definities daarvan zijn niet altijd eenduidig. In dit hoofdstuk wordt onder een project verstaan: een geheel van activiteiten om in een tijdelijke organisatie, binnen gestelde condities, een vooraf gedefinieerd resultaat te bereiken2. Onder een programma wordt in lijn met MSP verstaan: het geheel van samenhangende projecten en activiteiten in een tijdelijke organisatie om eéń of meer van tevoren gedefinieerde doelstellingen te realiseren, die van strategisch belang zijn. Dit betekent dat een programma veelal een multi-projecten aanpak zal zijn en ook dat er sprake is van een verbijzonderde programmaorganisatie. Ten opzichte van projecten zijn in een programma echter nog aanvullende beheersingsvraagstukken aanwezig, zoals het stakeholdermanagement en benefit management. In het vervolg zal ten behoeve van de leesbaarheid worden gesproken over projecten en projectmanagement waarmee ook programma’s en programmamanagement worden bedoeld. Op een

afl. 43 (juni 2012)

5314-3

aantal plaatsen waar sprake is van belangrijke verschillen tussen projecten en programma’s, zal dat nader worden benoemd.

3.

Overzicht soorten audits

In lijn met de toename van projectmatig werken en het (strategisch) belang van projecten, worden steeds vaker projectaudits uitgevoerd. In de praktijk kennen deze een grote diversiteit. Globaal zijn er twee soorten projectaudits: _ Audit op het projectmanagement (PM), ofwel van (de inrichting en beheersing van) het project als geheel. Deze audit is prospectief van aard. Dit is niet zozeer een beoordeling van de projectmanager, maar van het ‘systeem’ ofwel de maatregelen die zijn getroffen om te waarborgen dat het project succesvol zal zijn. Natuurlijk is dat wel hetgeen waarvoor de projectmanager in belangrijke mate verantwoordelijk is. Belangrijk onderdeel van die maatregelen, als het gaat om IT-projecten, is de keuze en uitvoering van de juiste systeemontwikkelingsmethode voor de ontwikkeling van de ICT-systemen. _ Audits op deliverables (ofwel op onderdelen van het project, zijnde specifieke activiteiten of mijlpaalproducten). Deze zijn nader onder te verdelen in audits op: a. Specialistische3 of ‘inhoudelijke’ producten (de deelproducten van het uiteindelijk door het project op te leveren resultaat). Deze zijn te bepalen op basis van de product breakdown structure in het projectplan of het fasen/stromen-model4, indien dat wordt gehanteerd. De auditor beoordeelt dan bijvoorbeeld het testplan of de kwaliteit van de beheersmaatregelen in de processen en ICT-systemen ter waarborging van de betrouwbaarheid van de data. b. Managementproducten (de producten die de sturing en beheersing van het project betreffen, zoals het projectplan en een voortgangsrapportage). Deze zijn te bepalen op basis van de projectmanagementmethode (zoals Prince2, PMBOK of Projectmatig Cree¨ren). De audits op de deliverables kennen diverse uitvoeringen. Een belangrijk onderscheid daarbij is het volgende: _ systeemaudits waarbij prospectief wordt gekeken of voldoende waarborgen bestaan, zodat redelijke zekerheid bestaat dat het goed zal gaan. Er wordt dan met andere woorden niet achteraf naar het resultaat of product zelf gekeken, maar vooraf naar de geplande wijze van (beheersing van de) totstandkoming daarvan. Welke wijze van (beheersing van de) totstandkoming adequaat is, is afhankelijk van de context van het project en de op te leveren eindproducten (zoals de aard van de IT-systemen); _ performance- of product-audits, waarbij het doel is om retrospectief (achteraf) een oordeel te geven of het betreffende object voldoet aan de eisen. Bij de performance-audit op een bepaald mijlpaalproduct kan vervolgens in het werkprogramma worden gekozen om het product zelf te beoordelen dan wel het proces dat tot het product heeft geleid. Beoordeling van het product zelf door de auditor geeft meer zekerheid, maar kost over het algemeen meer. Daarbij kan de productbeoordeling pas na afronding van het product) worden uitgevoerd, terwijl een beoordeling van het proces vaak ook iets eerder kan plaatsvinden (ervan uitgaande dat het proces in het laatste stuk

afl. 43 (juni 2012)

5314-4

van oplevering niet substantieel zal wijzigen). Als de oplevering van het product op het kritieke pad van het project ligt, zou dat kunnen betekenen dat de audit het project vertraagd. Vraag is dan, alle risico’s afwegende, of niet voldoende zekerheid kan worden verkregen door middel van een beoordeling van hoe het proces verloopt (of is verlopen), inclusief de daarin opgenomen reviews. Dat zou dan zelfs op een zodanig moment kunnen plaatsvinden dat nog tijdig kan worden gecorrigeerd indien blijkt dat niet alles naar wens verloopt. Kortom, productaudits bieden de meeste zekerheid achteraf. Als het doel echter is om met de projectaudits toegevoegde waarde te leveren als verbeterinstrument voor het onderhanden project, pleit dat er voor om een (prospectieve) PM-audit uit te voeren. In het management (ofwel de inrichting en de beheersing inclusief de systeemontwikkelingsmethode van het IT-systeem) van het project ligt immers de basis voor het succes van het project en voor het adequaat opleveren van de gewenste deliverables. Hieraan kunnen audits op deliverables worden toegevoegd, tot een audit framework voor het project. Of dat nodig is, is afhankelijk van de risico’s en andere getroffen beheersmaatregelen. Door middel van de PM-audit wordt proactief in een vroeg stadium beoordeeld of het goed zal gaan, met als doel om op het moment dat het nog mogelijk is, indien nodig, op tijd bij te sturen. Dit in tegenstelling tot de beoordeling of het goed is gegaan, zoals bij de audits op deliverables veelal het geval is. Ook audits van deliverables kunnen proactief worden uitgevoerd, bijvoorbeeld door te stellen dat zij niet op het kritieke pad van het project mogen liggen. Dat kan door of het totstandkomingproces te beoordelen of bijvoorbeeld een 80%-versie te bekijken.

4.

Selectie relevante projecten

Benadrukt wordt dat niet elk project behoeft te worden ge-audit. Wel wordt ervoor gepleit om al bij de start van het project te bepalen of en welke projectaudits zinvol zijn en niet te wachten tot er problemen zijn. Op die manier worden de audits ook ingezet als verbeterinstrument en wordt de kans dat de audit als politiek instrument wordt ingezet, verminderd. Om te voorkomen dat projecten (en daarmee de organisatie) onnodig zwaar worden belast met projectaudits, kan gebruik worden gemaakt van een risicoanalyse waarmee niet alleen wordt vastgesteld of een audit wel nodig is, maar, bij bevestiging daarvan, ook wat de aard (qua reikwijdte en diepgang) daarvan moet zijn. Dit resulteert in een classificatie van projecten, waarmee de aard van de audits wordt afgestemd op het belang en risico van een project en de totale projectportefeuille. In de uitvoering van de risicoanalyse en het adviseren van de opdrachtgever welke projecten te auditen, zal, indien aanwezig, ook het projectbureau of portfoliomanagement een belangrijke rol spelen. Daar behoort men immers inzicht te hebben in de totaliteit van projecten. De wijze waarop deze risicoanalyse verloopt, is vergelijkbaar met de risicoanalyse die veel auditfuncties in het kader van de jaarplanning uitvoeren, waarbij de audituniverse wordt verdeeld in mogelijke auditobjecten, die vervolgens worden gee¨valueerd op hun belang en risico’s. Daarbij kan een expliciet onderscheid worden gemaakt tussen kans en impact:

afl. 43 (juni 2012)

5314-5

_

_

de kans dat het object van onderzoek niet goed zal worden beheerst of uitgevoerd en in het verlengde daarvan zijn doelen niet realiseert; de impact die dat heeft.

De audituniverse bestaat in dit geval uit het geheel van projecten, waarbij voor elk project de kans dat het project faalt en de impact daarvan in kaart worden gebracht. Bij het in kaart brengen van de kans kan worden gedacht aan: _ de omvang van het project in termen van de investeringskosten, het aantal (externe) projectmedewerkers of het aantal betrokken afdelingen; _ de complexiteit van het project, in termen van het op te leveren resultaat, zoals de technische complexiteit van het te ontwikkelen IT-systeem en de invloed op andere systemen, maar ook de mate waarin het projectresultaat leidt tot veranderingen voor de medewerkers van de organisatie (en de daartoe vereiste change management aspecten); _ de mate van afhankelijkheden van andere projecten of externe partijen. Bij het in kaart brengen van de impact kan worden gedacht aan: _ de invloed van het project op de realisatie van de strategische doelstellingen van de organisatie of op de naleving van wet- en regelgeving; om deze invloed te bepalen kan gebruik worden gemaakt van de business case waarin de doelen van het project zijn beschreven; _ de omvang van het projectbudget; _ het mogelijke effect op de reputatie van de organisatie. Daarnaast kunnen specifieke projectrisico’s het wenselijk maken om in de audit aan specifieke aspecten aandacht te besteden. Hierbij kan bijvoorbeeld worden gedacht aan risico’s die samenhangen met outsourcing (zoals de contractafspraken) of het risico van het verlies van voor de organisatie essentie¨le projecten materiekennis in een project dat voornamelijk wordt bezet door externe medewerkers. Een bijzonder aandachtspunt bij deze risicoanalyse is de mate of impact van de verandering die het project met zich meebrengt. Projecten zijn gericht op het bewerkstelligen van een verandering. Zo kan een verandering gericht zijn op de (inrichting van de) ICT-systemen, de processen en de organisatie. Uiteindelijk heeft elke verandering invloed op de mensen die de nieuwe organisatie moeten effectueren. De invloed van deze veranderingen beı¨nvloedt de mate waarin de medewerkers mee moeten veranderen. Afhankelijk van de impact van de verandering is het veranderingsmanagement (gericht op de acceptatie door de medewerkers en het managen van weerstand) en het auditen hiervan minder of meer belangrijk. Hiervoor kan de volgende indeling worden gehanteerd: _ alleen een wijziging van de knoppen ofwel de bediening van het ICT-systeem; _ een wijziging van functionaliteiten van het systeem en/ of werkwijze die de medewerkers moeten uitvoeren; _ een wijziging in de organisatie en taakverdeling waarvoor nieuwe vaardigheden moeten worden aangeleerd; _ een verandering van de houding waarmee de medewerkers hun werk moeten uitvoeren.

afl. 43 (juni 2012)

5314-6

5.

Audit Projectmanagement

In deze paragraaf wordt nader ingegaan op de audit van het projectmanagement (hierna de PMaudit). In paragraaf 5.1. worden de algemene uitgangspunten beschreven, inclusief het doel, de onderzoeksvraag en het moment van uitvoering. Daarna wordt in paragraaf 5.2 een mogelijke invulling van de PM-audit beschreven aan de hand van de Balanced Change Card (Koster & Bouman, 1997).

5.1

Uitgangspunten van de PM-audit

Het doel van PM-audit is het verkrijgen van extra zekerheid over het succes van het project en/of het project waar nodig daartoe tijdig bij te kunnen sturen. De centrale onderzoeksvraag kan worden omschreven als ‘Is het project voldoende voorbereid, ingericht en uitgerust met de juiste middelen, zodat redelijke zekerheid bestaat over de realisatie van de projectdoelen in de komende periode?’ Ofwel: bestaan er voldoende waarborgen dat het project succesvol zal zijn? Deze vraag is breed van opzet. De auditor dient te kijken naar alle benodigde maatregelen en middelen om het project tot een succes te maken, waarbij het vaak gaat om zowel het opleveren van een adequaat ICT-systeem (system delivery) als de implementatie en acceptatie daarvan (business change). Deze brede optiek gaat verder (omvat meer aspecten) dan de auditvragen die in de praktijk ook vaak onder de noemer van beoordeling van het projectmanagement worden aangeduid, zoals: _ Is het projectplan adequaat? (Waarbij alleen het projectplan wordt beoordeeld, bijvoorbeeld ten opzichte van de criteria die Prince2 stelt aan het PID); _ Is de projectinrichting overeenkomstig het projectplan? _ Wordt onze standaard projectmanagementmethode nageleefd? (Waarbij de norm bestaat uit de in de organisatie geldende standaard). Centraal bij deze vragen staat eigenlijk steeds het ‘product’ Projectplan. Op de beoordeling daarvan, wordt in paragraaf 6.3 nader ingegaan. In deze paragraaf wordt verder ingegaan op de ‘brede optiek’, die kijkt naar de totaliteit van beheersing en middelen; dit omvat ook zaken die veelal niet zijn beschreven in het projectplan. Zoals eerder aangegeven wordt ervoor gepleit de PM-audit in een vroegtijdig stadium van het project uit te voeren. Om zowel de opzet als de werking te kunnen beoordelen, is het van belang dat niet alleen het projectplan is opgeleverd en het project is ingericht, maar dat ook de uitvoering is gestart. Met name voor kleine projecten met een korte doorlooptijd, of projecten waar hoge risico-indicaties zijn, kan worden overwogen de PM-audit al in een eerder stadium uit te voeren, nog voor de feitelijke start aan het einde van de voorbereidings- of initiatiefase. In dat geval wordt met name de opzet van het projectmanagement beoordeeld. Vooral in omvangrijke langdurige projecten kan worden overwogen de PM-audit meer dan eens uit te voeren. Hiervoor bestaan twee mogelijkheden, mede afhankelijk van de gekozen projectmethode en planning: _ met een vaste frequentie, bijvoorbeeld eenmaal per half jaar;

afl. 43 (juni 2012)

5314-7

_

gekoppeld aan de faseovergangen in het project. In dat geval kan worden overwogen om de audit een aanvullende onderzoeksvraag mee te geven. Dan wordt niet alleen gekeken naar de waarborgen voor de komende fase, maar tevens naar de vraag of de afgelopen fase inderdaad kan worden afgesloten (en de projectleider worden gedechargeerd).

Ten aanzien van de wijze van uitvoering en meer specifiek het normenkader geldt het volgende. Er bestaat geen generiek ‘beste’ manier van projectmanagement die passend is voor alle situaties. Net zoals de projectleider de wijze van projectmanagement aanpast aan de specifieke kenmerken van het project, zal ook het normenkader daaraan moeten worden aangepast. Wel is er een aantal uitgangspunten voor de invulling van het normenkader om de toegevoegde waarde te optimaliseren, namelijk: _ Vooraf benoemd; _ Aansluitend bij de veranderstrategie en PM-methode van de organisatie; _ Integraal, alle aspecten omvattend: – harde eń zachte aspecten; – ontwerp eń implementatie; – rol projectleider eń stuurgroep; _ Managerial houding. Bij de invulling van het normenkader kan de auditor goed gebruik maken van het IIA-rapport Projectauditing, Handvatten voor de internal auditor. In dat rapport wordt een groot aantal modellen en instrumenten beschreven die de auditor kan gebruiken voor het uitvoeren van audits op (aspecten van) het projectmanagement. Dit betreffen specifieke PM-methoden (zoals Prince2 en PMBOK), reguliere control modellen (zoals COSO en Simons) en modellen op het gebied van veranderingsmanagement (zoals MOC en De Caluwe´). Daarbij is tevens aangegeven onder welke omstandigheden en op welke momenten het instrument meer of minder bruikbaar is. De genoemde uitgangspunten worden hieronder verder toegelicht. 5.1.1 Normenkader vooraf benoemd Aangezien er geen universele, algemeen geaccepteerde beste manier van projectmanagement is, kunnen verschillen van interpretatie en mening bestaan over ‘hoe het zou moeten’. Zodoende wordt ervoor gepleit het normenkader vooraf te expliciteren en te bespreken met zowel opdrachtgever als auditee (projectleider). Hiermee wordt voorkomen dat er pas achteraf discussie over ontstaat. Mogelijke meningsverschillen komen dan voor de start van het (veldwerk van het) onderzoek al op tafel. Het zou dan zelfs mogelijk kunnen zijn dat in die bespreking wordt geconstateerd dat de feitelijke wijze van projectbeheersing niet overeenkomt met de gewenste situatie en de uitvoering van de audit niet meer nodig is. Het is de opdrachtgever van de audit die formeel het normenkader vaststelt. De auditor heeft daarbij een adviserende rol, net als de projectleider. 5.1.2 Aansluitend bij de veranderstrategie en PM-methode van de organisatie Een andere consequentie van het ontbreken van een algemeen geldig normenkader is dat het normenkader specifiek voor het project moet worden ingevuld. Gewaakt moet worden voor het simpelweg gebruiken van een standaardmodel. Bij de invulling van het normenkader dient te worden aangesloten bij:

afl. 43 (juni 2012)

5314-8

_

_

_ _

de veranderstrategie die wordt gehanteerd (is er bijvoorbeeld sprake van een ontwikkelof expertbenadering?); (indien aanwezig) de door de organisatie als standaard werkwijze gekozen PM-methode. Met name organisaties die frequent project uitvoeren of projectmatig werken, kiezen vaak voor een standaard (bijvoorbeeld Prince2) en spitsen deze ook vaak toe op de eigen organisatie; de gekozen systeemontwikkelingmethode; de grootste risico’s van het project.

5.1.3 Integraal, alle (kritieke) aspecten omvattend Adequate besturing en beheersing van een project is complex; het succes van een project is van vele factoren afhankelijk. Indien de auditor prospectief (redelijke) zekerheid wil kunnen geven over het slagen van een project dient hij naar vele aspecten te kijken. Op basis van de vele gemaakte analyses van de oorzaken van het mislukken van projecten, worden de volgende aspecten als essentieel onderkend: _ Harde eń zachte aspecten Besturing en beheersing omvat enerzijds formele, ‘harde’ aspecten en anderzijds meer informele,‘zachte’ aspecten. De formele beheersing van projecten, in termen van plannen, voortgangsrapportages, taakverdeling, e.d., is in veel PM- en systeemontwikkelingsmethoden uitvoerig beschreven en is ontegenzeggelijk van groot belang. Echter, ook meer informele mechanismen spelen een grote rol bij het al dan niet slagen van projecten. Teveel nadruk op de formele beheersing kan zelfs ongewenste effecten hebben en resulteren in een overdreven bureaucratisch en in die zin onbeheerst project. In de praktijk stranden ook veel projecten op interne conflicten, gebrek aan motivatie en weerstand tegen veranderingen. Deze meer informele of zachte aspecten kunnen grote risicofactoren zijn en dienen daarom een onderdeel te vormen van de projectaudit. _ Ontwerp eń implementatie Veelal is de projectleider niet verantwoordelijk voor de implementatie van de resultaten van het project. Wel bepaalt een juiste implementatie vaak het succes. Dit pleit er voor de beheersing van de implementatie mee te nemen in de PM-audit. Dat behoeft niet altijd even zwaar te zijn. In de voorbereiding van de audit dient de auditor te evalueren wat de impact van de verandering is: is er alleen sprake van een wijziging in de bediening van het systeem, zijn er ook nieuwe functionaliteiten, of is er ook een wijziging van taken, vaardigheden of zelfs attitude? Naarmate de impact groter is, zijn de complexiteit en het risico van weerstanden groter en is het dus belangrijker om deze mee te nemen in de audit. _ Rol projectleider eń stuurgroep De beheersing van een project is niet alleen voorbehouden aan de projectmanager. Ook de stuurgroep, inclusief de opdrachtgeverrol, speelt daarin een essentie¨le rol. Dat geldt bijvoorbeeld sterk voor risico’s als scopecreep en gebrekkige implementatie, zeker als de verantwoordelijkheid daarvoor geen onderdeel is van de verantwoordelijkheden van het project. Juist ook in het functioneren van de stuurgroep liggen vaak oorzaken van problemen. Dit pleit er voor om zaken als de samenstelling, de besluitvaardigheid, getoond sponsorship, e.d. mee te nemen in de PM-audit. Een model waarmee aan al die aspecten aandacht kan worden besteed, is de Balanced Change Card (BCC). De BCC wordt in paragraaf 5.2 nader toegelicht.

afl. 43 (juni 2012)

5314-9

5.1.4 Managerial houding Belangrijk bij de uitvoering van de PM-audit is niet alleen te kijken naar de regels of de concreet benoemde beoordelingscriteria, maar steeds in ogenschouw te houden wat de achterliggende doelstellingen daarvan zijn. Daarbij is het belangrijk de criteria in hun onderlinge samenhang te bezien. Het ontbreken van een verwachte beheersmaatregel, kan mogelijk door andere zaken worden gecompenseerd. Voorbeeld In een audit naar een groot veranderingsproject bleek direct al bij de start dat er slechts een heel summier projectplan (‘PID’) aanwezig was. Vergeleken met de gebruikelijke PMmethoden was dit plan duidelijk onvoldoende. In de interviews bleek echter dat bij de herstart van het project sprake was van een politiek gevoelige situatie met gedemotiveerde medewerkers en een boze klant. Zodoende was, in overleg met de directie (opdrachtgever van het project eń van de audit) gekozen om snel ‘aan het werk’ te gaan en in eerste instantie vooral te werken aan de onderlinge verhoudingen. Het opstellen van de gebruikelijke PID zou dit sterk vertragen. Door het wekelijkse overleg van de projectmanager met de directie en het intensieve overleg binnen het projectteam was het risico van onduidelijke doelen en afspraken voldoende afgedekt. Audittechnisch kan dit een wijziging van het normenkader betekenen. Theoretisch zou de auditor dat zoveel mogelijk moeten voorkomen door in de voorbereiding goed de context van het project te bezien en op basis daarvan een specifiek, gericht normenkader vast te stellen. Aangezien hier echter sprake is van praktijkonderzoek en niet van wetenschappelijk onderzoek zal het normenkader veelal niet zeer gedetailleerd worden uitgewerkt en blijven dergelijke overwegingen belangrijk. Dit stelt ook eisen aan de auditors. Naast specifieke auditkennis is materiekennis op het gebied van projectmanagement absolute noodzaak. Daarom werkt het goed om dergelijke audits uit te voeren in een team met zowel een ervaren auditor als een ervaren projectmanager.

5.2

De Balanced Change Card (BCC)5

Zoals eerder aangegeven, zijn er vele factoren die bepalen of een project lukt of mislukt en waaraan de auditor dus aandacht moet besteden. De BCC is een model dat daarbij kan helpen met name als een kapstok waaraan vervolgens andere PM-methoden en -modellen kunnen worden opgehangen. De BCC (Koster & Bouwman, 1997) is eigenlijk een vertaling van het concurrerende waarden model van Quinn en Cameron (1988) naar tijdelijke organisaties, zoals projecten of veranderorganisaties. Het gaat ervan uit dat het management van een organisatie gelijktijdig een tweetal schijnbaar paradoxale krachten in balans dient te houden. Enerzijds betreft dit de balans tussen een interne en een externe focus. Anderzijds moet de balans worden gemanaged tussen beheersing en flexibiliteit. Indien deze balans van krachten wordt weergegeven op twee assen ontstaat een matrix met vier perspectieven (zie figuur 1). De diverse perspectieven van de BCC worden hierna nader beschreven.

afl. 43 (juni 2012)

5314-10

Flexibiliteit Zorgen voor hechte veranderteams

Zorgen voor tijdige aanpassing veranderbehoeften

Accep

Team

Interne focus

tatie

Conflicthanteringsfunctie

Adaptieve functie

Integratieve functie

Doelrealisatie functie

Externe focus

aat

Regels

Result

Zorgen voor duidelijke spelregels

Zorgen voor resultaatgerichte inspanningen Beheersing

Figuur 1. Balanced Change Card (Koster & Bouman, 1997)

5.2.1 Resultaatperspectief Het eerste perspectief betreft de extern gerichte beheersing, oftewel de mate waarin het project er in slaagt om de door de ‘buitenwereld’ gewenste resultaten op doelgerichte wijze te bereiken. Dit wordt daarom de doel- of resultaatgerichtheid van het project genoemd. In dit perspectief wordt beoordeeld of de doelstellingen van het project helder zijn verwoord, of deze goed in projectplannen en de bijbehorende planning zijn opgenomen en of de realisatie van doelstellingen in termen van kwaliteit, tijd en geld, goed wordt beheerst. Tevens wordt beoordeeld of de fasering juist is en of de afhankelijkheden tussen de verschillende onderdelen van het project in voldoende mate worden beheerst. Eventueel kan ook de performance, oftewel het daadwerkelijk gerealiseerde resultaat (t.o.v. de planning) op het moment van de audit worden beoordeeld. 5.2.2 Regelperspectief Het tweede perspectief betreft de intern gerichte beheersing, oftewel de mate waarin het project er in slaagt om intern de gang van zaken te beheersen door het stellen van duidelijke taken en procedures. Dit worden daarom de regels van het project genoemd. Waar het in het resultaatperspectief vooral gaat om de ‘wat-vraag’ (wat moet het project opleveren?), staat hier de ‘hoevraag’ centraal. Ten eerste betreft dit de governance en de verdeling van taken, verantwoordelijkheden en bevoegdheden binnen het project. Het project dient te beschikken over een duidelijke taakstructuur waarbinnen het voor alle betrokkenen helder is wat er van hen wordt verwacht. Er dienen expliciet goede afspraken te zijn gemaakt over de besluitvorming alsmede de rollen en bevoegdheden daarin van de diverse functies en overlegorganen. De rol, bezetting en de besluitvaardigheid van de stuurgroep is daarbij een bijzonder aandachtspunt. Daarnaast dient het project te beschikken over een goede interne communicatie alsmede over

afl. 43 (juni 2012)

5314-11

adequate procedures die worden gehanteerd voor het bewaken van de voortgang en de kwaliteit, voor het documentbeheer en voor de afhandeling van risico’s, issues en wijzigingen. De eerste twee perspectieven zijn vooral gericht op de meer ‘harde’ aspecten van projectmanagement. De BCC voegt daar echter nog twee perspectieven aan toe, die zich vooral richten op de zogenoemde soft controls van een project. 5.2.3 Teamperspectief Het derde perspectief beoordeelt de samenstelling en samenwerking binnen het projectteam. Uitgangspunt is dat naast de doelgerichtheid en het naleven van de regels, de kwaliteit van (de samenwerking in) het projectteam een bepalende factor is voor het welslagen van een project. Enerzijds gaat het daarbij om de adequate vertegenwoordiging van de betrokken afdelingen in het project of de inbedding van het project in de organisatie. Anderzijds geldt dat zonder een goede sfeer, een hechte samenwerking en een goede kwalitatieve samenstelling van het projectteam een project niet echt succesvol zal kunnen zijn. Het beoordelingmodel bevat daarom criteria die zowel de opzet als de werking van het team beoordelen. Het gaat hierbij onder meer om de vraag of er een goede representatie vanuit de organisatie in het project is opgenomen en of er voldoende en juiste maatregelen zijn getroffen om de sfeer, de samenwerking en het leervermogen binnen het project te optimaliseren. 5.2.4 Veranderperspectief In het vierde en laatste perspectief staat de acceptatie van de resultaten van het project door de organisatie centraal. Dit heeft twee kanten. Enerzijds gaat het hierbij om de vraag of wordt bewaakt of de uitgangspunten waarop het project van start is gegaan steeds geldig zijn. Het project moet in staat zijn om flexibel om te gaan met een zich wijzigende omgeving en mogelijk wijzigende eisen aan het project en haar resultaten. Anderzijds gaat het om de zorg dat het uiteindelijke resultaat wordt geaccepteerd door en geı¨mplementeerd in de organisatie. Dit vereist meer dan alleen communicatie en training. Een manco waar veel projecten op stuklopen is een onderschatting van de benodigde inspanningen op het gebied van verandermanagement. De meeste (grote) projecten zijn mede gericht op het realiseren van een gedragsverandering. Dit wordt vaak onvoldoende beseft. Weerstand tegen verandering kan er toe bijdragen dat een overigens goed georganiseerd project alsnog mislukt. Het projectmanagement moet daarom zorgen voor een goede communicatie met de omgeving en monitoren in hoeverre sprake is van mogelijke weerstanden tegen de geplande veranderingen. De wijze waarop in het project wordt omgegaan met mogelijke weerstand wordt bij voorkeur omschreven in een apart change plan. De BCC biedt de auditor aldus een generiek toepasbare ‘kapstok’, inclusief aandacht voor de zachtere aspecten. Het model zelf is echter onvoldoende concreet om als normenkader voor een audit te fungeren en dient tevens te worden toegesneden op de specifieke situatie. Daarbij kan goed gebruik worden gemaakt van andere methoden en modellen op het gebied van projecten verandermanagement. Zo kunnen Prince2 (of andere methoden zoals PMBOK of Projectmatig Cree¨ren), MSP en Fasen-/stromenmodellen helpen bij de concretisering van het resultaat- en regelperspectief. Voor het team- en veranderperspectief geldt dat voor modellen vanuit de veranderkunde, zoals Management of Change en de Kleuren van De Caluwe´.

afl. 43 (juni 2012)

5314-12

Tabel 1 geeft een overzicht van de uitwerking van de BCC in onderzoeksvragen en onderzoeksaspecten (auditvariabelen). Perspectief BCC

Afgeleide onderzoeksvragen

Auditvariabelen

A. Resultaat

Is het project voldoende resultaatgericht?

1. Gedefinieerde doelen en resultaten (business case) 2. Adequate plannen 3. Adequate bewaking business case 4. Adequate bewaking voortgang (kwaliteit, geld, en tijd) 5. Gerealiseerde resultaten

B. Regels en procedures

Zijn de regels en procedures voor de uitvoering, samenwerking en besluitvorming adequaat?

1. Adequate (governance-)structuur en taakverdeling 2. Adequate besluitvorming 3. Goede interne communicatiestructuur 4. Adequate procedures voor voortgangsbewaking 5. Adequate procedures voor kwaliteitsbewaking (QA en QC) 6. Goed ingericht risico- en issuemanagement 7. Adequate procedure voor wijzigingenbeheer 8. Adequate procedure voor documentatie 9. Voldoende leervermogen

C. Team

Is er sprake van een adequate bezetting en samenwerking van het projectteam?

1. Adequate procedures voor bemensing project 2. Adequate representatie en competentie medewerkers 3. Beschikbaarheid juiste mensen 4. Goede teamspirit 5. Goede samenwerking 6. Adequate oplossing van conflicten 7. Aandacht voor persoonlijke ontwikkeling teamleden 8. Team leert als geheel

D. Verandermanagement

Is er sprake van adequaat verandermanagement?

1. Adequate externe communicatie 2. Adequate training toekomstige gebruikers 3. Adequate aandacht voor veranderbereidheid en verandervermogen 4. Voldoende flexibiliteit om in te spelen op externe dynamiek

Tabel 1. BCC: onderzoeksvragen en -aspecten

Voor een volledige uitwerking van het normenkader op basis van de BCC wordt verwezen naar bijlage 1. Daarin is elk van de genoemde auditvariabelen uitgewerkt in beoordelingscriteria op basis waarvan kan worden beoordeeld of de desbetreffende variabele adequaat is ingevuld. Benadrukt wordt dat dit een indicatie is. Voor alle variabelen en criteria geldt dat zij zorgvuldig moeten worden beoordeeld op bruikbaarheid in een specifieke audit.

6.

Audits van mijlpaalproducten

Zoals aangegeven in paragraaf 3 worden twee soorten audits onderscheiden. In paragraaf 5 is de

afl. 43 (juni 2012)

5314-13

algemene PM-audit beschreven. Nu wordt in paragraaf 6 nader ingegaan op audits op specifieke objecten (deliverables of mijlpalen) binnen het project. In paragraaf 6.3 wordt een tweetal praktijkvoorbeelden van dergelijke audits kort beschreven. Daaraan voorafgaand wordt in de paragrafen 6.1 en 6.2 ingegaan op de uitgangspunten respectievelijk het stappenplan om tot een zorgvuldige keuze van de voor een specifiek project relevante auditobjecten te komen. Hierbij zij het volgende opgemerkt. Beoordelingen of het goed gaat met het project en of de geleverde mijlpaalproducten voldoen aan de kwaliteitscriteria, worden veelal uitgevoerd door de QA-functie. Vaak is daarbij in de praktijk sprake van een QA die repressief controleert of de gewenste deliverables zijn opgeleverd. Hier wordt echter voor een meer pro-actieve QA gepleit, die systematisch kijkt naar de risico’s en naar de waarborgen dat het project haar resultaten zal behalen zonder dat dit leidt tot overbelasting van het project. Daarom wordt hier gesproken over Proactive Quality Assurance ofwel PQA (Hartog & Cleton, 2009). PQA bestaat dan uit een geheel van audits (een auditframework) gericht op de meest belangrijke punten van het project. Zodoende is PQA in de eerste plaats een instrument voor de QA-functie in het project. Het kan echter ook worden gehanteerd door een meer onafhankelijke Interne Audit Dienst of externe (IT-)auditor.

6.1

Uitgangspunten relevante audits van mijlpaalproducten

Bij het bepalen van de mijlpaalproducten die voor een audit in aanmerking komen, moet worden uitgegaan van de volgende uitgangspunten: _ Pro-actief: pro-actief betekent dat niet wordt gewacht tot deliverables worden opgeleverd, maar dat vroegtijdig wordt gekeken naar de waarborgen die er bestaan dat de deliverables conform de gestelde kwaliteitseisen (kwaliteit, tijd en kosten) zullen worden opgeleverd. Dat komt tot uiting door in het gehele auditframework een zwaar accent op te leggen de kwaliteit van het projectmanagement alsmede in een zodanige timing van audits op deliverables dat nog tijdig correcties kunnen plaatsvinden. _ Minimale belasting van de organisatie: om de gewenste extra zekerheid te verkrijgen, dienen aanvullende werkzaamheden in de vorm van audits te worden uitgevoerd. De belasting hiervan, zowel in termen van de hoeveelheid werk als de planning, wordt echter zo klein mogelijk gehouden. – Risico-georie¨nteerd: zeker niet alles behoeft te worden geaudit. De keuze van de uit te voeren audits wordt gebaseerd op een risicoanalyse, waarbij wordt vastgesteld op welke punten de grootste risico’s worden gelopen en waar aldus extra zekerheid is gewenst. – Niet op kritieke pad: de audits worden zo opgezet dat zij niet op het kritieke pad liggen en de voortgang van het project dus niet hinderen. Dat betekent bijvoorbeeld dat bij audits van deliverables die op het kritieke pad liggen niet wordt gewacht op de oplevering daarvan, maar wordt gekozen voor een systeemgerichte benadering, waarbij kort voor de oplevering wordt gekeken of aan alle voorwaarden is voldaan om een adequaat product op te leveren. – Afstemming met andere audits: de invulling van het auditframework wordt afgestemd met andere audits binnen en buiten de organisatie om overlap te minimaliseren en zoveel als mogelijk gebruik te maken van elkaars resultaten. _ Uitgaan van de gebruikte projectmethode: het auditframework dient te worden afgestemd op de door de organisatie gekozen projectmethode (bijvoorbeeld Prince 2 of ASAP6) en de daarin benoemde fasen, producten en standaarden.

afl. 43 (juni 2012)

5314-14

6.2

Selectie relevante audits van mijlpaalproducten

De selectie van de relevante audits (c.q. de ontwikkeling van PQA) binnen een project verloopt als volgt: 1. vaststellen van de context en uitgangspunten; 2. benoemen van de gewenste audits (scoping); 3. uitwerken van de werkprogramma’s voor de onderscheiden audits; 4. implementeren van het framework, zodanig dat de diverse audits adequaat kunnen worden uitgevoerd. Opgemerkt wordt dat de uitvoering hiervan kennis vereist van zowel het project en de projectmethode, als van auditing. Daarmee kunnen de risico’s en auditobjecten enerzijds gericht worden bepaald en anderzijds deugdelijk eń doelmatig worden geaudit. De stappen worden hierna nader beschreven. 6.2.1 Stap 1. Context en uitgangspunten De eerste stap betreft het vaststellen van de uitgangspunten inzake de doelen, de inhoud en de wijze van uitvoering van de audits. Dit gebeurt op basis van een contextanalyse, waaronder een bespreking met het verantwoordelijke management. Vragen die in de contextanalyse aan de orde komen zijn: Wat zijn de doelstellingen van het project, ook in termen van de (achterliggende) doelen van de business? _ Welke projectmethode wordt gebruikt en in hoeverre wordt daarbij gebruik gemaakt van de in de methode beschikbare standards en templates (ook wel Quality Control (QC) genoemd)? _ Waar liggen de grootste risico’s van het project? _ Welke andere assurance is in en rond het project aanwezig? _ Wat is het doel van de PQA in de beheersing van het project en wie is de (primaire) opdrachtgever van de audits? _

6.2.2 Stap 2. Scoping Nadat de doelstellingen en aard van PQA zijn vastgesteld, dienen de uit te voeren audits te worden benoemd. Zoals gezegd, zijn de door de organisatie gekozen projectmethode en het projectplan daarvoor het uitgangspunt. Die beschrijven als het ware de audituniverse. Het verdient aanbeveling om in die audituniverse een onderscheid te maken tussen: _ specialistische7 producten: de producten die het project oplevert aan de organisatie ofwel de inhoudelijke resultaten. Deze zijn specifiek voor het desbetreffende project en verschillen dus met de aard van het project; _ managementproducten: de producten die worden opgeleverd in het kader van het projectmanagement van het project, zoals het projectplan, een voortgangsrapport en een risicolog. Hoewel de specifieke invulling natuurlijk per project verschilt, zijn deze producten in beginsel wel in elk project aanwezig. Voor het bepalen van de relevante managementproducten kan worden gekeken naar de binnen het project gehanteerde methode van projectmanagement, zoals Prince2 of Projectmatig Cree¨ren. Prince2 definieert per fase welke managementproducten dienen te worden opgeleverd en heeft

afl. 43 (juni 2012)

5314-15

templates voor de inhoud daarvan. Dat geeft de auditor zowel een hulpmiddel om te bepalen waar naar te kijken als om de normen vast te stellen waaraan die desbetreffende producten dienen te voldoen. Vanwege het generieke karakter zeggen deze modellen echter niets over de op te leveren specialistische of inhoudelijke producten, behalve dat deze gedefinieerd moeten worden in een productdecompositie (product breakdown structure) en hoe deze beschreven dienen te worden (product descriptions). De specialistische producten zijn wel in het projectplan of Project Initiatie Document (PID) beschreven. In het door het IIA-rapport Project Auditing, Handvatten voor de internal auditor is een uitgebreid overzicht opgenomen van de producten die in een aantal gangbare methoden zijn opgenomen. Naast deze generieke modellen, wordt met name in projecten met systeemontwikkeling vaak gebruik gemaakt van meer specifieke fasen/stromen-modellen8. Deze modellen gaan een stap verder in de zin dat in die modellen wel de specialistische producten per fase en stroom worden gedefinieerd, waarmee de audituniverse keurig in kaart wordt gebracht.

1

0

Project Project Preparation PrePreparation

GAP Analysis Project plan Scope

2 Business Blueprint

Enhancements Authorization Reports Conversions Interfaces Business Processes Organiz. Structure

4 Final Preparation

3 Realization

Continuous

Change 5 Go Live & Suport

System Performance

Business Processes

Test Plan Training mat. Procedures Test Cases

Reports

Go Live Plan

Interfaces Conversion

Figuur 2. Voorbeeld fasen/stromen-model met mijlpaalproducten.

Nadat op basis van de gehanteerde PM-methode en het projectplan inzicht is verkregen in het geheel van deliverables, wordt door middel van een risicoanalyse gee¨valueerd hoe belangrijk en hoe complex de desbetreffende deliverables zijn. Dit gebeurt in overleg met de stuurgroep, het projectmanagement, consultants met kennis van de PM-methode en materiedeskundigen. De auditor zou bijvoorbeeld op basis van het projectplan een aantal interviews kunnen houden en de

afl. 43 (juni 2012)

5314-16

resultaten daarvan vervolgens in een workshop met alle genoemde betrokkenen bespreken. Dit resulteert in een overzicht van de meest kritieke deliverables, die zullen worden geaudit. Scoping

Project preparation

Business blueprint

Realization

Final preparation

Go live & support

PROGRAM & PROJECT MANAGEMENT SOLUTION STREAM TECHNICAL DEVELOPMENT CHANGE MANAGEMENT

GAP Analysis Process Audit Scope Document Audit

Data Upload Audit Stress Test Audit

Business Blueprint Process & Object Audit Technical Management Audit Conversion Planning Audit

Program & project management audits

Integration Test Audit Cut-over Plan Audit System Settings Audit Customizing Documentation Audit

Figuur 3. Voorbeeld resultaat scoping: vaststelling uit te voeren audits m.b.v. fasen/stromen-model.

In aanvulling op de benoeming van de auditobjecten wordt ook het type audit en de globale planning bepaald. Bij het type of de aard van de audit wordt een onderscheid gemaakt naar: _ systeemaudits waarbij (prospectief) wordt gekeken of voldoende waarborgen bestaan dat het goed zal gaan; _ performance- of productaudits, waarbij het doel is om (retrospectief) een oordeel te geven of de desbetreffende deliverable voldoet aan de eisen. Bij de performance-audit kan vervolgens om tot dit oordeel te komen, worden gekozen om het product zelf te beoordelen dan wel het proces dat tot het product heeft geleid. Additionele beoordeling van het product zelf geeft meer zekerheid, maar kost over het algemeen meer. Daarbij kan de productaudit pas in later stadium (na afronding product) worden uitgevoerd. Als de oplevering van het product op het kritieke pad van het project ligt, zou dat kunnen betekenen dat de audit het project vertraagt. Vraag is dan, alle risico’s afwegend, of niet voldoende zekerheid kan worden verkregen door middel van een beoordeling van het proces, inclusief de daarin opgenomen reviews. Dat zou zelfs op een zodanig moment kunnen plaatsvinden dat nog tijdig kan worden gecorrigeerd indien blijkt dat niet alles naar wens verloopt. De resultaten van de voorgaande activiteiten worden verwerkt in een Audit Roadmap. In dit document wordt het auditframework beschreven in de vorm van een overzicht van de uit te voeren audits.

afl. 43 (juni 2012)

5314-17

Audit

Stroom

Doel Audit

Kwal.asp.

Aard audit

Benodigde docum.

Afhankelijkheden

Fase I 1

Figuur 4. Opzet van de Audit Roadmap.

6.2.3 Stap 3. Uitwerken audits in werkprogramma’s Nadat duidelijk is welke audits zullen worden uitgevoerd, dient de inhoud en de wijze van uitvoering nader te worden uitgewerkt. De belangrijkste aspecten daarbij zijn de uitwerking van het normenkader en het bepalen van de bronnen en wijze waarop die te benaderen. Het wordt belangrijk geacht dat de auditor, zeker in geval van projecten met zijn vele deskundigen en aanpakken, een concreet normenkader opstelt dat aangeeft naar welke aspecten wordt gekeken eń wanneer die aspecten adequaat zijn ingevuld. Dat normenkader hoeft niet van scratch af aan ontwikkeld te worden, maar dient wel op maat voor het desbetreffende project te worden gemaakt. De basis is gelegen in: _ de projectmethode, waarin de op te leveren (management)producten zijn gedefinieerd en veelal zijn uitgewerkt in templates. Dit zijn vooral de procedurele eisen (vormvoorschriften); _ eerder opgeleverde deliverables die meer de inhoudelijk criteria aangeven. Zo dient de inhoud van een Business Blueprint aan te sluiten bij de Business Case. 6.2.4 Stap 4. Implementatie Afhankelijk van de omvang en frequentie van de projecten PQA-activiteiten, kunnen de volgende activiteiten in dit kader worden uitgevoerd: _ de verdere uitwerking van de auditontwerpen in praktische tools, zoals interviewvragenlijsten en formats voor de verslaglegging; _ de opleiding en training van de auditors; _ de communicatie met de betrokkenen om duidelijkheid te cree¨ren over de toegevoegde waarde van PQA en de diverse audits; _ de afstemming met andere auditors en toezichthouders om afspraken te maken over de rol- en taakverdeling en over de waarborgen voor het kunnen steunen op elkaars resultaten. Voor projecten waarbij sprake is van meerdere implementaties of roll-outs van een nieuw systeem, speelt daarbij nog het volgende. Veelal zal gekozen worden voor een generiek auditframework, waarbij de concrete samenstelling van het framework per roll-out, op basis van een risicoanalyse, specifiek wordt gemaakt. Bepalende factoren daarbij zijn bijvoorbeeld: _ green field of is er al ervaring met een business system-implementatie; _ de mate van afwijking van de standaard werkprocessen; _ de mate van ondersteuning door consultants. Eigenlijk is daarbij sprake van een soort nadere scoping aan het begin van een nieuwe roll-out.

afl. 43 (juni 2012)

5314-18

6.3

Voorbeelden audits mijlpaalproducten

In deze paragraaf wordt een tweetal in de praktijk veel uitgevoerde audits van mijlpaalproducten kort beschouwd. Vanzelfsprekend is dit bij lange na niet volledig. Wel wordt een aantal overwegingen bij het invullen van de gewenste audits geconcretiseerd. Deze overwegingen gelden ook voor andere mijlpaalproducten. De volgende mijlpaalproducten worden besproken: _ het projectplan of PID (een managementproduct); _ de blauwdruk van het nieuwe proces of het ontwerp van de nieuwe organisatie (en specialistisch product). 6.3.1 Projectplan of PID Het projectplan of het Project Initiatie Document (PID), zoals dat binnen Prince2 wordt genoemd, dient als basis van het project en beschrijft de opzet en wijze van beheersing. Het is daarom een belangrijk object van onderzoek. Hierbij geldt, zoals eerder opgemerkt, dat een audit van het projectplan niet hetzelfde is als audit van het projectmanagement (de PM-audit). Niet alle relevante aspecten staan immers in het projectplan. Daarbij betreft het projectplan alleen de opzet en kijkt de PM-audit ook naar de werking van de beheersmaatregelen. Om dat laatste te ondervangen wordt ook wel eens het onderscheid gemaakt in: _ de audit van het projectplan; _ de audit van de inrichting van het project, waarbij wordt vastgesteld of het project is ingericht conform het projectplan (dat dan dus als normenkader fungeert). In de praktijk bestaat een veelheid van audits van projectplannen. Zij verschillen vooral in de kwaliteitsaspecten die worden beoordeeld. Belangrijke onderzoeksvragen zijn: _ Voldoet het projectplan aan de standaard? Dit geldt vooral voor organisaties met een eigen PM-methode en voor situaties waarin expliciet is gekozen om een bepaalde PM-methode te volgen. Deze audit is vooral procedureel van aard: is alles ingevuld en beschreven? (Zie tabel 2.) _ Is het projectplan volledig; zijn alle, voor het succes van het project relevante beheersaspecten beschreven? Deze vraag lijkt op de vorige zonder dat vooraf expliciet een PM-methode als norm is gekozen. Dat betekent dat in de voorbereiding van de audit, in overleg met opdrachtgever en auditee, een keuze moet worden gemaakt over wat een adequaat projectplan omvat en in het verlengde daarvan het normenkader dient te worden gee¨xpliciteerd. _ Is het projectplan inhoudelijk adequaat? Veelal gaat het daarbij uiteindelijk om de vraag of het project haalbaar is en of er voldoende waarborgen bestaan voor het succes ervan. De auditor dient hierbij alert te zijn op het normenkader; met name voor de uitwerking van de doelen in termen van planning, budgettering en bemensing is het moeilijk te bepalen wanneer deze adequaat zijn (bijvoorbeeld: wanneer is de planning en het budget realistisch; had het sneller en goedkoper gekund of had juist meer tijd en geld moeten worden begroot?). Daarom wordt in de praktijk veelal vooral gekeken naar de onderlinge consistentie van de diverse onderdelen en of deze met enige onderbouwing zijn beschreven. In bijlage 2 is een voorbeeld van een (deel van een) dergelijk uitgewerkt normenkader opgenomen.

afl. 43 (juni 2012)

5314-19

Auditaspect Managementsamenvatting

Doelen

Randvoorwaarden afhankelijkheden

Initiële Business Case

Projectorganisatie

Projectplanning Begroting Beheersmechanismen Communicatie

Criteria • Opdrachtgever benoemd en bevoegd? • Projectmanager benoemd? • Project opgenomen in goedgekeurde programma? •… • Doelen benoemd en SMART verwoord? • Aanleiding en op te lossen probleem vermeld? • Duidelijke afbakening? • Aannames en uitgangspunten geëxpliciteerd? • Risicoanalyse uitgevoerd? Maatregelen gedefinieerd en toegewezen? •… • Randvoorwaarden en uitgangspunten geëxpliciteerd? - organisatorisch - technisch • Afhankelijkheden van andere projecten geëxpliciteerd? •… • Business Case opgenomen en plausibel onderbouwd? • Aannames en uitgangspunten expliciet beschreven? • Format ‘investeringsanalyse’ volledig ingevuld? •… • Organogram opgesteld en ingevuld? • Alle rollen ingevuld (SG, PM, …) en TBV’s gedefinieerd? • Overzicht overlegstructuren gedefinieerd? •… •… •… •… •…

Tabel 2. Voorbeeld van procedurele beoordelingsvragen van de PID

6.3.2 Blauwdruk Juist de blauwdruk (ofwel het ontwerp of de Business Blueprint) wordt vaak gezien als het belangrijkste (specialistische) product. Het omschrijft de nieuwe taakverdeling, werkwijze en functionaliteiten van het systeem en is daarmee bepalend voor veel van de andere projectwerkzaamheden eń voor het realiseren van de strategie en doelen van de organisatie. Bij het bepalen van de wijze waarop de blauwdruk het beste kan worden geaudit spelen de volgende vragen ofwel mogelijkheden. _ Is een aparte audit wel gewenst of is het voldoende om in de PM-audit bijzondere aandacht te besteden aan de waarborgen dat de blueprints (blauwdrukken) adequaat zijn? Deze afweging is onderdeel van de risicoanalyse waarmee de gewenste audits op het project worden bepaald. Eventueel kan een tweetrapsraket worden gehanteerd, waarbij wordt afgesproken dat indien uit de PM-audit twijfels ontstaan of blijkt dat onvoldoende is geborgd dat adequate blauwdrukken zullen worden opgeleverd er alsnog een verbijzonderde audit op de blauwdruk zal worden uitgevoerd. _ Verdient het de voorkeur om (achteraf) de blauwdruk zelf of om (vooraf, prospectief) de

afl. 43 (juni 2012)

5314-20

_

opzet van het totstandkomingproces te bekijken? Wil de opdrachtgever echt een oordeel over de blauwdruk zelf of meer zekerheid vooraf dat de blauwdruk goed zal zijn? Het laatste heeft als voordeel dat, indien nodig, in een vroegtijdig stadium kan worden bijgestuurd. De deliverable zelf wordt echter niet beoordeeld, zodat er minder zekerheid kan worden verschaft over het uiteindelijke resultaat. Bij de beoordeling van de opzet van het proces, wordt gekeken naar de waarborgen dat de blauwdruk adequaat zal worden opgesteld; tabel 3 geeft hiervan een voorbeeld. Als een oordeel over de inhoudelijke kwaliteit van de blauwdruk ofwel het mijlpaalproduct zelf wordt gevraagd, zijn er wederom twee mogelijkheden. Deze mogelijkheden betreffen de vraag hoe het beste tot het oordeel over het mijlpaalproduct kan worden gekomen: kan deze het beste worden gegeven door het product zelf te beoordelen of door de wijze waarop deze tot stand is gekomen te bekijken? In het laatste geval wordt gekeken naar de werking van het proces en de daarin getroffen beheersmaatregelen daarin die hadden moeten waarborgen dat de blauwdruk aan de gestelde eisen voldoet. Het kijken naar het proces heeft als voordeel dat niet behoeft te worden gewacht tot het mijlpaalproduct daadwerkelijk is opgeleverd. Dat kan met name een voordeel zijn als dit product op het kritieke pad van het project ligt. Daarbij is het vaak eenvoudiger en daardoor minder duur om het proces te beoordelen. In de keuze tussen een beoordeling van het product of het proces, spelen ook de volgende vragen: – Is een inhoudelijke beoordeling van de blauwdruk wel nodig? Hier speelt de afweging tussen waarborgen vooraf en controle achteraf. Indien in het project is afgesproken dat gebruik wordt gemaakt van standaards in termen van procedures, templates en reviews, is een aparte audit achteraf minder nodig. Zo wordt in de ASAP-methode de blauwdruk gezien als een halffabrikaat dat wordt getoetst door alle afnemers (de bouwers, degene die de testscripts moeten maken, etc.). Als alternatief voor de inhoudelijke beoordeling zou dan kunnen worden gekeken naar de werking of naleving van de afgesproken standaards9. – Is een inhoudelijke beoordeling van de blauwdruk door de auditors wel mogelijk (binnen een redelijk budget)? Vaak wordt hieraan getwijfeld, omdat in het bepalen van de toekomstig gewenste werkwijze vele betrokkenen en aspecten een rol spelen. Deze worden besproken en ten opzichte van elkaar afgewogen, waarbij functionaliteiten worden afgezet tegen kosten en de acceptatie van veranderingen. Daarbij worden prioriteiten gesteld en risico’s ingeschat en al dan niet geaccepteerd. Dat maakt het voor de auditors eigenlijk onmogelijk om te beoordelen of het uiteindelijke resultaat adequaat is gegeven het geheel van doelen van de organisatie. Wel kan naar een bepaald aspect worden gekeken, zoals ‘is de audittrail geborgd’ of ‘zijn er adequate maatregelen om de betrouwbaarheid van de afhandeling te waarborgen?’. Deze audits kunnen worden uitgevoerd zonder de vereiste afwegingen met andere doelen en kritieke succesfactoren. Nog een alternatief, dat in de praktijk vaak wordt gebruikt, is een beoordeling van het product op meer procedurele eisen, ofwel of het aansluit bij formats die hiervoor binnen de organisatie gelden (klopt de paragraafindeling, zijn alle aspecten beschreven?) of dat alle aspecten consistent zijn met elkaar?

Op basis van het bovenstaande worden in de praktijk de volgende audits op blauwdrukken uitgevoerd.

afl. 43 (juni 2012)

5314-21

_

_

_

Een prospectieve systeem- of procesaudit: bestaan er voldoende waarborgen dat de blauwdruk adequaat zal zijn?’ (zie tabel 3); Een retrospectieve productaudit: (is de blauwdruk adequaat?) uitgevoerd door een beoordeling van de blauwdruk zelf: voldoet het product aan de eisen?; Een retrospectieve productaudit (is de blauwdruk adequaat?), uitgevoerd door een beoordeling van het totstandkomingproces: is de blauwdruk adequaat tot stand gekomen? Het normenkader hierbij zal in belangrijke mate overeenkomen met de eerste optie (zie tabel 3), waarbij hier vooral de werking zal worden bekeken.

Zoals aangegeven dient de keuze voor wat het meest passend is in het desbetreffende project op basis van een risicoanalyse, in overleg met de betrokkenen, uiteindelijk door de opdrachtgever van de audit te worden bepaald. Auditaspect = waarborg Duidelijke te behalen resultaten

Voortgangsbewaking

Duidelijke taakverdeling Samenstelling team

Tools en procedures

Bewaking kwaliteit

Criteria • Vastgesteld scopingsdocument, met inhoudelijke uitgangspunten en randvoorwaarden - Scopingfase afgerond voor start Blauwdrukfase • Vastgestelde planning • Doelen en planning haalbaar (geacht) - Incl. specificatie van vereiste beschikbaarheid diverse rollen per week - Expliciet akkoord op planning van betrokken managers • Goede interne overleg- en communicatiestructuur • Adequate registratie en afhandeling van risico’s • Adequate procedures voor voortgangsbewaking (tijd en geld) • Adequate escalatiemogelijkheden • Adequate besluitvorming • Adequate taakverdeling: specificatie rollen (met bijbehorende taken en competenties) • Aanwezigheid van de volgende rollen: - Proceseigenaar of Functioneel eigenaar (met voldoende bevoegdheden over inhoud) - Key users betreffende proces(sen) - Business Consultant (inbreng best practices) - Adviseur met voldoende kennis systeem (inbreng haalbaarheid, kosten maatwerk) - Analist (voor eenduidige beschrijving) • Teammedewerkers beschikken over de vereiste competenties (conform rollenboek) • Voldoende beschikbaarheid resources, met name (risico’s bij) - Proceseigenaar - Key users • Adequate afspraken over wijze en niveau van detaillering • Adequate tools en templates voor beschrijving • Adequate procedure voor opstellen blauwdruk • Adequate procedure voor wijzigingenbeheer • Vooraf gedefinieerde acceptatiecriteria • Expliciete afstemming blauwdrukken diverse processen op onderlinge aansluiting (‘integratie’) • Controle opgeleverde resultaten door afnemers blauwdruk (zoals bouwers, testers, …) op vastgestelde acceptatiecriteria

Tabel 3. Voorbeeld van audit op het totstandkomingproces van de blauwdruk

afl. 43 (juni 2012)

5314-22

Noten 1.

Dit wordt wel het onderscheid tussen de 2e en 3e ‘line of defence’ binnen het project genoemd,

2.

waarbij de 1e line de projectmanager zelf is. Definitie volgens de Nederlandse Competentie Baseline (NCB) versie 3 van de International Project Management Association (IPMA).

3. 4.

Het onderscheid tussen specialistische en managementproducten is ontleend aan Prince2. De product breakdown structure is de weergave van de hie¨rarchie van op te leveren producten en onderliggende tussenproducten om tot een ordening van de in het project noodzakelijke activiteiten te komen. Een fasen/stromen-model is een model waarin een project wordt verdeeld in een matrix met enerzijds een aantal fasen (zoals voorbereiding, blauwdruk, realisatie, etc.) en anderzijds een aantal inhoudelijke stromen (zoals het management, de inhoudelijke oplossing en de technische oplossing).

5.

Onderstaande tekst is in belangrijke mate ontleend aan Babeliowsky & Hartog, Het auditen van projecten programmamanagement, www.auditing.nl.

6.

ASAP staat voor Accelerated SAP, de implementatiemethode van SAP.

7.

Het onderscheid tussen specialistische en managementproducten is ontleend aan Prince2.

8.

De fasen/stromen-modellen zijn veelal ontwikkeld in het kader van ontwikkeling volgens de watervalmethode. Daarnaast bestaan veel succesvolle methodieken die meer evolutionair of incrementeel ontwikkelen, waarbij ontwerp, bouw en test meer iteratief in kleine stapjes plaatsvinden in plaats van volledig na elkaar.

9.

Voor het evalueren van ontwerpen t.o.v. afgesproken standaards bestaan ook tools, vergelijkbaar met tools voor de analyse van de robuustheid van softwarecode. Daarmee kunnen deze beoordelingen effectief en snel worden uitgevoerd.

Literatuur A. Babeliowsky en P.A. Hartog, Het auditen van projecten programmamanagement, www.auditing.nl. L. de Caluwe en H. Vermaak, Leren veranderen – Een handboek voor de veranderkundige, Kluwer, 2002. www.managementsite.nl/350/verandermanagement/veranderen-vijf-kleuren.html. P.A. Hartog en H. Cleton, ‘Proactive Qualty Assurance (PQA)’, AuditMagazine, nr. 3, 2009. IIA, Project Auditing, Handvatten voor de internal auditor, www.auditing.nl, 2010. E. Koster & W. Bouwman,‘Een raamwerk voor het vormgeven en evalueren van veranderorganisaties’, M&O nr. 5, 1997. Prince2 (PRojects IN Controlled Environment), www.prince-officialsite.com. R. E. Quinn en K. S. Cameron, Towards a theory of change in organization and management, Ballinger, 1988. Auteur Peter Hartog is senior auditing consultant bij Auditing & Consulting Services (ACS) en docent aan enkele universiteiten waaronder de postinitie¨le opleiding internal/operating auditing aan de Erasmus Universiteit Rotterdam. Hij publiceert regelmatig op het vakgebied. Hij is lid van de Commissie Vaktechniek van het IIA en maakte deel uit van de vaktechnische groep van het IIA die in 2010 een publicatie over project auditing heeft uitgebracht (IIA, 2010).

afl. 43 (juni 2012)

5314-23

afl. 43 (juni 2012)

5314-24

Bijlage 1 BCC, een uitgewerkt normenkader1 A. Resultaatgerichtheid Auditvariabelen 1. Gedefinieerde doelen en resultaten

Beoordelingscriteria l l l

l l

l

l

2. Adequate plannen

l

l l

l

l l l

3. Adequate bewaking business case

l

l

l

l

Er is een actuele, gevalideerde business case De business case wordt uniform geı¨nterpreteerd Doelen worden door alle betrokkenen uniform geı¨nterpreteerd Doelen en resultaten zijn SMART (beschreven) De doelen van de binnen het project onderscheiden deelprojecten sluiten goed op elkaar aan Er zijn ook doelen geformuleerd in termen van verandermanagement Geborgd is dat de doelen ook de relevante eisen van externe partijen omvatten Projectplan is opgesteld conform de gehanteerde PM-methode Projectplan is goedgekeurd (conform geldende procedure) Randvoorwaarden voor succes zijn benoemd en worden bewaakt Afhankelijkheden tussen delen van het project (deelprojecten/activiteiten) zijn benoemd en worden bewaakt Plan bevat realistische planningen Plan bevat realistische budgetten Evenwichtige aandacht voor ‘system delivery’ en ‘business change’ De realisatie van de doelen en resultaten wordt bewaakt (cf. vastgestelde procedure) De relevantie en haalbaarheid van de doelen en resultaten wordt periodiek gee¨valueerd (incl. het definie¨ren van nieuwe) Er is een procedure voor aanpassing gedefinieerde resultaten (incl. analyse van impact op de business case) Belanghebbenden worden geı¨nformeerd over voortgang en mogelijke aanpassingen

afl. 43 (juni 2012)

5314-25

Auditvariabelen 4. Adequate voortgangsbewaking (kosten, voortgang, kwaliteit)

Beoordelingscriteria l

l

l

l l

5. Gerealiseerde resultaten

l

Tijd, geld en kwaliteit zijn genormeerd in mijlpalen die aansluiten op de doelstellingen De voortgang wordt periodiek gerapporteerd, vastgesteld en vergeleken met de norm Voortgangrapportage is gerelateerd aan de op te leveren mijlpaalproducten Duidelijk is wanneer en door wie moet worden ingegrepen Er zijn voldoende ingreepmogelijkheden bij geconstateerde afwijking De doelen worden gerealiseerd conform plan (performance)

B. Regels en procedures Auditvariabelen 1. Adequate (governance-) structuur, taakverdeling

2. Adequate besluitvorming

Beoordelingscriteria Er is een adequaat besturingsmodel, met: – Een duidelijke sponsor en (eéń) opdrachtgever – Eenduidige verantwoordelijkheden voor het project l Er is een heldere projectstructuur l Taken, bevoegdheden, verantwoordelijkheden zijn verdeeld in overeenstemming met het besturingsmodel en de gekozen PM-methode l De rollen in het project zijn beschreven in termen van taken, bevoegdheden, verantwoordelijkheden, kennis en vaardigheden l De benoemde rollen weerspiegelen zowel ‘system delivery’ als ‘business change’ l Projectmedewerkers worden aangesproken op hun taken en verantwoordelijkheden en verantwoordelijk gesteld voor de bereikte resultaten l

l

l l l l

l

Het is duidelijk hoe het proces van besluitvorming verloopt en wie waarover besluit Besluitvormingsbevoegdheden zijn voldoende gedelegeerd Er is een goed escalatiemodel Besluitvorming wordt gebaseerd op adequate informatie Besluitvorming vindt plaats conform de vastgestelde structuur Besluitvorming vindt tijdig plaats

afl. 43 (juni 2012)

5314-26

Auditvariabelen 3. Goede interne communicatiestructuur

4. Adequate procedures voor voortgangsbewaking

Beoordelingscriteria Er is een open en tijdige communicatie waarbij ook ruimte is voor slecht nieuws l De communicatiestructuur waarborgt een goede uitwisseling van informatie en communicatie tussen: – Teams onderling – Van het team naar projectmanager naar stuurgroep – Van stuurgroep naar projectmanager en teams l

l

l

l

l

5. Adequate procedures voor kwaliteitsbewaking (QA en QC)

l

l

l

l

l

6. Goed ingericht risico- en issuemanagement

l l

l l

l

7. Adequate procedure voor wijzigingenbeheer

l

l l l l

8. Adequate procedures voor documentatie

l

l

Er zijn adequate standaards en templates voor het rapporteren van de voortgang (tijd, geld en kwaliteit) De templates (en onderdelen daarvan) worden eenduidig geı¨nterpreteerd Rapportages sluiten aan op de overlegstructuur, voor wat betreft inhoud, detaillering en frequentie De procedure werkt in de praktijk conform de opzet Er zijn goede standaards en templates voor het borgen en bewaken van de gewenste kwaliteit, in overeenstemming met de gekozen PM-aanpak Voor alle kritieke mijlpaalproducten zijn ‘productbeschrijvingen’ opgesteld met concrete kwaliteitscriteria Opgeleverde mijlpaalproducten worden volgens de gedefinieerde standaard getoetst De projectmanager ontvangt goede en tijdige informatie over het gebruik van de afgesproken kwaliteitsstandaards Er is periodieke verbijzonderde toetsing van het project gepland Er is een periodieke, structurele (integrale) risicoanalyse Risico’ s en issues worden geı¨dentificeerd en gelogd. De risicolog is up-to-date Alle aangedragen risico’s en issues worden gelogd Er is duidelijk vastgelegd wie (op welk niveau) welke risico’s en issues moet behandelen en bewaken Acties om de risico’s en issues op te lossen worden gedefinieerd; de afhandeling daarvan wordt bewaakt Er is een procedure hoe wijzigingen (changes: inhoud) en afwijkingen (exceptions: tijd, geld) worden afgewikkeld Er is een procedure voor nood – spoedwijzigingen Alle wijzigingen en afwijkingen worden geregistreerd Per wijziging wordt een impact analyse uitgevoerd. De afhandeling van de wijzigingen wordt bewaakt Er is een adequate procedure voor het beheer van alle aan het project gerelateerde documenten De procedure werkt in de praktijk conform de opzet

afl. 43 (juni 2012)

5314-27

Auditvariabelen

Beoordelingscriteria

9. Voldoende leervermogen

l

l

l

Regelmatig wordt de gang van zaken gee¨valueerd en gekeken waar verbeteringen mogelijk zijn Alle medewerkers worden gevraagd verbetermogelijkheden aan te geven Er wordt gebruik gemaakt van lessons learned voor volgende projecten

C. Team Auditvariabelen 1. Adequate procedures voor de bemensing project


l

2. Adequate representatie en competentie projectmedewerkers

3. Beschikbaarheid juiste mensen

Alle betrokken onderdelen van de organisatie zijn in het project vertegenwoordigd l Alle betrokken medewerkers en managers, voldoen aan de gestelde eisen ten aanzien van kennis en ervaring l In het project is voldoende kennis en kunde van: – De business; dus geen overdaad aan externen (max. 50% externen) – Projectmanagement – Verandermanagement l

l l l

l

4. Goede teamspirit

l

l

l

l

5. Goede samenwerking

Er zijn adequate en goed werkende procedures voor het selecteren, registreren en beoordelen van de benodigde personele capaciteit voor de uitvoering van het project Er is een procedure voor het realiseren van achtervang (voor medewerkers die deelnemen in het project)

l

l l

Er is goed zicht op de gewenste bezetting De planning is tijdig beschikbaar en stabiel Medewerkers worden voor een substantieel tijdsbeslag ingezet (geen versnippering) De gewenste bezetting wordt bewaakt en is ook daadwerkelijk aanwezig Het teamgevoel en de kwaliteit van de samenwerking tussen de verschillende teams wordt actief gestimuleerd Er wordt actief gewerkt aan het cree¨ren van een gemeenschappelijke visie Er is sprake van een goede teamsfeer en gevoel van gemeenschappelijke verantwoordelijkheid Er is vertrouwen in succes van het project Alle teamleden zijn bekend met hun eigen rol en die van anderen Teamleden durven anderen om hulp en advies te vragen Resultaten en problemen worden onderling gecommuniceerd

afl. 43 (juni 2012)

5314-28

Auditvariabelen 6. Adequate oplossing van conflicten 7. Aandacht voor de persoonlijke ontwikkeling van de teamleden


l

l

l

8. Team leert als geheel

l

Er wordt (naar de ervaring van betrokkenen) tijdig en adequaat gereageerd op conflicten die zich voordoen Medewerkers worden mede op basis van hun persoonlijke leerdoelen geselecteerd om aan het project deel te nemen Er is gedurende het project actief aandacht voor de persoonlijke ontwikkeling van de teamleden Gedurende het project is duidelijk waar medewerkers na afloop komen Er vinden tussentijdse evaluaties plaats en de leerpunten die hieruit voortkomen worden actief opgepakt

D. Verandermanagement Auditvariabelen 1. Adequate externe communicatie


l

l

l

l

2. Adequate training van toekomstige gebruikers

l l

l

3. Adequate aandacht voor veranderbereidheid en het verandervermogen

l

l

l l

De diverse externe stakeholders en hun belangen en informatiebehoeften zijn goed in beeld gebracht Op basis van deze analyse is een adequaat communicatieplan opgesteld Communicatie naar de betrokken lijnafdelingen wordt uitgevoerd door de ‘verandermanagers’ uit de lijnorganisatie Communicatiedeskundigen hebben slechts een faciliterende rol Het communicatieplan wordt uitgevoerd conform plan Een formeel trainingsplan/coachingsplan is opgesteld De diverse gebruikers worden conform trainingsplan getraind Er is voldoende aandacht van het lijnmanagement voor de training Er is goed een goed inzicht in de impact van de veranderingen die het project tot gevolg zal hebben Er is een goed inzicht in de aanwezige weerstand tegen verandering, veranderbereidheid en -vermogen worden periodiek ‘gemeten’ Op de aanwezige weerstand wordt adequaat gereageerd Er is een goed change-plan waarin alle veranderkundige interventies staan beschreven

afl. 43 (juni 2012)

5314-29

Auditvariabelen 4. Voldoende flexibiliteit om goed in te spelen op externe dynamiek


l

Het project heeft voldoende kanalen om eventuele wijzigingen in de (wensen van de) omgeving op te vangen Het project is flexibel genoeg om zich gedurende de looptijd van het project aan te passen aan zich wijzigende omstandigheden en wensen vanuit de omgeving

Noot 1.

Ontleend aan Babeliowsky & Hartog, Het auditen van projecten programmamanagement, www.auditing.nl.

afl. 43 (juni 2012)

5314-30

Bijlage 2 Audit op projectplan, een uitgewerkt normenkader In deze bijlage wordt een voorbeeld gegeven van het normenkader van een audit op het projectplan op basis van ‘projectmatig werken’. Het doel van deze audit is inzicht te geven in de haalbaarheid en volledigheid van het projectplan. Daartoe bepaalt de auditior of alle componenten aanwezig zijn in het projectplan. Behalve de aanwezigheid dient de auditor zich een oordeel te vormen over de kwaliteit. Hierbij dient gekeken te worden naar juistheid en haalbaarheid. Opgemerkt wordt dat dit normenkader generiek van aard is, dus toepasbaar op alle soorten projecten. Dat betekent dat voor ICT-projecten de diverse variabelen dienen te worden toegespitst op de risico’s van en benodigde tools voor systeemontwikkeling en technische realisatie. Auditvariabelen


Doelen & resultaten

l l l

l

l

l l

l

Kwaliteit

l

l l

l l l

l l

Is het doel van het project benoemd? Is dit doel vertaald in ‘te behalen resultaten’? Zijn de resultaten duidelijk, dus: specifiek, meetbaar, acceptabel, realiseerbaar en uitgezet in de tijd (SMART)? Bestaat er een procedure voor het wijzigen van de projectresultaten? Bevat de wijzigingsprocedure een impactanalyse van de wijziging op planning en kosten? Zijn de randvoorwaarden voor het project bepaald? Zijn de relaties met andere projecten, afdelingen, etc. aangegeven? Is er overeenstemming met de opdrachtgever over het doel en de resultaten? Zijn er kwaliteitseisen opgesteld voor de producten (eventueel in kwaliteitsplan)? Zijn deze eisen zoveel mogelijk kwantitatief en aantoonbaar? Zijn er maatregelen gedefinieerd om te waarborgen dat de input voldoet? Zijn er maatregelen genomen om het proces te beheersen? Zijn er controles van het eindproduct gedefinieerd? Zijn er standaarden gedefinieerd waarmee in het project wordt gewerkt (denk aan systemen, taal, formulieren, etc.)? Is het kwaliteitsplan goedgekeurd? Is het goedgekeurde kwaliteitsplan aan alle betrokkenen verstrekt?

afl. 43 (juni 2012)

5314-31

Auditvariabelen


Tijd

Bij het beoordelen van de planning zal bekeken moeten worden of deze aanwezig is in het projectplan, maar ook of deze realistisch is. l Zijn de opleverdata van de resultaten bepaald (milestones)? l Is per activiteit bepaald: bewerkingtijd, doorlooptijd en personen? l Zijn de afhankelijkheden tussen de activiteiten bepaald? l Is er een detailplanning opgesteld (incl. Gantchart) op activiteitenniveau? l Zijn er marges ingebouwd?

Geld

Bij het beoordelen van het budget zal bekeken moeten worden of het budget aanwezig is in het projectplan, maar ook of het opgevoerde budget realistisch is. Dit kan bereikt worden door vergelijking met expertmeningen of evaluatiegegevens. ¨ le rendement bepaald? l Is het gewenste financie l Zijn de kosten gedetailleerd per te verrichten activiteit? Zijn deze realistisch? l Zijn de vaste kosten (bijvoorbeeld machines, licenties) bepaald? Zijn deze realistisch? l Zijn de totale kosten ingeschat? l Zijn er marges ingebouwd? l Is het budget onderverdeeld in periodes? l Is het budget goedgekeurd? l Zijn de benodigde investeringsvoorstellen uitgegaan?

Organisatie

l

l

l l

l l

l

Bevat het projectplan een duidelijke organisatiestructuur van het project (inclusief opdrachtgever, projectteam, werkgroepen, etc.)? Zijn de taken, verantwoordelijkheden en bevoegdheden helder gedefinieerd? Bevatten ze geen overlappingen? Is een team/werkgroep verantwoordelijk voor een afgerond resultaat? Is de relatie tussen moederorganisatie en project duidelijk? Zijn er duidelijke overlegstructuren aanwezig die zorgt dat benodigde uitwisseling van informatie en meningen ontstaat? Zijn de projectmedewerkers zorgvuldig geselecteerd en vullen ze elkaar aan qua kennis en ervaring?

afl. 43 (juni 2012)

5314-32

Auditvariabelen


Informatie

l l

l l

l l

Risico’s

Is geı¨dentificeerd welke informatie beheerd moet worden? Zijn er afspraken gemaakt over het centraal archiveren van documenten? Is er een afspraak gemaakt over het te gebruiken systeem? Zijn er afspraken gemaakt over het uniek coderen van documenten? Is er een afspraak voor het wijzigen van documenten? Zijn er afspraken gemaakt met betrekking tot klachten en escalaties?

Is bepaald welke risico’s zich voor kunnen doen? Is dit overzicht van de risico’s volledig? l Is de impact van de risico’s op het project en de organisatie bepaald? l Is bepaald wat de kans is dat de risico’s zich voordoen? ¨dentificeerd (kans van voordoen * l Zijn de grootste risico’s geı Impact)? l Zijn er voor de grootste risico’s passende maatregelen genomen ? – Voor verkleinen kans van optreden? – Voor verkleinen impact? – Early Warning System? l l

Activiteiten

Bij de activiteiten zal de auditor naast het vaststellen dat er activiteiten bepaald zijn in het projectplan ook vast dienen te stellen dat de gekozen aanpak voldoet om het beoogde resultaat te bereiken. l Is waar mogelijk gebruik gemaakt van standaardwerkwijzen van de organisatie of uit de literatuur? l Is er een fasering aangebracht in de activiteiten, waarbij iedere leidt tot een concreet resultaat? l Is bepaald welke activiteiten dienen te worden uitgevoerd om het resultaat te bereiken? l Is per activiteit bepaald en beschreven: – Doel en resultaat activiteit; – Werkwijze & hulpmiddelen; – Betrokkenen; – Bewerkingstijd?

afl. 43 (juni 2012)

5314-33

Auditvariabelen


Omgeving

l

l l l

l l

Is de communicatiestrategie bepaald (bijdrage communicatie aan project, kiezen voor eigen logo, standaarddocumenten, enz.)? Zijn er doelgroepen onderkend? Is per doelgroep bepaald wat het communicatiedoel is? Is per doelgroep bepaald waarover en op welke manier men geı¨nformeerd wil worden? Wordt de moederorganisatie betrokken bij de communicatie? Is er een expliciete afspraak gemaakt over de voortgangsrapportage aan de opdrachtgever?

afl. 43 (juni 2012)

5314-34

Soorten Projectaudits

Recommend Documents