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’s denkbaar 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.

Er is geen #businesscase voor #opdrachtgevers en #businesscases

Ik wil beginnen met een stukje geschiedenis. Mijn allereerste project was in het begin van de tachtiger jaren van de twintigste eeuw (ik vind dat beter klinken dan de vorige eeuw;-). Toen spraken we nog niet over opdrachtgever, eerder hadden we het over de klant. Maar we lieten dat een beetje in het midden. Ook verwachten we niet veel van onze klant of degene die ons op de klus zette. Een projectmanager in die tijd dook in de klus, werkte als het moet tachtig uur per week, en zorgde ervoor dat de klus geklaard werd. Overigens vaak met – net als nu – tegenvallende resultaten op het gebied van doorlooptijd, kosten en opgeleverde functionaliteit. Het duurde langer, kostte meer en leverde meer of iets anders.

Toen gingen we professionaliseren en kopieerden we technieken uit de productiepraktijk in projectmanagement. Er ontstonden methoden en standaards, de belangrijksten waren en zijn in zekere zin nog steeds PRINCE2 en PMBOK, waarbij de eerste een methode zegt te zijn en de tweede een standaard. Ik weet niet of jij het verschil ziet, maar ik ken beiden, wat mij betreft behoren ze tot hetzelfde genre. Pretentieus doch zeer populair, het zal wel aan mijn skeptische en kritische geest liggen. Overigens noemen beiden het belang van op maat maken wel op de een of andere manier. Massaal gingen mensen deze toepassen, in ons deel van de wereld werd het voornamelijke PRINCE2. 

Er zijn een paar zaken in PRINCE2 waar ik mijn pijlen op wil richten: de businesscase en de opdrachtgever of de executive. Deze laatste is eindverantwoordelijk en eigenaar van de eerste. Er staat een uitgebreide lijst met verantwoordelijkheden van de opdrachtgever in de PRINCE2 manual. Als je deze laat lezen aan projectmanagers die nog niet zijn blootgesteld aan PRINCE2 dan kijken ze je verbaasd aan. Ik heb dit een aantal keren gedaan. De meeste projectmanagers vinden dan dat de opdrachtgeverszaken juist door hun gedaan moeten worden. Dat heb ik zelf ook altijd gedacht, totdat ik werd blootgesteld aan PRINCE2.

Toen wij na verloop van tijd in Nederland een kritieke massa PRINCE2 projectmanagers hadden ontstond er hierdoor een behoefte aan trainingen voor opdrachtgevers. Deze voldeden immers niet aan de lijst van verantwoordelijkheden die PRINCE2 noemde. Dat niemand zich publiekelijk heeft afgevraagd of misschien de lijst verantwoordelijkheden fout was, heeft mij altijd bevreemd. Projectmanagement hoort zich aan te passen aan de praktijk en niet omgekeerd. Wie zegt dat PRINCE2 best practice is kan goed verkopen maar heeft het niet bij het juiste eind, het is een practice en daar houdt het mee op.

Wat kunnen we leren van het agile paradigma, geen almachtige opdrachtgeven, geen machtige projectmanager, in plaats daarvan een productowner die de klant vertegenwoordigd. Als we die nu eens overbrengen naar de projectorganisatie. De persoon heeft functioneel inhoudelijke kennis van wat er nodig is. Het is de stem van de klant in het project. Van het hoger management is er een pot geld beschikbaar gesteld om een volgende fase in te gaan. Geen businesscase, maar dat wat ondernemers een veroorloofbaar verlies noemen. Vergelijk het met een aandelenoptie. Het is een fractie van wat de totale kosten van het project kunnen worden. Tijdens de uitvoering sprint men in een vaste candans van de ene increment naar de andere, de productowner bepaalt de inhoud van het werk het team wat ze de volgende sprint kunnen doen. Het schatten van de fase verloopt zoals in een vorige blog is beschreven. Aanvankelijk weet men de doorlooptijd niet zeker, maar na een aantal iteraties kan men redelijke goede voorspellingen doen. Aan het eind van de fase bepaalt men of men verder gaat. Is het antwoord negatief, dan stopt men. Omdat men van te voren besloten heeft dat het verlies veroorloofbaar was kan het alleen maar meevallen. 

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. 

#projectmanagement en de onzin van #scopebeheersing

De eerste definitie die ik hoorde van projectmanagement is het managen van het project binnen de afgesproken tijd en budget en volgens de opgestelde specificaties. Waar we dan voor moesten oppassen is dat we niet te maken krijgen met steeds weer nieuwe eisen van onze klant. Het is de vrees van elke projectmanager. We wapenden ons tegen deze scope-creep door middel van een strakke, vaak contractueel afgedwongen, wijzigingsprocedure. Met de hakken in het zand betreden team en klant het strijdtoneel om aan het eind van de contractonderhandelingen met de samenwerking te beginnen. Resultaat? Iets waar de klant niet op zat te wachten. Als je dan ook nog projectmanager binnen de overheid bent en openbaar moet aanbesteden dan wordt het leven er ook niet prettiger door.

In deze blog probeer ik vanuit het agile perspectief te bewegen naar het overbekende en nog veel gevolgde managementparadigma. Ik noem het paradigma omdat het vooral een sterke overtuiging is hoe je bepaalde zaken moet beheersen. Of het ook wijs is, dat is een andere vraag. Je zou eens met wetenschappers moeten praten over al die technieken, de meeste hebben weinig tot geen voorspellende waarde. Toch vormen ze een belangrijk onderdeel van de praktijk die we elkaar aan leren en praten.

Projectmanagement werkt vanuit een beheersingsparadigma dat niet vriendelijk tegenover veranderingen staat. Heel lang hanteerde ik de spreuk: ‘Een projectmanager vertraagt de planning om de uitvoering te versnellen!’ De onderliggende aanname is dat ik wanneer ik daar voldoende tijd voor neem ik de meeste zaken vooraf kan specificeren en dus kan plannen. Wat blijkt nu in de praktijk van alle dag? Dat dit een foutieve aanname is. Een heleboel is niet goed te voorspellen. Het meeste moeten we allemaal nog ontdekken en in kaart brengen. In mijn vorige blog ben ik in gegaan op schattingen, nu verbreed ik de blik enigzins.

Dat wat zeker is, zouden we volgens het managementparadigma kunnen plannen en opleveren, echter dat werkt niet voor wat we nog niet helemaal zeker kunnen weten. Binnen agile spreken we van een productbacklog met zaken die we willen doen. Regelmatig schonen we deze op door onze wensen in lijn met de behoefte te brengen. Wanneer we de backlog verdelen in zekere producten en producten waar we nog een keuze voor moeten maken, dan zijn we een eind op weg. De zekere dingen schatten we zoals in de vorige blog geschreven, de onzekere gaan we uitzoeken wanneer de tijd daar rijp voor is. Niet zoals als in het managementparadigma, aan het begin van het project, nee tijdens wanneer we het kunnen weten. Stel je eens voor hoeveel tijd dit uitspaart. 

Maar dan zijn we er nog niet, want een ander probleem is de opdrachtgever. Dit is de uiteindelijke beslisser voor elke uitbreiding van de scope. Het is een vreemde snoeshaan, want hoewel deze verantwoordelijk is voor het organisatiebelang (vastgelegd in een businesscase) is het vaak niet de feitelijke gebruiker. Die mag, vertegenwoordigd door een senior gebruiker meepraten in de stuurgroep, maar niet beslissen. Ik stel voor de opdrachtgever af te schaffen en de senior gebruiker vastgesteld budget te geven om als een productowner te besluiten welke producten we voor dat budget willen hebben en kunnen aanschaffen en daar moet hij het dan ook maar mee doen. Er zit nog wel een adder onder het gras wat betreft randvoorwaardelijke producten, maar ook daar kunnen we een soortgelijke constructie voor ontwerpen.

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 over te brengen. 

Nu we de opdrachtgever hebben geëlimineerd moeten we het ook hebben over de businesscase Dat is het onderwerp van mijn volgende blog.