Waarom IT-projecten zo vaak duurder uitvallen dan begroot

Hij noemt een project bij een grote herverzekeraar van twee jaar geleden als voorbeeld. “Die hadden een fixed price-programma voor softwarevernieuwing. Er was een prijs van een kleine 10 miljoen euro afgesproken, maar nadat de specificaties waren opgesteld was twee derde van het geld al op. En toen moest er dus nog gebouwd worden. Toen zei de leverancier dat het misschien toch wel 30 miljoen moest gaan kosten, terwijl ze het dus eigenlijk voor een vaste prijs van 10 miljoen hadden aangeboden.” Na een consultatie van IDC Metri bleken de daadwerkelijke kosten ook lager te liggen dan 30 miljoen, namelijk rond de 12 of 13 miljoen euro.

Te optimistische experts

Verhalen als deze staan niet op zichzelf. Vele bedrijven en IT’ers kennen wel verhalen van projecten die achteraf (veel) duurder uit blijken te vallen. Wat gaat er dan toch mis? Volgens Vogelezang en van Heeringen heeft dat te maken met hoe er wordt begroot. “Binnen bijna iedere industrie zijn er professionele begroters, die daarvoor gecertificeerd zijn. Een project gaat niet door zonder dat diegene daar zijn fiat aan geeft. Maar binnen de IT, en zeker binnen softwareprojecten, hebben we die mensen niet. Daar vraag je een projectleider, een developer en bijvoorbeeld een tester hoeveel tijd ze ergens aan kwijt denken te zijn. Dat, met een contingency van 20% erop, is dan je begroting”, verklaart Van Heeringen, die vanuit zijn expertise ook betrokken is bij de Netherlands Software Metrics Association (Nesma).

Het probleem is dat al die mensen alleen expert zijn in hun eigen gebied. Een developer weet dus alleen hoe lang hij bezig is met iets ontwikkelen en een designer weet alleen hoelang hij met zijn eigen ontwerp bezig is. “Op zich hoeven die deelbegrotingen niet zo slecht te zijn, maar zij vergeten dat je ook nog allerlei verbindende activiteiten nodig hebt om te zorgen dat bijvoorbeeld je stakeholders betrokken blijven. En die activiteiten zitten er vaak niet in. Je ziet dan ook dat je met die expertbegrotingen vaak toch 20 tot 30% te optimistisch bent”, vult Vogelezang aan.

En er speelt meer mee bij de kostenraming van een project. “Heb je een product owner die snapt wat er gemaakt moet worden, of laat hij dingen vier sprints achter elkaar opnieuw bouwen?”, zegt Van Heeringen. “En wat je ook veel ziet, is dat gevonden defects niet in dezelfde sprint worden opgelost, omdat er geen tijd is. Die worden dan teruggezet op de backlog. De volgende sprint heb je dan direct een achterstand, want die defects moet je ook nog eens oplossen. Dan kun je dus minder user stories in die sprint doen. Met dat soort zaken moet je in een begroting allemaal rekening houden.”

Misleidende story points en uurtarieven

Bovendien kunnen zogeheten user stories en story points – een meeteenheid om de benodigde tijdsinspanning, risico en de complexiteit te meten -  in een agile-werkmethode misleidend zijn. “Story points zijn een effortmaat en geen productmaat. Alles wat tijd kost, krijgt story points. Dus het kan best zijn dat je de voorspelde vijftig story points in een sprint behaald en dan ben je heel voorspelbaar in je werk. Maar misschien waren maar tien van die story points voor nieuwe functionaliteiten en de rest voor defects en bugs die opgelost moesten worden. Dan kom je dus niet veel dichter bij het product dat je wil maken, maar denk je wel dat je heel goed bezig bent, want je hebt die vijftig punten gehaald.”

En net zoals story points misleidend kunnen zijn, kunnen uurtarieven dat ook. En daar wordt al snel in gerekend als een organisatie een project zelf, met zijn eigen mensen, uitvoert, of bijvoorbeeld een team of zzp’ers inhuurt. “Het probleem met uurtarieven is dat het wel zegt wat het kost, maar niet wat je ervoor krijgt. Zeker als de inkoop gaat proberen om het onderste uit de kan te halen, krijg je bijvoorbeeld junioren of mensen die minder goed te plaatsen zijn. Dat wil je niet, want het verschil in productiviteit is veel groter dan het verschil in uurtarief.”

Bovendien heeft de leverancier in deze gevallen ook geen prikkel om heel productief te zijn. “Die heeft eerder een prikkel om heel veel uren te factureren.”

Hoe moet het dan wel?

Van Heeringen en Vogelezang begeleiden bij IDC Metri al jaren bedrijven met hun begrotingen voor IT-projecten. Een groot verschil is, volgens hen, dat ze niet alleen kijken naar wat er gedaan moet worden en wat dat naar verwachting kost, maar ook naar de omvang en de doorlooptijd. Van Heeringen vergelijkt het met een schilder die een opdracht krijgt. “Die telt eerst het aantal vierkante meters dat geschilderd moet worden. Dat doen wij ook.”

Vervolgens vergelijken de twee het project met eerdere, vergelijkbare projecten die uitgevoerd zijn. “We hebben richting de 15.000 referentieprojecten. Daar zitten allerlei kenmerken in, zoals de branche, de techniek, de teamgrootte, waar het team zit – bij elkaar over gedistribueerd over de wereld – en de kubieke meters software die opgeleverd moeten worden”, legt Vogelezang uit. “Als je die dingen combineert, kun je zo goed mogelijk vergelijkbare projecten selecteren en krijg je binnen een bepaalde bandbreedte een duidelijk beeld van wat het project echt gaat kosten.”

Tot slot wordt dan dus ook de doorlooptijd meegerekend in de begroting, aangezien die van grote invloed is. Van Heeringen haalt de schilder aan: “Als die een muur van 200 vierkante meter moet gaan schilderen in een uur, gaat hem dat niet lukken. Daar heeft hij te weinig mensen voor. Dus dan moet hij met een heel groot team gaan werken. Maar die kunnen elkaar in de weg gaan lopen en misschien gaat de communicatie niet goed. Zo is het in IT ook. Als je een te groot project in te korte tijd moet doen, worden de teams steeds groter en de complexiteit dus ook. Als je een tweede team neerzet, gaat de doorlooptijd niet opeens door de helft. Daar gaat misschien maar 10% vanaf.”

De komst van de software cost estimator

Wie een accuratere inschatting wil maken van zijn begroting, is vooralsnog dus veelal aangewezen op organisaties die dergelijke factoren meenemen en naar referentieprojecten kunnen kijken om een goede schatting te maken. Maar in de toekomst kunnen bedrijven dit misschien wel zelf gaan doen, vertelt Van Heeringen. Vanuit NESMA is hij namelijk betrokken bij de ontwikkeling van de Software Cost Estimating Body of Knowledge (SCEBoK), dat door de International Cost Estimating & Analysis Association (ICEAA) opgezet wordt. De SCEBoK wordt een certificeringsprogramma voor kostenbegroters, specifiek gericht op softwareprojecten. In de toekomst kunnen organisaties dus zogeheten software cost estimators gaan aannemen of inhuren, die getraind zijn in het zo accuraat mogelijk begroten van een softwareproject.

Niet alleen ontstaat er dan vooraf een beter beeld van wat iets gaat kosten, maar kan er ook tijdens het project beter bijgestuurd worden, aldus Van Heeringen. “Wat tot nu toe vaak gebeurd, is dat alle stoplichten tot drie dagen voor de deadline nog op groen staan, maar vervolgens blijkt dat je het toch niet gaat halen. Als je echter na een half jaar weet dat de helft van de functionaliteit klaar moet zijn en je gaat kijken hoeveel er echt af is, kun je goed zien of je op schema ligt of dat het fout gaat. Dan kun je je estimate bijwerken of kijken of er maatregelen nodig zijn. Maar dit kan alleen maar als je weet hoe groot het is, wat je moet maken en hoeveel er op ieder moment is afgerond.”

Wat Vogelezang en Van Heeringen betreft hebben bedrijven in de toekomst dan ook een eigen cost estimator – die bijvoorbeeld ook product owner of scrum master is – die constant een vinger aan de pols houdt. Maar voor het zo ver is, moet eerst de certificering officieel verschijnen bij ICEAA. Wanneer dat gebeurt, is nog niet helemaal duidelijk. “Het is nu een kwestie van het formaliseren van het examen. Ik verwacht dat dat binnen een maand gaat gebeuren. Dan kunnen we echt aan de gang.”

Aanpassing 3 oktober 2022: In de inleiding stond dat de kosten rondom DigiD draaien om het veiliger maken van DigiD. Het gaat echter om kosten om private inlogmiddelen naast DigiD toe te laten. Het artikel is hierop aangepast.