Kwantitatieve risicoanalyse it-projecten

 1. Inleiding handleiding risicoanalyse IT

Deze handleiding is bedoeld voor alle medewerkers die betrokkenen worden bij het uitvoeren van een risico analyse, en met name voor de medewerker die de leiding geeft aan de uitvoering van de project risico analyse.
De handleiding geeft een inzicht in de wijze waarop potentiële risico’s kunnen worden gemeten, geanalyseerd, gewogen en gerapporteerd. De noodzaak voor uitvoering van de analyse komt niet aan de orde.

Hoofdstuk 2 gaat in op de doelgroep, de begrenzing en het resultaat van een risico analyse.

Hoofdstuk 3 gaat in op het hulpmiddel dat wordt gebruikt bij risico analyse:
de vragenlijsten.

In hoofdstuk 4 wordt uiteengezet hoe de risico analyse als activiteit binnen het project moet worden uitgevoerd.

Hoofdstuk 5 gaat in op de analyse en weging van gemeten risico’s.

In hoofdstuk 6 worden de vragenlijsten in verband gebracht met de fasen in een project. 

2. Doelgroep, beperkingen en resultaat risico analyse

2.1 Doelgroep

De project risicoanalyse is een activiteit die een bijdrage levert aan de tijdige onderkenning van risico’s verbonden aan een project.
Deze syllabus is primair bedoeld voor de medewerker die de leidinggevende rol vervult in de project risico analyse: de gespreksleider. Voor alle overige betrokkenen in het project verschaft deze syllabus inzicht in het doel en gebruik van de project risico analyse.
In het algemeen wordt de rol van gespreksleider vervuld door een projectmanager of door een functionaris die erin is gespecialiseerd. Aangezien de vragenlijsten onderverdeeld zijn in aandachtsgebieden, kan de risico analyse, zij het in beperkte mate, eveneens uitgevoerd worden door de projectleider van elk aandachtsgebied.

2.2 Beperkingen project risico analyse

De volgende beperkingen worden onderkend:

• De project risicoanalyse in deze syllabus gaat niet in op de toegevoegde waarde van het project voor de organisatie.
• De project risicoanalyse in deze syllabus is alleen bedoeld voor IT-projecten.
• De project risicoanalyse in deze syllabus gaat niet in op de prioriteit van een project.
• De project risicoanalyse in deze syllabus is niet bruikbaar voor exploitatie en beheer.

2.3 Het resultaat van de project risico analyse

De tijdens de analyse vastgestelde bevindingen worden vastgelegd in een rapport dat minimaal de volgende onderwerpen omvat:

• de formulering van de opdracht;
• de beschrijving van het project;
• de onderkende risico’s;
• aanbevelingen. 

 3. De vragenlijst voor uitvoering risico analyse

Als hulpmiddel voor de project risicoanalyse zijn vragenlijsten ontwikkeld, die elk een bepaald aandachtsgebied bestrijken. Elke lijst bevat vragen over onderwerpen die een potentieel risico vormen voor het project. Aan elke vraag is een limitatieve opsomming van mogelijke antwoorden toegevoegd. Natuurlijk zijn er ook andere vragenlijsten in omloop. Belangrijkste doel van de vragenlijst is dat alle onderdelen van het project geraakt worden. De kwantitatieve berekening van de risicowaarde van een project is niet erg betrouwbaar. Laat deze eindwaardering dan ook niet over aan het team dat betrokken is bij de risicoanalyse, maar laat deze over aan de auditor (voorzitter van de sessie) zelf, nadat de deelnemers hun mening over de projectrisico’s hebben onderbouwd. Het doel van de vragenlijst is er voor te zorgen dat:

• voor het meten van project risico’s de juiste vragen worden gesteld;
• vragen en antwoorden op de juiste wijze worden gewogen;
• de combinatie van vraag en antwoord op een juiste wijze wordt vertaald naar een risico voor het project;
• gemeten risico’s in het project gerelateerd kunnen worden aan normen die zijn ontleend aan ervaringen uit eerder uitgevoerde projecten.

3.1 Aandachtsgebieden IT-project risicoanalyse

Elk aandachtsgebied omvat een traject, respectievelijk een fase van een project. De volgende aandachtsgebieden zijn onderkend:

• pre-offerte;
• naar aanleiding van een offerte aanvraag, voorafgaand aan het uitbrengen van een offerte;
• offerte;
• tijdens het offerte traject uit te voeren; de resultaten moeten in de offerte worden meegenomen;
• contract;
• na het offerte traject, tijdens de contractbesprekingen en voor het afsluiten van het contract;
• uitvoering;
• tijdens de uitvoering van het project, doch in iedere geval op de volgende momenten:
  • bij de aanvang van het project;
  • tijdens de afronding van een plan van aanpak per fase;
  • bij één derde van het totale traject;
  • bij afsluiting van het project.

Bij de uitvoering van het project is een verdere onderverdeling van de vragenlijst aanwezig naar sublijsten, gericht op de functionarissen die verantwoordelijk zijn voor:

• projectmanagement;
• inhoudelijke coördinatie;
• projectbureau;
• kwaliteitsbureau;
• systeemontwikkeling;
• gebruik;
• beheer;
• evaluatie.

3.2 Analyse gebieden IT-projecten

De vragen op elke lijst zijn naar analyse gebieden gegroepeerd. Een analyse gebied omvat alle vragen die gericht zijn op een bepaalde invalshoek waarmee naar het project wordt gekeken. De volgende analyse gebieden worden onderkend:

• de conditionering:
  Zijn de doelstellingen van het te ontwikkelen informatiesysteem en het project duidelijk geformuleerd? Wat moet er gebeuren en wat niet? Zijn de afbakening van het project, de opdracht, de omvang en de doelgroep voldoende vastgelegd?
• het proces:
  In hoeverre is de gebruiker betrokken in het proces? Zijn er communicatieplannen? Is voldoende rekening gehouden met de conversie, de implementatie en het toekomstig beheer?
• het eindresultaat:
  Is het eindresultaat voldoende gedefinieerd? Zijn de gestelde eisen ten aanzien van de kwaliteit vastgelegd? Is voldoende rekening gehouden met het accepteren van dit resultaat?
• de besturing van het project:
  Hoe wordt het project bestuurd? Zijn er planningsmethoden van toepassing? Hoe wordt de voortgang bewaakt? Zijn er projectrapportages voorzien? Zijn de controle- en beoordelingsmogelijkheden bekend?
• de inrichting van het project:
  Hoe wordt het project georganiseerd? Zijn de taken en verantwoordelijkheden binnen de projectorganisatie gedefinieerd en op schrift gesteld? Zijn op alle niveaus zowel kwantitatief als kwalitatief de juiste medewerkers betrokken? Zijn er duidelijke afspraken over de toe te passen standaards en richtlijnen? Zijn er nieuwe tools of hardware?
• de projectomgeving:
  Is er een complexe externe regelgeving van toepassing? Wijzigt deze regelgeving gedurende het project? Heeft het systeem veel interfaces naar andere systemen of naar resultaten van andere projecten? Zijn er veel organisatieonderdelen betrokken bij het project? Is er tevens een grote reorganisatie gepland? Staat het topmanagement achter het project?

In het artikel ‘Vragenlijst kwantitatieve projectrisicoanalyse IT’ wordt een voorbeeld van een vragenlijst gegeven, die redelijk generiek bruikbaar is. Veelal is het de auditor als voorzitter, die op basis van zijn professionaliteit de belangrijkste items selecteert. In dat geval is uiteraard de kwantificering van het project in een risicowaarde niet meer dan een indicatie, op basis waarvan aanbevelingen geformuleerd worden. 

4. Uitvoeren project risico analyse

Het uitvoeren van de risicoanalyse vindt volgens onderstaande fasering plaats:

• voorbereiding;
• afbakenen van de project risicoanalyse opdracht;
• bepalen van de doelstelling van de project risicoanalyse opdracht;
• selecteren van deelnemers aan de opdracht;
• selecteren van de aandachtsgebieden;
• plenaire zitting;
• voorstellen van de deelnemers;
• introduceren van de te volgen methodiek;
• geven van een overzicht van het project;
• invullen van de vragenlijsten;
• rapportage en afronding.

4.1 Voorbereiding risico analyse

De volgende activiteiten worden uitgevoerd:

• afbakenen van de project risicoanalyse opdracht:
  Een zo goed mogelijke afbakening van de project risicoanalyse opdracht is de eerste en belangrijkste activiteit bij de inhoudelijke voorbereiding. Met de opdrachtgever van de risicoanalyse moet duidelijk worden afgesproken of het hele project dan wel een bepaald deelproject onderwerp van de risicoanalyse is.
• bepalen van de doelstelling van de project risicoanalyse opdracht:
  Initieel wordt de doelstelling van de uit te voeren risicoanalyse bepaald. Vastgesteld moet worden of alleen algemene risico’s dan wel specifieke risico’s moeten worden geanalyseerd. Criteria voor het vaststellen van te analyseren risico’s zijn de randvoorwaarden en doelstellingen van het project.
• selecteren van deelnemers aan de opdracht:
  De selectie van de deelnemers aan de risicoanalyse hangt af van de fase waarin het project zicht bevindt. Het is belangrijk dat naast vertegenwoordigers uit het project tevens vertegenwoordigers van de gebruikersafdelingen aanwezig zijn.

Onderstaand is een overzicht van kandidaat deelnemers opgenomen:

• projectmanagementteam;
• opdrachtgever;
• stuurgroep (vertegenwoordiging);
• projectteam (vertegenwoordiging);
• gebruikers (vertegenwoordiging);
• beheerders (vertegenwoordiging);
• overige belanghebbenden.

4.2 Selecteren van de aandachtsgebieden

In overleg met de opdrachtgever wordt vastgesteld welke aandachtsgebieden voor de analyse van toepassing zijn. Standaard passeren alle aandachtsgebieden de revue. Van belang is na te gaan of in het kader van de opdracht alle aandachtsgebieden noodzakelijk zijn. Het stellen van vragen die niet van toepassing zijn tijdens de plenaire zitting roept onnodige irritatie bij de deelnemers op.

4.3 Plenaire zitting om projectrisico’s te bepalen

De plenaire zitting vormt de belangrijkste fase van de risico analyse. Geadviseerd wordt om de doorlooptijd van de plenaire zitting maximaal 4 uur te laten bedragen. De sessie moet bovendien in een aangesloten zitting plaatsvinden.
De gespreksleider vervult een belangrijke rol in deze zitting. Hij begeleidt het proces en neemt in geval van onenigheid tussen de deelnemers de beslissingen.
Tijdens de plenaire zitting worden de volgende activiteiten uitgevoerd:

• voorstellen van de deelnemers:
  Aan het begin van de zitting stelt iedere deelnemer zich kort voor. Het is van belang te weten welke rol iemand in het project en bij de risicoanalyse vervult.
• introduceren van de te volgen methodiek:
  De voorzitter geeft een korte uiteenzetting van de methodiek van de project risico analyse. Hierbij wordt tevens behandeld welke voorselecties hebben plaats gevonden op basis van de opdracht, de projectafbakening, de geselecteerde aandachtsgebieden. Het moet voor iedere deelnemer duidelijk zijn wat de doelstelling van de plenaire zitting is.
• geven van een overzicht van het project:
  De projectmanager geeft een overzicht van het project tot nu toe. Hierbij komen de volgende vragen aan bod:
  • Voor welke organisatie wordt het project uitgevoerd?
  • Wat is het doel van het project?
  • Wat is de relatie naar andere deelprojecten?
  • Wat is er tot nu toe gebeurd?
  • Wat is op korte termijn gepland?
  • Wat is de status van het project?
  • Welke problemen of knelpunten zijn er?
• invullen van de vragenlijsten:
  Het invullen van de vragenlijsten houdt in het beantwoorden van alle vragen van de geselecteerde vragenlijst. Voor een volledige lijst is 2 tot 4 uur nodig. Bij onenigheid tussen de deelnemers beslist de voorzitter over de beantwoording van de vraag. Een te snelle beantwoording van de vragen is niet gewenst. Het gezamenlijk beantwoorden van de vragen is een wezenlijk onderdeel van de analyse. Het is een noodzakelijke voorwaarde voor het bereiken van een gemeenschappelijk commitment.

4.4 Rapportage en afronding risico analyse

Tijdens de rapportage en afronding worden de volgende activiteiten uitgevoerd:

• berekenen van de score:
  Het berekenen van de score wordt in het volgende hoofdstuk beschreven.
• maken van een verslag van de plenaire zitting:
  De voorzitter van de plenaire zitting zorgt voor een verslag van het proces. Specifieke aandacht wordt besteed de volgende aspecten:
  • de vragen waarover bij de beantwoording geen overeenstemming tussen de deelnemers kon worden bereikt;
  • de acties die de deelnemers hebben afgesproken om een vraag beter te kunnen waarderen;
  • het algemene procesverloop;
  • het waarderen van de risico’s.

Aan de hand van de ingevulde scores op de vragenlijsten worden de risico’s geïdentificeerd. Vragen die hoger scoren dan 12 behoeven extra aandacht. In dergelijke gevallen is bijna altijd sprake van een risico voor het project. Voor het bepalen van risico’s worden eveneens scores van de vragenlijst per groep of per subgroep geanalyseerd. Als de (sub)groep van vragen hoger scoort dan de aangegeven norm, dan is sprake van een verhoogd risico voor het project.
Het is de taak van de projectleiding ervoor de te zorgen dat de geïdentificeerde risico’s en de daaruit voortvloeiende maatregelen op hoog niveau in de project controle worden bewaakt.

4.5 Rapportage en conclusies

Het eindrapport van een risicoanalyse bevat:

• een korte schets van de opdracht en de motivatie voor de risico analyse;
• een schets van het project;
• de geplande looptijd;
• de informatieve kengetallen uit het project;
• een grafisch overzicht van de scores per groep;
• een beschrijving van elke vraag met een verhoogd risico voor het project;
• een verslag van de plenaire zitting;
• aanbevelingen. 

 5. De score van de ICT-project risico analyse

Zoals eerder gezegd is dit meestal meer dan een rekensommetje, omdat deelnemers aan zo’n risicoanalyse sterk geneigd zijn om hun eigen risico’s te laag in te schatten en de risico’s. waar anderen verantwoordelijk voor zijn te overschatten. Een puur kwalitatief gebruik van de vragenlijst is dan ook een serieuze optie. Onderstaand echter toch ook het kwantitatieve model.
Aan elke vraag is een wegingsfactor toegekend, die van invloed is op de mate waarin het onderwerp van de vraag een risico vormt voor een project. Tevens is op de lijst bij elke vraag een limitatieve opsomming van antwoorden toegevoegd, waaruit een keuze moet worden gemaakt. Aan elk antwoord is een risico factor toegekend. Door de wegingsfactor van elke vraag te vermenigvuldigen met de risico factor van het gekozen antwoord op de vraag, wordt de risico waarde berekend. De risico factoren en wegingsfactoren zijn zodanig vastgesteld, dat een hoog risico overeenkomt met een hoge waarde en een laag risico met de waarde 0.

5.1 Berekenen van de risicowaarde van het IT-project

De score van een groep, analysegebied of aandachtsgebied kan als volgt worden berekend:

• totaliseer de berekende risico waarden van alle vragen uit een groep, analysegebied of aandachtsgebied;
• druk het berekende totaal uit als percentage van de maximum score uit de groep, het analysegebied of het aandachtsgebied.

Het is van belang alle vragen uit een groep, analysegebied of aandachtsgebied te beantwoorden. Het overslaan van een vraag heeft hetzelfde effect als het toekennen van de risico waarde 0 aan de vraag.

5.2 Vergelijken met de normen

Vragen die hoger scoren dan 12 duiden in vrijwel alle gevallen op een verhoogd risico. De score van een groep, analysegebied of aandachtsgebied wordt vergeleken met de volgende normen:

• Als de score ligt tussen 0% en 40%, dan is er sprake van laag risico.
• Als de score ligt tussen 40% en 60%, dan is er sprake van een verhoogd risico.
• Als de score ligt tussen 60% en 100%, dan is er sprake van een hoog risico.

Voor het totale project gelden andere normen:

• Als de score van het totale project ligt tussen 0% en 25%, dan is er sprake van laag risico.
• Als de score van het totale project ligt tussen 25% en 50%, dan is er sprake van een verhoogd risico.
• Als de score van het totale project ligt tussen 50% en 100%, dan is er sprake van een hoog risico.

Als vuistregel geldt, dat voor een project met een laag risico standaard 10% extra budget en doorlooptijd wordt gecalculeerd.
Voor projecten met een verhoogd risico wordt het risicopercentage een-op-een doorvertaald in een opslagpercentage voor zowel budget als doorlooptijd.
Projecten met een hoog risico zullen waarschijnlijk mislukken en in deze gevallen zal eerst het risicopercentage teruggebracht moeten worden naar een acceptabele waarde.
Zoals echter eerder al is betoogd zal de kwaliteit van de risicoanalyse sterk afhangen van de kwaliteit van de voorzitter van de plenaire sessie. Per definitie geldt, dat het gebruik van een ICT-kwaliteitshandboek het projectrisico sterk kan verminderen.
Het voorbeeld bestaande uit 3 delen is tenslotte ontwikkeld vanuit een generieke project risicoanalyse.