Hoe kan ik risico’s en hun impact inschatten? #anticiperen

1 Inleiding en leerdoel

Het beheren en beheersen van risico’s is jammer genoeg een activiteit die nog altijd te weinig aandacht krijgt van de projectmanager en het ganse projectteam. Risicobeheer laat ons toe de toekomst in te schatten en er bijgevolg op te anticiperen. Een efficiënt risicobeheer moet toelaten tijd en ademruimte te creëren, en zo de kans verhogen dat we het project op de rails houden. Risicobeheer gaat per definitie over onzekerheid. Aangezien projecten niet op een eiland worden uitgevoerd, worden ze geconfronteerd met onzekere factoren.

In dit hoofdstuk willen we duiden welke onzekerheden echt belangrijk zijn, hoe je risico’s echt kunt detecteren en vooral, welke risico’s je eerst aanpakt en hoe je dat doet.

Op het einde van dit hoofdstuk:

… begrijp ik het belang van een risicobeheer;

… ben ik vertrouwd met de stappen die mijn team zal doorlopen om goed te anticiperen;

… kan ik de tools gebruiken die me helpen concreet met risico’s om te gaan.

2 Omgaan met onzekerheid op projecten

2.1 Definities

Er zijn veel onzekere factoren binnen of rond ons project. Het gegeven dat ons project niet op een eiland wordt uitgevoerd, werkt dat zeker in de hand, maar niet alle onzekere elementen zijn belangrijk voor ons project. Het is daarbij belangrijk om onze aandacht te richten op die onzekerheden die relevant zijn voor ons project. We vertrekken met een onderscheid te maken tussen onzekerheden en risico’s. Onderstaand voorbeeld maakt onze focus duidelijk.

VOORBEELD

Het is perfect mogelijk dat het in de nabije toekomst sterk zal stormen in Indië, al dan niet met overstromingen en stormschade tot gevolg. Die mogelijke storm is overduidelijk een onzekerheid. Aangezien mijn project wordt uitgevoerd voor en bij een Belgische onderneming, zonder enige band met Indië, zal die onzekerheid mij niet doen wakker liggen. Die onzekerheid leidt met andere woorden niet tot een directe dreiging of risico.

Anderzijds bestaat de kans dat de Belgische winter onverwacht het wegennet onbruikbaar maakt en het treinverkeer blokkeert. Het winterweer is in een Belgische context een onzekerheid. Als mijn projectteam verplicht in de kantoren van de klant dient te werken, kan die moeilijk te voorspellen gebeurtenis voor grote problemen zorgen tijdens de kritieke fases van mijn project. Mocht die onzekerheid zich voordoen, hebben we dus een impact. Dat maakt die onzekerheid wel een risico.

We dienen de onzekerheden dus weg te filteren op basis van de impact die ze kunnen hebben. We volgen in dit boek volgende definitie:

Risico’s zijn onzekerheden die een invloed hebben op de projectobjectieven. Onzekerheden die de projectobjectieven mogelijk beïnvloeden, dienen we correct te managen. Die discipline noemen we projectrisicobeheer.

In tegenstelling tot de algemene gedachtegang en ondanks de negatieve bijklank, hoeven risico’s niet enkel negatieve gevolgen te hebben. Dat onderscheid maken we door de juiste terminologie te hanteren: negatieve risico’s noemen we bedreigingen, positieve risico’s noemen we opportuniteiten

Risicobeheer is een continue activiteit op projecten. Als projectmanager kijk je m.a.w. niet enkel bij het begin of ‘nu en dan’ eens even naar risico’s. Je houdt dat het best continu en op gezette tijdstippen op de agenda. Projectmanagers moeten dus vermijden te vervallen in het concept van risk season, waarbij ze enkel bij de start of bij het rapporteren van de status naar de risico’s kijken. Risicobeheer mag geen eenmalige focus zijn. Dat zou namelijk gevaarlijk kunnen zijn. De onzekerheden zouden kunnen wijzigen of de impact van een risico zou plots kunnen vergroten. Bijgevolg raden we echt aan om als projectmanager op regelmatige basis naar de risico’s op je project te kijken!

Al tijdens het plannen van het project doorlopen we noodzakelijke stappen rond risicobeheer. Op die manier proberen we ons voldoende vroeg voor te bereiden en ons in de mogelijkheid te stellen tijdig te anticiperen. Onderstaande paragrafen verduidelijken de belangrijkste stappen.

VOORBEELD

Een verdeler van sanitair materiaal wenst stappen te zetten in zijn digitalisering. Daartoe wordt beslist een CRM-systeem in te voeren om zijn vertegenwoordigers (verkopers) op één platform te laten werken dat altijd en overal toegankelijk is, ook op hun mobiele toestellen.

Bij het initiëren van het project bepaal je de requirements en tracht je een eerste tijdslijn uit te tekenen. Het is dan aan te raden om voor elke deliverable te evalueren hoe risicogevoelig de realisatie is. Als je bijvoorbeeld voorziet om uitgebreid training te geven, maar de verkopers zijn zeer onbekend met digitale tools of werken verspreid over meerdere landen, dan kan dat mogelijk leiden tot meer complexiteit in de organisatie en dus een langere doorlooptijd.

Door dat risico te benoemen en gepast te beantwoorden bij het inplannen van die deliverable, anticipeer je dus op een mogelijk negatief effect.

2.2 Risicobeheer plannen

Zoals voor elk deelgebied van de projectcyclus, moeten we ook voor risico’s eerst bepalen hoe we ze zullen benaderen. Het risicomanagementplan beschrijft m.a.w. hoe je op jouw project zal omgaan met risicomanagement. Op grote projecten maak je een specifiek plan en heb je de vrijheid en de tijd om dat zelf op te maken. Op kleinere, digitale initiatieven of in een sterke agile omgeving, is het aangeraden dat de PMO een centrale richtlijn aanreikt die aangeeft hoe op die initiatieven naar risico’s wordt gekeken.

Volgende tabel geeft een overzicht van de elementen die in het kader van het risicomanagementplan beschreven moeten worden.

Tabel 1 Mogelijke inhoud van het risk managementplan.

Onderdeel risicomanagementplan Omschrijving

Identificatie: plan van aanpak

Beschrijving hoe we binnen het project risico’s identificeren. Daarbij kunnen we terugvallen op de technieken die we in de volgende paragraaf beschrijven.

Naast de technieken moeten we ook definiëren welke tijdlijn we zullen volgen met betrekking tot risico-identificatie. Risk identification is iets wat elke week kan ingepland worden of, zoals vaak op grote projecten, elke maand of elk kwartaal.

Tot slot dienen we ook te beschrijven hoe we de risico’s zullen bijhouden, met andere woorden hoe ons risicoregister er zal uitzien.

Evaluatie: plan van aanpak

We kunnen niet alle risico’s dezelfde aandacht geven. Focus is belangrijk. Daarom moeten we regels vastleggen die ons toelaten om prioriteiten te stellen.

Daarbij dienen we vast te leggen hoe we de probabiliteit en de impact zullen inschatten. Hoe objectiever we die inschatting kunnen maken, hoe doeltreffender we de risico’s kunnen beoordelen. De schaal leunt best zo dicht mogelijk aan bij de objectieven van het project.

We beschrijven in het risicomanagementplan eveneens of we de evaluatie ook grafisch willen weergeven met behulp van een probabiliteit-impact-matrix.

Organisatie We kunnen kiezen om voor risicobeheer specifieke rollen en verantwoordelijkheden vast te leggen binnen het project. Zo kan een lid van het projectmanagementteam tot risk manager benoemd worden. Hij bewaakt dan de correcte uitvoering van de gerelateerde activiteiten.

Budgettering Het riskmanagementplan moet eveneens instructies geven hoe risicobeheer geïntegreerd wordt in de budgetbepaling. Hier verwijzen we bijvoorbeeld naar het hoofdstuk ‘Hoe kan ik een realistische prijs bepalen voor mijn initiatief? #inschatten’ met betrekking tot contingency-bepaling.

Rapportering We leggen vast welke elementen uit het riskregister we zullen rapporteren (aan het team, aan de stuurgroep …) en met welke frequentie.

Het opmaken van een risk managementplan verplicht ons om na te denken hoe we zullen omgaan met de onzekerheden die ons project zullen beïnvloeden. De volgende stappen verduidelijken hoe dat plan van aanpak in de praktijk gebracht wordt. Als projectmanager kun je kiezen om alle of slechts enkele voorgestelde technieken te gebruiken. Die pragmatische invulling bepaal je in functie van de aard van jouw project (bv.: complex, early adopter qua geïmplementeerde technologie, …) en de risicogevoeligheid van de organisatie. Het is echter van cruciaal belang dat elk proces dat we zullen beschrijven, minstens eenmaal per projectfase wordt doorlopen.

3 Risico’s identificeren

Risico’s identificeren betekent onzekerheden vinden die het project mogelijk impacteren. Elk lid van het projectteam, niet enkel het projectmanagementteam, moet dagelijks de ogen en de oren open houden voor risico’s. Risico’s met een grote impact kunnen verscholen zitten in kleine events. Het is dan ook de taak van de projectmanager om ervoor te zorgen dat zijn team getraind en alert is om projectrisico’s te onderkennen.

De output van dat proces is een samenvattende lijst van alle gevonden risico’s. Die lijst noemen we het riskregister. Het is echter wel belangrijk om het risico juist te omschrijven. Het risico dient namelijk de onzekere gebeurtenis te omschrijven, niet de oorzaak en niet het gevolg. Tegen die regel wordt in de praktijk vaak gezondigd. Daarom maken veel riskregisters een onderscheid tussen cause

(vaststaand feit of vaststelling), risk (onzekere gebeurtenis) en effect (mogelijk gevolg indien het risico zich voordoet). Door die drie elementen naast elkaar te plaatsen wordt men aangezet om de risico’s correct te beschrijven. Voor het neerschrijven van risico’s wordt aangeraden uitdrukkingen te gebruiken die de onzekerheid benadrukken, zoals ‘mogelijk’, ‘kunnen gebeuren’, ‘misschien’, ‘eventueel’, ‘de kans bestaat’ … Hieronder wordt een summier voorbeeld gegeven. Merk op dat op vele projecten de ‘vaststelling’ (het feit) onterecht als risico zou genoteerd staan.

Voorbeeld

Vaststelling: we gebruiken een nieuwe technologie op ons project. Onzekere gebeurtenis: het team beschikt mogelijk niet over voldoende technische kennis of ervaring met die technologie.

Effect: hoger aantal issues, veel work-arounds geïmplementeerd, langere doorlooptijd voor implementatie …

Het risico is de mogelijk gebrekkige of afwezige kennis. Dat moet onderzocht en eventueel aangepakt worden om het project niet in gevaar te brengen.

Om deze oefening goed uit te voeren kunnen we een aantal technieken toepassen. Het spreekt voor zich dat het identificeren van risico’s een tijdrovende bezigheid kan zijn, zeker wanneer gekozen wordt voor technieken die betrekking hebben op het volledige team. Daarom moet goed nagedacht worden hoe vaak deze groepssessies worden voorzien. Op basis van onze praktijkervaring willen we twee technieken onder de aandacht brengen.

3.1 Risk Identification Sessions

De eerste en eenvoudigste techniek baseert zich op groepsdynamiek. Het organiseren van risk identification sessions is erg nuttig en zorgt vaak voor lange lijsten risico’s. Het is de bedoeling het team geheel of gedeeltelijk samen te brengen en via brainstorming of een groepsdiscussie de onzekerheden van het project bloot te leggen.

Tips & Tricks uit de praktijk:

Die oefening kan gefaseerd gebeuren, waarbij de juiste mensen voor een bepaald onderdeel van de scope worden samengebracht. Als je wilt kijken naar risico’s binnen de supply chain scope, dan hoeven misschien de mensen van de boekhouding niet deel te nemen. Merk op dat het hier vooral gaat om het identificeren van risico’s en niet om het scoren of evalueren.

– Voor veel deelnemers kan deze sessie nieuw zijn, bereid die daarom goed voor. Leg tijdens de introductie goed uit wat het doel is en hoe je als projectmanager zal faciliteren. Geef ook mee wat de verwachtingen zijn van de deelnemers.

Om de sessie te structureren kan het helpen om je te baseren op de deliverablelijst. Zo kun je stilstaan bij elk stukje scope en in groep beoordelen hoe ‘onzeker’ de uitvoering is en wat die onzekerheid stuurt.

– Groepsessies hebben het voordeel dat ze veelal een goede dynamiek en kruisbestuiving teweegbrengen. Samen vind je meer dan alleen. Maar wees erg aandachtig voor negatieve vibes tussen de deelnemers. Benoem duidelijk dat dergelijke sessies gebaat zijn bij constructieve input en positieve dialoog.

Maak notities tijdens de sessie en duid daartoe een penhouder aan. Maar zorg dat het noteren van de input geen rem wordt op de sessie. M.a.w. besteed niet te veel aandacht aan taal en lay-out tijdens de sessie. De notities ‘opkuisen’ kun je als penhouder later doen voor je de notities deelt.

3.2 A&C-Analyse

Doorheen het volledige project, zeker bij het opmaken van het projectplan, baseren we ons op veronderstellingen (assumpties) of worden er beperkingen (constraints) opgelegd. Een doeltreffende techniek om je projecten te beschermen, evalueert die veronderstellingen of beperkingen. We spreken over een assumption & constraint-analyse ( A&C-analyse).

Het volstaat om twee vragen te stellen:

Voor assumpties:

• Vervalt de veronderstelling?

• Heeft de veronderstelling een directe invloed op de projectobjectieven?

– Voor constraints:

• Kunnen we de beperking afzwakken?

• Heeft de veronderstelling een directe invloed op de projectobjectieven?

Als op beide vragen positief wordt geantwoord, dienen we een risicostatement te maken aangezien het project mogelijk positief of negatief beïnvloed wordt. Veelal maken we een eenvoudige tabel op ter ondersteuning van die analyse. We geven nog mee dat voor veronderstellingen die vervallen, de impact veelal negatief is. Terwijl een beperking die afgezwakt wordt, eerder positieve gevolgen zal hebben voor het project. De tabel hieronder geeft weer hoe je die analyse kunt documenteren.

Veronderstelling / Beperking

(veronderstelling)

Hardware zal geleverd en beschikbaar zijn bij de start van het project.

(veronderstelling)

De applicatie wordt enkel voorzien voor gebruik met onlinetoegang.

(beperking)

De klant wil dat de applicatie einde Q2 beschikbaar is.

(veronderstelling)

Project wordt uitgevoerd in de kantoren van de klant in Brussel.

Vervalt de veronderstelling? Kunnen we de beperking afzwakken?

Impact op projectobjectieven?

Risicostatement

Y Y Een late levering van de hardware kan leiden tot vertraagde start die mogelijk niet ingehaald kan worden.

Y Y Mogelijk moeten ook andere toegangs- en gebruiksmogelijkheden aangeboden worden (zoals offlinemodus of een desktop-app). Dat kan leiden tot bijkomend werk.

Y Y Mogelijk uitstel door vervallen van de deadline einde Q2 geeft het projectteam meer tijd om de applicatie op te leveren.

Y Y Omdat ook andere (internationale) vestigingen bediend moeten worden, worden we mogelijk geconfronteerd met bijkomende reiskosten en dus budgetimpact.

Bovenstaande voorbeelden tonen een zeer belangrijk principe aan. Veronderstellingen worden door het projectteam zelf bepaald. Dat doen we om het project te beschermen. Als die veronderstellingen dreigen te vervallen, betekent dat dat het project een stuk bescherming verliest. Het vervallen van een veronderstelling leidt dan ook tot het identificeren van een bedreiging (negatief risico). Anderzijds is het de buitenwereld, vaak via de klant, die beperkingen oplegt. Als een beperking losgelaten kan worden, is dat goed nieuws voor het project. Daarom leidt de analyse van beperkingen tot het identificeren van opportuniteiten (positief risico).

4 Prioriteiten stellen

De beschreven technieken leiden tot een goed gevuld riskregister. Het is echter onmogelijk om alle risico’s met dezelfde aandacht op te volgen. Daarom moeten we prioriteiten stellen. Daarvoor grijpen we terug naar de principes van de kwalitatieve analyse zoals het PMI ze voorschrijft.

De prioriteiten worden door drie parameters bepaald:

1. Wat is de kans dat het risico zich voordoet?

2. Wat is de impact van het mogelijke risico op de projectobjectieven?

3. Wanneer kan het risico zich voordoen?

Voor de eerste twee vragen hanteren we de schaal zoals we ze in het riskmanagementplan hebben vastgelegd. Om die analyse leesbaar te maken, zetten we de resultaten uit in een grafiek. Die weergave noemen we de probability/impact grid (PIG ). Volgende figuur toont een voorbeeld.

De ‘kleurvakken’ in de PIG tonen onmiddellijk welke risico’s onze aandacht verdienen. In de praktijk splitsen we de risico’s vaak op in drie categorieën.

– Risico’s die rechts, in de donkergrijze (rode) zone vallen, die vragen onze onmiddellijk aandacht. Vaak worden die risico’s toegewezen aan een individuele eigenaar, die het risico verder behandelt en opvolgt.

– Risico’s die in het midden, in de lichtgrijze (oranje) zone liggen, zijn belangrijk genoeg om op te volgen. In de praktijk worden ze vaak toegewezen aan het projectmanagementteam.

– De middelgrijze (groene) risico’s aan de rechterkant achten we niet cruciaal. Ze zullen dan ook niet actief beheerd worden.

Zowel voor negatieve als voor positieve risico’s hanteren we dezelfde kleurencode. Dat is mogelijk omdat rood in deze filosofie niet per se als negatief mag worden aanzien. Een rode score betekent dat het risico, de bedreiging of de opportuniteit, onze onmiddellijke aandacht vereist.

We herhalen dat deze analyse geen eenmalige oefening is. We maken de evaluatie voor alle risico’s op regelmatige basis opnieuw. Afhankelijk van het type risico kan de frequentie van de controle verschillen, maar geen enkele categorie mag vergeten worden. Dat is een belangrijk onderdeel van de monitoring binnen risicobeheer. Het is namelijk zeer gebruikelijk dat de kans of de impact van een risico sterk verandert door het project heen, al dan niet door de acties die worden genomen om het risico te beheersen.

We spraken nog niet over de tijdsdimensie van risico’s. Wanneer een risico zich kan voordoen, is echter wel een belangrijk element om te oordelen hoe dringend we dienen te handelen. Die parameter wordt vaak ook de risk proximity (nabijheid) genoemd. De nabijheid van een risico is een belangrijk criterium wanneer we volop inzetten in kortlopende (digitale) initiatieven. Cru gesteld krijgt een risico vaak niet de kans een issue te worden (dus zich te manifesteren), aangezien op dat moment ons initiatief of onze sprint al is opgeleverd. We onderlijnen echter wel dat dat absoluut niet betekent dat een kortlopend initiatief niet gebaat is bij risicobeheer.

5 Omgaan met risico’s

Zodra risico’s geïdentificeerd zijn en we de prioriteiten hebben vastgelegd, trachten we in een volgende stap een antwoord te definiëren op de onzekerheden die ons project positief of negatief kunnen beïnvloeden. Vanuit onze visie op riskmanagement bepalen we eerst de strategie en vertalen we die vervolgens in relevante en doeltreffende acties.

Een antwoord formuleren op bedreigingen of opportuniteiten gebeurt pas na een doorgedreven analyse. Aangezien we moeten kiezen voor de doeltreffendste en meest economisch verantwoorde strategie, kunnen we niet over één nacht ijs gaan. Ook hier primeert overleg, discussie in groep en inzicht in het project, meer bepaald de objectieven.

Zowel voor opportuniteiten als voor bedreigingen worden vier mogelijke strategieën weerhouden. Volgende tabel geeft een overzicht en de interpretatie.

Tabel 3 Strategieën om met risico’s om te gaan.

Bedreiging Avoid (vermijden)

We maken de keuze om het negatieve risico volledig te vermijden. Het is onze bedoeling om de kans dat het zich voordoet en/of de impact die het risico kan hebben, tot nul te herleiden. We kijken met andere woorden de andere kant op of we kiezen een alternatieve benadering waarbij het risico volledig geannuleerd wordt.

De keuze om iets niet te doen of om een alternatief te kiezen leidt mogelijk tot een hogere kost. Die extra kost is het budget dat voorzien moet worden voor de risicostrategie.

Voorbeeld

Tijdens een project wordt er voorgesteld om met een nieuwe, onbekende technologie te werken. Wanneer die technologie te veel onzekerheid zou betekenen, kan er na een evaluatie gekozen worden om een bekende, vertrouwde technologie te gebruiken. Op die manier verdwijnt het initiële risico.

Bedreiging Transfer (overdragen)

Bij een transferstrategie trachten we de impact van het onzekere event volledig door te geven aan een derde partij.

Belangrijk aandachtspunt bij een transferstrategie is dat de volledige impact wordt doorgegeven. Dat bereiken is niet altijd evident. Denk daarbij aan verschillende vormen van verzekeringen. Een verzekering verzacht de pijn (impact) een stuk, maar in vele gevallen is er nog altijd een impact. Bijgevolg kunnen we die verzekering niet als een doeltreffende transfer aanzien.

Voorbeeld

Hedging, waarbij prijsschommelingen of wisselkoersverschillen wel 100 % worden afgedekt, zijn correcte voorbeelden van transferstrategieën.

Een autoverzekering dekt materiële en fysieke schade. Maar de vrijstelling moet nog altijd betaald worden en de schade kan invloed hebben op de inzetbaarheid (paraatheid) de weken na het ongeval. Bijgevolg kunnen we die verzekering niet als een volwaardige transferstrategie aanzien. De verzekeringspremie is de kost die verbonden is aan de gemaakte keuze.

Bedreiging Mitigate (inperken)

De kans dat het risico zich voordoet of de impact terugdringen tot een aanvaardbaar niveau noemen we mitigeren. De impact of de kans zijn daarbij nooit verdwenen.

In vele projecten is dat jammer genoeg de enige strategie die overwogen wordt. Vaak is die strategie economisch het meest efficiënt, maar we mogen niet uit het oog verliezen dat de kans of de impact nog altijd bestaat.

Voorbeeld

Wanneer blijkt dat het werken met een off-shorepartner te veel risico’s inhoudt (kwaliteit, communicatieproblemen …), kunnen we beslissen om het developmentteam on site te brengen of om met lokale resources werken. Op die manier perken we het risico in.

Bedreiging Accept (aanvaarden)

We kiezen bewust om met het risico te leven. Op het moment van die keuze is er nog geen impact op de projectobjectieven. ‘Leven’ met een bestaand risico kan om onderstaande redenen:

De kans bestaat dat het risico nooit een impact zal genereren en we aanvaarden de kans dat het risico zich zal voordoen.

– We zien geen mogelijkheden om het risico anders te counteren.

Voorbeeld

Het winterweer in België kan leiden tot een beperkte inzetbaarheid van het team. Dat heeft mogelijk een vertraagde oplevering als gevolg. Er wordt na evaluatie geoordeeld dat de kans dat we een strenge winter zullen hebben in België zo klein is, dat het niet de moeite loont daarop te anticiperen.

Opportuniteit Exploit (maximaliseren)

We kiezen om de kans dat deze opportuniteit zich voordoet te maximaliseren. We willen met andere woorden verzekeren dat we kunnen gebruik maken van het positieve effect.

Voorbeeld

Een leverancier meldt dat we een aanzienlijke korting krijgen wanneer we kiezen voor zijn technologie. Die korting is een opportuniteit om ons budget onder controle te houden. De exploit-strategie stelt dat we er alles aan doen om de IT-teams ervan te overtuigen die technologie uiteindelijk te kiezen.

Opportuniteit Share (delen)

Bij het delen van een opportuniteit willen we de kans verhogen dat die opportuniteit waarheid wordt, maar zijn we wel bereid een stuk van het effect te delen. We dragen geheel of gedeeltelijk het ownership, en dus de opvolging, over aan een andere partij.

Voorbeeld

De IT-architecten stellen een technologie voor die momenteel niet standaard gebruikt wordt binnen de organisatie. Die nieuwe technologie blijkt de stabiliteit van de omgeving positief te beïnvloeden. De IT-architecten zullen de software vendor inschakelen om het IT-management te overtuigen. Zo staan ze sterker in hun evaluatieproces. De kans dat de keuze alsnog gemaakt wordt, is significant verhoogd en de positieve impact op de applicaties brengen we op die manier dichterbij.

Opportuniteit Enhance (verhogen)

We verhogen de kans en/of de positieve impact van het risico.

Voorbeeld

De IT-architecten stellen een technologie voor die momenteel niet standaard gebruikt wordt binnen de organisatie. Die nieuwe technologie blijkt de stabiliteit van de omgeving positief te beïnvloeden. De IT-architecten zullen een prototype bouwen om hun mening te ondersteunen. De kans dat de keuze alsnog gemaakt wordt, is significant verhoogd.

Opportuniteit Accept (aanvaarden)

In het geval van een aanvaardingsstrategie bevestigen we het bestaan van de opportuniteit, maar we zetten niet actief stappen om de kans dat ze zich voordoet te verhogen.

Voorbeeld

De projectmanager krijgt een budget toegewezen om mensen aan te sporen langer te werken en zo het project sneller op te leveren. De projectmanager kiest ervoor het team daar niet actief over te informeren. De communicatie zal pas gebeuren op het moment dat het team effectief een tandje moet bijsteken. We zullen het team met andere woorden niet proactief prikkelen om harder te werken.

Velen vragen zich af wat het verschil is tussen de avoid- en mitigate-strategie. Het onderscheid zit vervat in de basisgedachte van de keuze die gemaakt wordt. Bij avoid-strategie stellen we alles in het werk om de bedreiging 100 % irrelevant te maken. We ondernemen een poging om het risico volledig uit te sluiten. Bij een mitigate-strategie willen we de bedreiging niet volledig wegwerken, maar kiezen we ervoor om de kans en/of de impact tot een aanvaardbaar niveau terug te dringen. Bij het monitoren van de strategie en de gerelateerde acties zal blijken of de keuzes het juiste effect hebben.

Risico’s beantwoorden of counteren vraagt in principe altijd een investering. Afhankelijk van de gekozen strategie spreken we daarvoor ons contingency-budget aan of lanceren we een change request dat bijkomend budget kan vragen (of budget kan verschuiven binnen het project). In het hoofdstuk ‘Hoe kan ik een realistische prijs bepalen voor mijn initiatief? #inschatten’ lichten we toe hoe een buffer voorzien kan worden om het hoofd te bieden aan onzekerheden.

Als we kiezen voor een accept-strategie, aanvaarden we het risico en gebruiken we de buffer die we hebben voorzien om de eventuele schade op te vangen. Het contingencyplan stipuleert hoeveel buffer er voorzien is in ons budget op project- of deliverableniveau en welk aandeel opgenomen kan worden om het risico te accepteren. Als een andere strategie gekozen wordt, hebben we in principe altijd te maken met een change request. We beslissen om iets bijkomends te doen om een risico volledig uit te sluiten of in te perken. De change requests doorlopen een goedkeuringsprocedure en worden aansluitend opgenomen in het projectmanagementplan.

We stelden eerder dat een project niet op een eiland wordt uitgevoerd. Er zijn met andere woorden altijd invloeden van buiten het project of ons project, kan ook andere projecten beïnvloeden. Daarom spreekt men in de recente versies van de PMBoK ook over escalatie als risicostrategie. Het idee achter die strategie is dat het beheren of counteren van een risico niet in de bevoegdheid of de mogelijkheid van het project zelf ligt. Bijgevolg kan de projectmanager via escalatie een ander project of een andere verantwoordelijke informeren over een risico dat geïdentificeerd werd.

6 Risico’s opvolgen: loont onze risicostrategie?

Hoe beter een projectteam kan anticiperen, hoe groter het gevoel van comfort dat kan worden geborden aan de projectsponsor, de stuurgroep, de PMO-verantwoordelijke enz. Daarom dat de uitkomst van de voorgaande stappen ook een plaats verdient in de project status reporting.

Hieronder geven we een voorbeeld van regelmatige risicorapportering. Dit kleine dashboard focust op het aantal geïdentificeerde, actieve risico’s. Dat onderstreept dat het projectteam actief met risico’s omgaat. Daarnaast tonen we ook de effectiviteit van ons risicobeheer. Dat wordt aangetoond door te rapporteren hoeveel risico’s al zijn omgezet in issues, m.a.w. hoeveel mogelijke issues ondertussen al effectieve issues zijn geworden. Wat hier niet getoond wordt, is hoeveel budget (of contingency) al werd aangesproken om risico’s te managen. In sommige bedrijven is dat ook een parameter die men graag gerapporteerd wenst te zien.