Stop met #risicomanagement op #projecten

Zoals je weet ben ik aan het nadenken in deze reeks blogs over hoe we ideeen vanuit agile kunnen gebruiken binnen het projectmanagementparadigma. Wat ik een grote weeffout vindt in de laatste paradigma is de obsessie met beheersing van onzekerheid. Daarom in deze blog wat kansberekening.

Stel dat je projectmanager bent die iets moet verbeteren aan bestaande productielijn. Een probleem dat je met de scope van dit project natuurlijk hebt is dat men extra wijzigingen buiten de scope om wil toevoegen. Het risico op scopecreep ligt dan levensgroot op de loer.

Laten we eens wat kansberekening doen. De percentages zijn voorbeelden, ik moedig je aan om het voor je eigen project zelf te doen (bijvoorbeeld met de techniek van de ‘gelijkwaardige weddenschap’.

Geen extra wijzigingen

25%

Wel extra wijzigingen

75%

Geen scopecreep 90% 25%
Wel scopecreep 10% 75%

Wanneer er geen extra wijzigingen zijn is de kans op scope creep natuurlijk kleiner dan wanneer deze er wel zijn, maar niet helemaal nul, het team zelf kan het nodige tegenkomen wat gewijzigd moet worden. Er zijn dus twee scenarios met scopecreep waarvan de gemeenschappelijke kans gelijk is aan:

(25% x 10%) + (75% x 75%) = 58,75%

Je besluit om dit risico te beheersen met behulp van een wijzigingsprocedure. Hoeveel procent denk je dit risico te kunnen verminderen?

Laten we de berekening nog een keertje doen. Waar je nu rekening mee moet houden dat er scenario’tain’tdenkbaar zijn waarbij ook een wijzingsprocedure scopecreep niet kan voorkomen. De volgende tabel laat de kansberekening zien. Ik hoop dat je nog geïnteresseerd bent;-) 

Geen extra

wijzigingen

25% Wel extra

wijzigingen

75%
Wijzigingsprocedure Werkt

95%

Werkt niet

5%

Werkt

70%

Werkt niet

30%

Geen scopecreep 80% 70% 70% 30%
Wel scopecreep 20% 30% 30% 70%

Er zijn nu vier scenarios met scopecreep waarvan de gemeenschappelijke kans gelijk is aan:

(25% x 95% x 20%) + (25% x 5% x 20%) + (75% x 70% x 30%) + (75% x 30% x 70%) = 36,5%

Wat betekenen deze twee tabellen nu? Het aanbrengen van de wijzigingsprocedure in dit voorbeeld levert een vermindering van de kans op scopecreep op van 58,75%  – 36,5% = 22,25% . De vraag is nu of de resterende 36,5% acceptabel is. Ik vind het nog steeds aan de hoge kant. De valkuil waar we met het beheersingsmechanisme tegen aan lopen is dat we de wijzigingsprocedure nog strakker gaan handhaven, iets wat veel projectmanagers dan ook daarwerkelijk doen. Met als resultaat veel escalaties, ontevredenheid en iets waar de eindgebruiker niet op zit te wachten of in het ergste geval niet mee kan werken.

Je kunt er van alles van vinden van de bovenstaande berekening, mogelijk vind je er nog een fout in ook. Maar de meeste projectmanagers nemen de tijd niet voor deze overwegingen en ik durf te wedden dat de meeste moeite hebben met deze kansberekening. Maar dan is de vraag wat heeft het voor zin om een risicoanalyse te doen?

Het paradigma van beheersing van onzekerheid bouwt op de foutieve aanname dat deze te beheersen is! Een risico is, zo zeggen we, een onzekere gebeurtenis met negatieve gevolgen voor het project. De bovenstaande berekening gaf een voorbeeld waarin de vermeende verbetering ten gevolge van de risicomaatregel minder groot is dan we intuitief dachten. Dat komt omdat je onzekerheid niet goed kunt beheersen! Onzekerheid is het gebrek aan informatie die pas na verloop van tijd vrijkomt. Moet je dan wachten? Neen dat is ook niet de juiste manier.

Het begin met een mindset verschuiving van het voorkomen naar het verwachten en omarmen van verandering. Dat is iets dat projectmanagers uit het agile denken kunnen leren. Maar hoe ga je er dan mee om? Door doorlopend in een regelmatige cadans de aannames te toetsen. Als deze  niet blijken te kloppen, dan neem je daar op dat moment maatregelen voor. De scope stel je vast in hoeveelheid werk waarvoor geld beschikbaar is, in een vorige blog spraken we over het veroorloofbare verlies. Per iteratie stel je dat vast, budget voor, in dit geval wijzigingen stel je per sprint of increment vast. Het is niet de onzekerheid die je beheerst maar de gevolgen daarvan.

Is dit te simplistisch? Ja dat is het! Is het agile? Neen dat is het niet. Je mag het wat mij betreft hybride noemen, maar als je mij een beetje kent dan weet je dat ik dat niet echt zie zitten. Wat is het dan, het is een poging om met de inzichten uit het agile paradigma naar dat van de beheersing te reizen.