Management

Waarom IT-projecten zo vaak duurder uitvallen dan begroot
Software Cost Estimator kan in toekomst oplossing gaan bieden.
Software Cost Estimator kan in toekomst oplossing gaan bieden.
De ICT-vernieuwing bij de Nederlandse Voedsel- en Warenautoriteit die 59 miljoen euro extra bleek te kosten, de verachtvoudiging van de kosten om private inlogmiddelen naast DigiD toe te laten – het zijn slechts twee van de vele voorbeelden van ICT-projecten bij de overheid die flink duurder uitvielen. En ook in de private sector worden ICT-projecten lang niet altijd goed begroot. Waar gaat het mis?
ICT-projecten bij de overheid: ze zijn duur en blijken achteraf met regelmaat nóg duurder. Uit het Rijks ICT Dashboard blijkt bijvoorbeeld dat de 114 actieve grote ICT-projecten nu samen naar schatting ruim 5,9 miljard euro gaan kosten, 24% meer dan ingeschat werd toen de projecten begonnen.
Maar niet alleen de overheid kampt met hoger uitvallende kosten bij ICT-projecten, zien Principal Consultant Harold van Heeringen en Senior Consultant IT Intelligence Frank Vogelezang van IDC Metri. Beide mannen specialiseren zich in het zo accuraat mogelijk begroten van softwareprojecten. “In de publieke sector ben je verplicht dit soort gegevens openbaar te maken. Maar mijn beeld over de private sector is niet per se veel positiever”, zegt Vogelezang tegenover AG Connect.
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.
Misschien moeten we concluderen dat grote, complexe veranderingen met een IT component heel moeilijk te begroten zijn vanwege de vele factoren die het verloop kunnen beïnvloeden. De genoemde begrotingsmethoden zijn wellicht een benadering maar accuraat wordt het nooit als een traject meer dan 2 jaar duurt. En dat is niet uniek voor IT. Kijk naar de zeesluis IJmuiden, de Keteltunnel en andere infra projecten of bijvoorbeeld scheepsbouw projecten. In alle sectoren blijkt dat mensen optimistischer schatten als het groots en meeslepend is; ze weten het gewoon niet precies.
Dus de scope zo veel mogelijk beperken en kleine opeenvolgende stappen zetten is ook een antwoord. Maar dat moet dan wel kunnen. Als het niet kan kunnen genoemde methoden een betere indicatie geven dan de experts een schatting vragen, maar zie het dan niet als de waarheid. Het blijft een schatting en als je iets doet dat nooit eerder is gedaan dan is historische data maar beperkt geldig! Ik zou nu op basis van historische data gewoon altijd 100% erbij tellen. Dan kom je gemiddeld aardig uit.........
Natuurlijk is het inderdaad onderhand tijd voor brede acceptatie van een fatsoenlijk begrotingstool (zoals functiepuntanalyse, een methodiek die al meer dan twintig jaar bestaat, zoals ook door anderen al terecht opgemerkt) maar dit artikel slaat de problematiek wel héél erg plat. Impliciet wordt uitgegaan van de veronderstelling: loopt het project uit de kosten, dan waren die vooraf fout ingeschat. Sterker nog, het is de titel van dit stuk.
Als we kijken naar het grootschalige onderzoek van PMI van een paar jaar geleden, dan staat de factor "inaccurate cost estimates" op de zevende plek. Slecht change management, slechte communicatie, wijzigende doelstellingen en wijzigende prioriteiten staan allemaal hoger op de lijst. En terecht. Als je bij alles wat foutgaat concludeert dat de kostenschatter dat maar had moeten voorspellen en had moeten meenemen in de begroting, leer je nog steeds niks.
Hoeveel software is er gebouwd of moet er gebouwd worden? In mijn beleving is FPA nog steeds de beste methode om dit onafhankelijk van technologie en software ontwikkel proces te bepalen. Bij het maken van backlogs of gedetailleerde ontwerpen wordt vaak vooral aan de happy flow gedacht. De resterende 80 procent van foutafhandeling komt pas later. Non functionals (iso 25010) zijn voor een deel in de Definition of Done mee te nemen, maar voor een groot deel moet je hier ook uren voor rekenen. Bestaat er al zoiets als een 'bestek' in de IT?
Ik blijf mij op mijn leeftijd verbazen. In de jaren '80 werd IFPA (Interprogram FunktiePunt Analyse) -een geautomatiseerde tool- bedacht. Daarna verder verbeterd met globale omvang begrotingen. Erkend door NESMA. Wij gaven daar Fixed Prices op af en garandeerden dat. Afspraak=Afspraak.
Waar is de goede tijd gebleven, dat het wel kon?
Beide heren Harold van Heeringen en Frank Vogelezang zijn mij beide bekend als oud-collega's.
Op zich een mooie poging van de heren. Maar voor mij zitten hier nog twee andere, niet benoemde aspecten aan het begroten van een verandering (ik noem het bewust een verandering, want een IT-project bestaat voor mij niet, uiteindelijk zijn het de gebruikers die het gaan ontvangen, dus die groep stakeholders heb je altijd).
Voor mij is het belangrijkste aspect voor het begroten van een verandering dat in essentie een project definieert. Dan heb ik het nog niet eens over de definitie van een project, maar van een "afgebakende hoeveelheid werk". Die "afgebakende hoeveelheid werk" moet uiteindelijk leiden tot een "iets". Dat iets kun je tot op heden vertalen naar een doel of een resultaat. Een project dat een doel moet nastreven is veel lastiger te begroten dan een project dat een eindresultaat moet behalen. Hoe dan ook, er is voor geen enkele tak van sport (dus naast de IT) een manier waarop dat eindresultaat in dermate voldoende detail (granulariteit) en ondubbelzinnigheid voor alle stakeholders kan worden vastgelegd. Besef dat een gemiddeld IT-project, naast de IT-middelen, ook de factor mens (zie ik als middel), geld (zie ik als middel), de ondersteunende processen en de daaruit voortvloeiende (half)producten - diensten als onderdelen bevat. Ik hoor mijn vakgenoten al roepen dat je daarvoor ArchiMate, een modeleertaal voor architecten, die met enige fantasie al deze facetten enigszins omarmt, maar zeker niet volledig. Architectuur is een abstractie van de werkelijkheid en derhalve niet implementeerbaar. Engineering is het vakgebied waar voldoende detail is te behalen. Helaas is er geen alles omarmende methode taal die al die detailontwerpen op het gebied van producten en diensten, processen, IT-objecten (datamodellen, services, it-infra componenten) kan relateren aan elkaar, zodat je daadwerkelijk op de cent en seconde na nauwkeurig kan uitrekenen wat iets kost. En nog is het lastig, stel dat je iets moet doen in je project, want nog nooit iemand heeft uitgevoerd.
Een tweede belangrijk aspect is voortschrijdend inzicht en de factor tijd. Een project begint altijd hoog-over en naarmate de tijd vordert, zal er steeds meer voortschrijdend inzicht ontstaan. De factor tijd introduceert ook nog een belangrijk, vaak onderschoven aspect, die van de veranderende omstandigheden. Het zal echt niet de eerste keer zijn dat een project wordt ingehaald door de werkelijkheid, waarbij nut- en noodzaak niet meer relevant is.
Vaak spelen hier menselijke eigenschappen vaak een rol in de besluitvorming dan meer rationele afwegingen. Je hebt veel lef nodig om de stekker uit een project trekken dat al 7 jaar loopt en inmiddels 3x meer kost dan oorspronkelijke begroot.