Schattingen: houden we onszelf voor de gek?

Schattingen vormen een belangrijke bron bij de calculatie en planning van ict-projecten. Een goede schatting bepaalt de haalbaarheid van een project en bij een uitbesteding de gunning van het werk. Toch gaat hier nog veel mis. Waarom focussen we telkens op schattingen in uren terwijl deze schattingen lastig waar te maken zijn? Vanuit de agile-aanpak Scrum komen manieren van schatten die een meer accuraat resultaat opleveren. Dit wordt bereikt door de schatting relatief te maken ten opzichte van de performance van het team. Wat kan je als opdrachtgever en als leverancier doen om schattingen meer overeen te laten komen met de werkelijkheid?

Traditionele manieren van schattingen hebben in veel gevallen een uitkomst in uren. Deze urenschatting zijn vaak de uitkomst van uitgebreide analyse eventueel gecombineerd met een formele methode zoals functiepunten of Delphi. Maar waarop worden deze schattingen gebaseerd? In het beste geval is er in de organisatie een benchmark aanwezig om de schatting te onderbouwen. Richtlijnen voor deze urenbenchmark (bijvoorbeeld uren per functiepunt) zijn een continue bron van discussie. Zijn deze richtlijnen wel afgestemd op de laatste stand van de technologie, de gebruikte methode, de klantvraag en de capaciteiten van het team? Dat deze methode zo succesvol is, komt omdat uren per functiepunt voor ict-management een eenvoudige (dus voor management begrijpelijke) richtlijn voor het meten van de performance van de development-afdeling. Dit is alleen tot op zekere hoogte waar voor het meten van performance van afgeronde werkzaamheden. Dit werkt echter niet voor het voorspellen van de omvang van nog onbekend werk. Tot slot zijn uren een handige eenheid om de omvang van de te bouwen applicatie in uit te drukken. Vermenigvuldig dit met het gemiddelde tarief en je weet wat het product gaat kosten.

Deze traditionele schattingen worden in negen van de tien gevallen niet waar gemaakt. Soms valt het mee, maar in veel gevallen was de schatting te optimistisch en moet er vanuit het project een uitloop of overrun gemeld worden. Hoe komt het toch dat er telkens een verschil zit tussen de geschatte hoeveelheid werk en de uiteindelijke realisatie? De oorzaak moet gevonden worden in de wijze waarop er naar het werk wordt gekeken. Veel van de factoren die bepalend zijn voor de uitkomst van de schatting hebben te maken met de persoonlijke interpretatie van de schatter van de te schatten requirements. Dubbelblind en groepsgewijs schatten kunnen deze factoren verminderen maar niet helemaal wegnemen. De onderstaande factoren zijn bepalend voor de uitkomst van een schatting en het verschil ten opzichte van de realisatie.

Omvang schattingsinput

De omvang van de input is bepalend voor de uitkomst. Het gaat dan puur om de fysieke hoeveelheid pagina's requirements, ontwerp en modellen. De regel 'meer is beter' gaat hier vaak niet op. Uitgebreidere informatie geeft vaak een onjuiste (hogere) schatting. Er is ergens een optimum. Te weinig informatie leidt tot te veel aannames terwijl teveel informatie alleen maar tot meer vragen en misinterpretaties kan leiden. Bij grotere hoeveelheden data is de kwaliteit van de schatting vaak minder goed. Reden hiervoor is dat bij meer informatie, relatief onbelangrijke details tot belangrijke punten opgeblazen kunnen worden. Deze zaken worden vaak pas bij realisatie duidelijk.

Kwaliteit en relevantie schattingsinput

Ook de kwaliteit en relevantie van de schattingsinput is bepalend voor de kwaliteit van de schatting. Als bij de input voor de schatting een hoeveelheid niet relevante informatie zit, kan dit leiden tot een onjuiste (vaak hogere) schatting. De gegevens uit de niet-relevante gegevens wordt wel mee gewogen in de schatting (ook al wordt deze ervaren als niet relevant). Het is dus belangrijk om bij levering van requirements je te beperken tot alleen de relevante requirements.

Verkeerde interpretatie van de te schatten requirements

De interpretatie van de te schatten requirements kunnen sterk bepalend zijn voor de uitkomst van de schatting. De personen die de schatting maken interpreteren de requirements. Het beschikken over te veel of te weinig informatie (zie punten hierboven) geeft ruimte voor eigen interpretatie.  Als gedurende het proces van schatting ook nog weinig interactie met de opdrachtgever is, kunnen de requirements een heel eigen leven gaan leiden.

Te grote functionele delen schatten

Het menselijke brein is niet in staat om meer dan ongeveer één week werk helder te overzien. Deze hoeveelheid werk is voor de schatter/developer groot genoeg om te bepalen welke achtereenvolgende acties werk opleveren. Bij grotere deeltaken is het werk niet meer in één geheel te omvatten. De schatting wordt dus een grove schatting en kan dus flink afwijken. Het schatten van kleine deeltaken maakt de totale schatting zekerder en vermindert de afwijking. Daarnaast is de afwijking op kleine deeltaken meer acceptabel (100 procent afwijking op een taak van acht uur is te aanvaarden. Deze afwijking op een taak van tachtig uur is niet acceptabel).

Onderschatting van technologie

Een andere bron van onderschatting is de geadviseerde (nieuwe) technologie. Hoewel nieuwe technologie vaak als bron van efficiëntie wordt verkocht is dit in veel trajecten een factor van vertraging. Dit ondanks de talloze voorbeelden, demo's en referentie-implementaties. Nieuwe technologie heeft altijd een leercurve die in veel schattingen niet wordt meegenomen (of wordt weggestreept tegen de efficiëntievoordelen verderop in het traject). Vaak ben je als leverancier zo overtuigd van de kracht van de innovatieve oplossing die geboden kan worden dat er niet wordt gelet op fundamentele afwijkingen (of zelfs fouten) in deze oplossing. Deze tegenvallers komen in het ergste geval pas bij realisatie boven water.

Verwerken van onzekerheid in schatting

De te schatten objecten zijn (zeker over lange tijd) onderhevig aan verandering. De omvang en complexiteit kunnen door veranderingen in de omgeving (of binnen het realisatieteam) wijzigen. Dit kan de schatting zowel positief als negatief beïnvloeden. Helaas zien we deze meevallers in de bouw haast nooit terug in een vermindering van de kosten. Tegenvallers worden binnen de schatting opgevangen met zogenaamde buffers of PM-posten (bijvoorbeeld 15 procent). Dit geeft het project tijdens de realisatie de ruimte om dit soort onzekerheden binnen enige marges op te vangen. Het principe van dergelijke buffers geeft een schijnzekerheid dat het traject beheersbaar blijft zolang de onzekerheid binnen de buffer blijft. Maak als dit te kwantificeren was zou dit niet onzeker zijn. Het enige wat hiermee gecreëerd wordt is meer ruimte om het development-werk te laten mislukken. Er is in dit geval dus 15 procent tijd gereserveerd om vertraging en overrun te verstoppen voordat dit aan de opdrachtgever duidelijk wordt.

Verwerken van implementatiefactoren in schatting

Bij het maken van de schatting houden de schatters niet altijd rekening met factoren tijdens de implementatie. Zo kan het verschil in de productiviteit tussen een goede en een slechte ontwikkelaar oplopen tot een factor 25. Bij het maken van een schatting heeft de schatter al een soort gemiddelde ontwikkelaar in zijn achterhoofd. Dit kan dus nog flink afwijken. Bovenop deze factoren is de interactie van het team een sterke factor in de productiviteit. Zelfs een team van super-productieve ontwikkelaars kan een lage productiviteit krijgen door een gebrek aan samenwerking (of te veel ego). Het kan zelfs zijn dat goed samenwerkende teams van minder productieve ontwikkelaars juist door deze samenwerking een hogere productiviteit realiseren.

Voor de schatting is het dus van groot belang te weten wat de productiviteit van het team is. Met deze productiviteit kan er een indicatie gegeven worden van de kosten van functionaliteit. Hiervoor moet er echter wel eerst ervaring met dit team worden verkregen.

Waarom houden we onszelf toch steeds voor de gek?

Voor het opleveren van een goede schatting van gewenste functionaliteit moet er ervaring, vertrouwen en bekendheid met de technologie worden opgebouwd. Zonder deze ervaring is een schatting slechts een wilde gok die in het beste geval als een soort self fulfilling prophecy gaat fungeren. Waarom laten we ons als leverancier en als opdrachtgever dan toch steeds weer verleiden tot een fixed price-schatting voor een nieuwe applicatie, met nieuwe technologie, met een nieuwe leverancier en die dit met een nieuw team gaat realiseren? Deze factoren maken projecten minimaal lastig beheersbaar en leiden vaak tot overrun en vervelende discussies (of zelfs complete mislukking). Laten we dit van zowel leverancierskant als opdrachtgever onderkennen en elkaar niet voor de gek houden met deze schijnzekerheid.

Hoe nu beter schatten?

Scrum (de meest populaire agile-methodiek) is sterk gebaseerd op het principe van het verkrijgen van een ervaringscijfer en het opleveren van realistische schattingen. Het hele team bepaalt de schatting van de te bouwen functionaliteit. Scrum-schattingen zijn relatieve schattingen binnen één specifiek team voor één specifiek traject. Het erkent het feit dat productiviteit tussen verschillende teams en verschillende projecten niet vergelijkbaar zijn. Het gaat hiermee dus actief om met constateringen die de afgelopen jaren al door veel teams zijn bewezen (je kunt je flink vergissen bij schattingen gebaseerd op benchmarks). Productiviteit is niet vergelijkbaar tussen teams, talen, klanten en functionaliteit. Binnen Scrum wordt de scope van de schatting beperkt tot de volgende iteratie (bijvoorbeeld vier weken). Er worden alleen schattingen gemaakt van heldere, begrijpelijke en geaccordeerde functionaliteit. Hierdoor wordt voorkomen dat er gewerkt word aan ontwerpen van functionaliteit die nog niet helder zijn of functionaliteit die pas over een half jaar wordt gerealiseerd (en dan vermoedelijk weer anders moet zijn).

Productiviteit binnen Scrum wordt gemeten in hoeveelheid functionaliteit die het totale team binnen één iteratie (sprint) kan opleveren. Dit zijn behapbare, overzichtelijke en duidelijke brokken functionaliteit (stories). Om niet in de val van het schatten met uren te trappen, wordt binnen Scrum gewerkt met zogenaamde story points. Dit is de relatieve weging van de complexiteit en omvang van een stuk functionaliteit ten opzichte van een begrijpelijk, al gerealiseerd stuk functionaliteit. Door in iedere iteratie te meten wat de hoeveelheid gerealiseerde story points is, kan je relatief eenvoudig een beeld vormen van de ontwikkeling van productiviteit van je team. Door aan het eind van de iteratie deze productiviteit af te zetten tegen de schatting in story points krijg je direct een terugkoppeling van de kwaliteit van je schatting.

Conclusie

Je kunt pas echt wast zeggen over de schatting als je met een stabiel team al een tijdje ervaring hebt opgedaan met de technologie, functionaliteit en klant. Schattingen en productiviteit zijn niet vergelijkbaar tussen verschillende teams, technologie, functionaliteit en projecten. Alle schattingen in uren gedaan door teams zonder ervaring met al deze factoren zijn niet meer dan een wilde gok. Alleen teams die ervaring hebben opgedaan kunnen een betrouwbare schatting leveren. Tot die tijd moet je als leverancier je klant het vertrouwen bieden dat je hem waar voor zijn geld levert. En dit vervolgens ook leveren! Door je project in korte iteraties op te leveren, kan je voldoende statistieken opleveren om dit vertrouwen ook met cijfers te onderbouwen. Dit is de basis voor een langdurige en succesvolle relatie met je opdrachtgever.