samen
werken
De Cone of Uncertainty als hulp bij resource management
De Cone of Uncertainty is een handig instrument bij het maken van inschattingen of forecasts in een wendbare wereld. Wie al langer Agile werkt en aan de voorkant de filosofie goed weet toe te passen (lees: klantwaarde te leveren) komt er vaak achter dat er aan de achterkant (lees: resources zoals budgettering, capaciteit, tijd) allerlei problemen ontstaan. Het is lastig om een Agile Transformatie van een organisatie volledig door te voeren als de achterkant nog op de oude manier ingericht blijft. In deze blog kom je erachter hoe de Cone of Uncertainty daarbij kan helpen.
Wat is de Cone of Uncertainty?
De Cone of Uncertainty, letterlijk vertaald de ‘kegel van onzekerheid’, heeft betrekking op projectmanagement en geeft de ontwikkeling weer van de mate van (on)zekerheid van een project, gedurende een bepaalde tijd. Visueel wordt dit weergegeven in een grafiek over twee assen. De verticale as omvat de variabele ‘inschatting vs. variabiliteit’, of: de mate van onzekerheid. De horizontale as geeft de variabele ‘tijd’ aan. De essentie is het principe dat hoe vroeger in het project, hoe meer onzekerheid er is en dus hoe lastiger inschattingen gemaakt kunnen worden.
Zekerheid neemt toe in het verloop van een project
In het begin van een project is vaak nog weinig bekend of het werk voorspoedig of lastig gaat worden. Alle inschattingen die op dat moment gemaakt worden, dragen een grote onzekerheid met zich mee. Des te meer vraagtekens zouden dus moeten worden gezet op het moment dat de organisatie verwacht dat er in het begin van een project grote forecasts moeten worden gemaakt. Juist door eerst meer onderzoek en ervaring op te doen, help je jezelf de relevantie informatie te verzamelen, die het mogelijk maakt om betere inschattingen te maken.
Omdat er gedurende het project steeds weer bij wordt geleerd, daalt de mate van onzekerheid, tot uiteindelijk geen enkel risico overblijft bij het maken van inschattingen. In dit ultieme geval loopt het project logischerwijs tegen zijn einde (oplevering). Het enige wat hier voor nodig is, is de variabele ‘tijd’ (de x-as).
De Paradox leren vs. presteren
Laat de factor tijd nou net datgene zijn dat bij Agile werken en verandering nog onvoldoende wordt begrepen . Dit heeft alles te maken met het snel willen behalen van resultaten. De paradox leren vs. presteren zal hiervoor eerst beter begrepen en omarmt moeten worden. Pas als onderkent wordt dat leren, veranderen en innoveren op dit moment tijd kost, maar ook tijd in de toekomst kan opleveren, kan je deze aanpak optimaal benutten. Door op de juiste manier tijd te besteden, door te leren en waardevolle informatie op halen kun je de juiste beslissingen en inschattingen maken, wat ervoor zorgen dat je juist later veel tijd bespaart.
Waar pas je de Cone of Uncertainty toe?
De Cone of Uncertainty wordt bij projectmanagement toegepast en is van origine bedoeld om inzichten te verkrijgen over de ontwikkeling van de scope. In een snel veranderende omgeving is het ondenkbaar om een statische scope te beloven. De omgeving verandert te snel en de scope kan elke Sprint veranderen. Een dynamische scope ziet er als volgt uit: gedurende het verloop van het project wordt er allerlei informatie verzameld die het team in staat stelt de variabiliteit van de scope te verkleinen en steeds scherper te stellen. Het gaat hier om de vraag: wat is wél en wat is níet onderdeel van de scope?
Naast de scope zijn er ook andere variabelen die relevant zijn om beter inschattingen te maken:
- Budget
- Tijd
- Capaciteit
Lees meer over de variabelen en hun invloed op Agile projectmanagement.
Waar je precies de Cone of Uncertainty toepast leer je door in de eerste periode (in Agile termen, de 1e 2-3 sprints) de juiste informatie op te halen om uitspraken over de desbetreffende resources te kunnen doen. Informatie betreft in eerste instantie vaak kennis over de doelgroep, de behoeftes, de wensen en de te maken productonderdelen. Inschattingen doe je vervolgens alleen op basis van de informatie die je hebt. Dat maakt dat je automatisch ‘klein’ leert denken.
Het iteratieve proces van productontwikkeling aan de achterkant (resources) precies zo. Je maakt bijvoorbeeld budget-inschattingen per periode. Zo ben je veel secuurder dan dat je van tevoren een jaarbudget (‘groot’) afgeeft dat totaal niet representatief is voor de daadwerkelijke uitgaven.
Tot slot
De vraag die je je als organisatie wilt stellen is: willen wij een getal/inschatting hebben op een bepaald moment omdat het fiscale jaar hier om vraagt óf willen wij accurate inschattingen hebben op momenten dat ze zo goed mogelijk afgegeven kunnen worden? In het laatste geval bouw je een iteratief proces van inschattingen op, relevant voor de desbetreffende opleveringen. Zo blijven kosten en baten dicht bij elkaar en ben je enorm wendbaar om de risico’s continue te beperken door aan te passen wanneer nodig. Dit proces maakt het niet alleen leuker voor je werknemers, maar je realiseert ook een efficiëntere en waardevollere stroom van informatie om de juiste beslissingen te kunnen nemen.
Heb je na het lezen van dit artikel vragen? Of wil je even praten over de mogelijkheden van Agile werken? Aarzel niet en neem vrijblijvend contact op via info@agilescrumgroup.nl of 020 2614 195.
Ook interessant:
- Wat is een Solution Train Engineer? (+verantwoordelijkheden)
- Hoe en welke Kanban metrics kun je het beste gebruiken?
- Waarom Scrum niet (altijd) werkt? En wat dan wel werkt
