In deze blog beweeg ik vanuit het agile paradigma naar dat van projectmanagement en doe een poging om de agile oplossing voor onzekerheid terug te brengen naar het managementparadigma. Laten we eerst maar eens de onzekerheid in schattingen bij de staart pakken. Elke schatting is gebaseerd op ervaring en vaak een gemiddelde. Helemaal zeker weten we het niet en naarmate we meer ervaring hebben zal de spreiding van de werkelijke uitkomsten kleiner zijn. Dat lijkt een verstandige zaak, echter er kleven een aantal nadelen aan. Laat ik enkele noemen.
Het tijdstip van de eerste schatting!
De eerste schatting die men doet, is aan het begin van de levenscyclus van een project, derhalve is dit de meest foute schatting die men gedurende de hele periode zal doen. Aan het begin van het project is de onzekerheid immers het hoogst! Die eerste schatting vormt echter wel een 'anker' in het brein van de beslisser die daar vaak het hele project aan zal blijven vasthouden. Zeer onfortuinlijk want gaandeweg komt er meer informatie beschikbaar, in het managementparadigma heet dit 'change' en 'change' moet beheerst worden en onder 'control' gebracht worden.
Het probleem van gemiddelden!
Voor het gemak ga ik ervan uit dat de uitkomsten normaal verdeeld zijn (dat is niet helemaal juist, maar voor mijn argument voldoende) wat zoveel betekent dat je 50% kans hebt om uit te lopen. Iets wat niemand wil en daarom zal elke 'slimme' projectmanager wat reserve in zijn schattingen verbergen. Met als resultaat dat alle schattingen te hoog zijn. Deze verborgen reserves ontrekken zich aan het oog van hen die ze willen beheersen.
Als ongeveer de helft van je projecten uitlopen dan doe je het als organisatie gezien statistisch volgens verwachting. Wanneer dit lager is, dan komt dit waarschijnlijk omdat iedereen te ruim geschat heeft. Dit heeft te maken met de wetmatigheid van onzekerheid en daar helpt geen enkel besturingsysteem tegen. Het is net als zwaartekracht, onomkoombaar.
Nu wil ik een aantal agile inzichten in het management paradigma brengen. Een van de verschillen tussen beiden is dat de plan in de pdca cirkel bij agile een hypothese is die we willen toetsen en in het management paradigma een commitment is die we moeten houden. In SCRUM schatten we het aantal storypunten (de hoeveelheid werk), bepalen de snelheid waarmee het team deze verwerkt en weten zo wat we binnen een sprint kunnen leveren. Als je dit mechanisme toepast binnen projectmanagement, dan gaat het 'schatten' als volgt te werk:
- Je begint met team 1, schat het aantal storypunten van de 'totale' scope, gaat dan te werk in een aantal tweewekelijkse perioden en meet de snelheid waarmee de scope door het team wordt geleverd.
- Op basis hiervan maak je een eerste schatting van de doorlooptijd, deze is nog onvolledig omdat veel werk zich nog moet uitkristaliseren in de loop der tijd. Echter de schatting is nauwkeuriger dan op de oude manier.
- Daarna ga je opschalen indien dit nodig is. Je voegt langzaamaan teams toe, kijkt hoe de verwerkingssnelheid toeneemt, totdat je een optimum vindt.
- Je blijft de snelheid van opleveren in een twee wekelijkse cadans meten en past je prognoses aan.
Is dit ideaal? Neen dat is het niet, maar het is een eerste aanzet. Het grote probleem met de projectmanagementleer is dat zij het schatten van budgetten op een soortgelijke manier doet als dat lijnmanagers dit doen. Dat blijkt in de praktijk van alle dag niet te werken, vanwege de veel grotere onzekerheid die er op projecten is. Eigenlijk, als je een beetje verstand van onzekerheid hebt (statistiek en kansberekening), kan je met goed professioneel fatsoen geen goede schattingen tijdens de opstart van een project maken. Wie dat wel doet, begrijpt niet hoe onzekerheid werkt!
De essentie van wat ik hier naar voren breng is dat de redding van het schatten een mindset verandering vraagt van schattingen als commitment naar schatting als hypothese, waarna de hypothese steeds getoetst en bijgesteld wordt.
Hiermee heb ik projectmanagement nog niet gered, want schattingen zijn niet de enige dingen die onzeker zijn. We hebben ook nog de scope, dat is het onderwerp voor de volgende blog.