En wat kost dat dan?

Die vraag wordt mij bij IT projecten, vooraf, tijdens en bij onderhoud, altijd gesteld. En zoals de meeste projectmanagers, developers en analisten vind ik dit een lastige vraag, gewoon omdat die moeilijk met nauwkeurigheid en betrouwbaarheid is te beantwoorden.

Waarom is begroten van programmeerwerk zo moeilijk?

Omdat programmeren het oplossen is van onbekende problemen: er is nog geen oplossing voorhanden, we moeten meer analyseren voordat we een betrouwbaar antwoord kunnen geven. En als we gaan analyseren is vaak al meer dan 50% van het werk gedaan, voordat het probleem voldoende uitgewerkt is om een passend antwoord te geven. En dat (50% al besteed) is wat niet gewenst is, men wil juist vooraf een duidelijk antwoord. Dus moeten we een schatting maken op basis van ervaring met soorteglijke problemen in vergelijkbare omstandigheden. En dat is lastig.

Natuurlijk wordt je meer ervaren in de loop van de tijd en dat geldt ook voor mijzelf. Ik ben in de loop van de tijd beter geworden in het geven van een schatting die betrouwbaarder is.  In de onderstaande tekst deel ik mijn ervaringen met u.

Het magische getal PI

Lang geleden hanteerde ik het getal PI (3,1415926535) voor het doen van een schatting. Niet om de oppervlakte of omtrek van cirkels te te bepalen, maar als vermenigvuldigingsfactor van de schatting van een programmeur. Als hij op de vraag: “Hoeveel tijd kost het om XYZ te implementeren?” een antwoord gaf van “een halve dag” , dan vermenigvuldigde ik dat met PI en gaf dat als begroting af: ruim 1,5 dag dus. Een brute methode die misschien niet getuigt van wetenschappelijke onderbouwing, maar wel een die in de praktijk werkte. Programmeurs zijn namelijk aarts-optimisten en een eenvoudige nuancering kan nooit kwaad.

Ervaring is de sleutel

Alle gekheid op een stokje: je wordt alleen beter in het schatten van de benodigde tijd als je jezelf dwingt ervaring op te doen.

Ik probeer in de ochtend de dagindeling te begroten. Aan de hand van mijn ToDo lijst bepaal ik hoeveel tijd ik denk met iedere taak bezig te zijn. Als ik met developers werk, vraag ik ook (zeker in een agile/scrum aanpak), iedere taak die ze oppakken van een verwachte inspanning te voorzien. En aan het einde van de taak kijk ik hoe optimistisch die developer is geweest. Sommigen veranderen van optimist in realist en worden betrouwbaarder, anderen blijven aarts-optimisten. Maar door de ervaringen vast te leggen, kun je daarmee rekening houden en betrouwbaarder begrotingen afgeven.

Analyse en evaluatie achteraf

Leerzaam zijn de projecten die uit tijd en budget lopen. Besteed tijd om ervan te leren, niet altijd de leukste klus, wel een leerzame. Wat redenen waarom budget en/of doorlooptijd worden overschreden:

Over het hoofd gezien – Sommige taken zijn over het hoofd gezien bij de initiële begroting, taken als een conversie, het schaduwdraaien, opzetten van een functionele – en een performance testomgeving (echt dat gebeurt).

Een enkele taak blijkt erg ingewikkeld – en deze taak verbruikt een onevenredige hoeveelheid tijd en budget, bijvoorbeeld een factor 5 meer dan vooraf werd begroot. Tussentijds vinger aan de pols houden, opsplitsen in een serie van eenvoudiger taken en/of op tijd stilleggen en een andere oplossing bedenken kan helpen die overschrijding  in te dammen.

Alle taken blijken te kort ingeschat – en allemaal met vergelijkbare verkeerde inschatting. Men is gewoon te optimistich geweest, maar heeft wel structureel gewerkt. Oorzaken kunnen divers zijn, van een matig fungerende infrastructuur, trage management beslissingen, tot documentatiewerk dat onvoldoende voorzien was.

De scoop is aangepast – De scoop van het project is gaande het project aangepast, zonder dat men er erg in heeft gehad. Men was zo druk bezig dat onduidelijk is gebleven dat gaandeweg het spel de regels zijn aangepast.

Onvoldoende afstemming – Doordat mensen op elkaars resultaten moesten wachten  voordat ze zelf weer verder konden, is tijd voorbij gegaan die niet nuttig is besteed (time flies when you are having fun). Zoeken naar het kritieke pad, alternatieven verzinnen, “stop”werkzaamheden, vooruitwerken aan ongerelateerde taken kunnen een uitweg zijn.

Slecht performende developer – In het team zitten één of enkele developers die beduidend minder productief zijn dan de anderen. Het heeft mij altijd verbaasd dat er grote productiviteitsverschillen tussen developers kunnen zitten en dan heb ik het niet over 10 of 20%, maar een factor 2 of 3. En natuurlijk zijn we allemaal op zoek naar de perfecte productieve developer, maar feit is dat je rekening moet houden met verschillen.

Problemen voorkomen?

Ik heb geen eenvoudig recept waarmee ik perfecte begrotingen kan maken. Wel heb ik zelf iedere keer weer baat bij het zoveel als mogelijk uitsplitsen van taken, programmaonderdelen, functionaliteiten en overige werkzaamheden. Hoe meer details ik voor mijzelf uitsplit, des te betrouwbaarder kan ik een totaalbegroting maken op basis van de optelsom van alle delen. Bovendien helpt deze uitsplitsing mij in het bepalen van de voortgang (budgetverbruik) tijdens het project en kan ik een opdrachtgever op de hoogte houden van de voortgang. En omdat ik vaak in dezelfde technische omgeving werk (Microsoft .NET/SQL) en iedere keer weer een vorm van functiepuntanalyse gebruik, heb ik in de loop van de tijd gevoel gekregen voor de betrouwbaarheid van begrotingen, zowel van de developers als van mijzelf.

Dit neemt niet weg dat ik nog steeds, zelf na meer dan 25 jaar in het veld werkzaam te zijn, de vraag “Hoeveel tijd heb je nodig om XYZ te implementeren?” lastig te beantwoorden vind!

Heeft u suggesties voor meer praktische maatregelen? Ik hoor het graag…