Waarom zoveel softwareprojecten hun oorspronkelijke budget overschrijden

Meer dan de helft van de projecten overschrijdt het oorspronkelijke budget. De oorzaak ligt zelden waar ze gezocht wordt. Ze zit in de manier waarop de prijs aan het begin is vastgesteld: een lijst met functionaliteiten, een schatting per functionaliteit, een optelsom.

Budgetoverschrijding bij IT-projecten: wat de cijfers zeggen

Het scenario kent u misschien. Een getekende offerte, een goedgekeurde planning. Dan, tussen de tweede en de zesde maand, een eerste meerwerkopdracht die niemand had voorzien. Daarna een tweede.

Dit is geen uitzondering. 52,1 % van de projecten, van alle soorten, overschrijdt het geschatte budget, volgens Flyvbjerg, How Big Things Get Done, 2023 (16.000 projecten). Bij IT-projecten is het nog erger: de gemiddelde overschrijding bedraagt 80 % ten opzichte van de offerte, volgens Flyvbjerg et al., JMIS 2022 (4.677 IT-projecten). In dezelfde steekproef van 16.000 projecten, in alle sectoren, voldoet slechts 0,5 % van de grote projecten tegelijk aan budget, planning en verwachte resultaten.

Eén op de twee projecten, dat is geen pech meer. Het is ook niet een projectleider die zijn werk slecht heeft gedaan. Op deze schaal ligt het aan de methode: aan de manier waarop de prijs van een IT-project wordt berekend.

Hoe de branche de prijs van een softwareproject bepaalt

Bij IT-dienstverleners, bureaus en freelance ontwikkelaars is de methode dezelfde, en ze lijkt redelijk. De functionaliteiten worden op een rij gezet. Elke functionaliteit krijgt een schatting: zoveel dagen voor deze, zoveel voor die. Alles wordt opgeteld, als blokken die op elkaar worden gestapeld. En daar komt een budget uit, tot op de dag nauwkeurig.

Het ziet eruit als wetenschap. De cijfers zijn precies, de tabel is netjes, de optelling klopt. Maar elke regel van de tabel is een aanname, en een optelsom van aannames is geen meting. Het is pseudowetenschap: het heeft de vorm van een berekening, niet wat een berekening betrouwbaar maakt.

Taken optellen om een doorlooptijd te voorspellen: dat idee komt uit de werktuigbouwkunde. Het is het taylorisme, de industriële bedrijfskunde: opdelen in taken, alles plannen voordat er ook maar iets gebouwd wordt, opleveren zodra het plan is uitgevoerd. Een eeuw later wordt software nog altijd aangestuurd als een lopende band. Maar software-engineering is geen werktuigbouwkunde. Bij softwareontwikkeling levert het optellen van taken geen enkele voorspelbaarheid op.

De wetenschap zegt het al lang: het geheel is meer dan de som der delen. In 1972 publiceert natuurkundige Philip Anderson (Nobelprijs voor de Natuurkunde, 1977) “More is Different” in Science. Zijn stelling: op elk niveau van complexiteit ontstaan nieuwe eigenschappen die niet te voorspellen zijn door de delen afzonderlijk te bestuderen. Softwareontwikkeling is geen optelsom van taken.

P.W. Anderson, “More is Different”, Science, 177(4047), 393–396, 1972.

Een urenschatting blijft een aanname

Er bestaat vandaag geen enkel wetenschappelijk instrument om ontwikkeltijd betrouwbaar te schatten: schattingen zijn niet meer dan zeer onzekere aannames, gebaseerd op een lijst met functionaliteiten waarvan nog niemand weet of ze nut hebben.

Deze zin zegt twee dingen, en die tellen bij elkaar op.

Het eerste: schatten kan niemand. Werk dat steeds op dezelfde manier wordt herhaald, wordt voorspelbaar, en uiteindelijk wordt het geautomatiseerd. Software daarentegen wordt altijd voor het eerst ontwikkeld. Anders zou u het installeren.

Het tweede: de lijst zelf. Het programma van eisen wordt geschreven voordat de software bestaat. En wanneer Microsoft het effect van zijn ideeën met een gecontroleerd experiment meet, verbetert slechts één op de drie de beoogde indicator. Een derde heeft geen effect, een derde verslechtert hem (Kohavi en Thomke, Harvard Business Review, 2017). Wie een programma van eisen regel voor regel begroot, begroot dus ook de twee derde die niet de verwachte waarde zullen opleveren. Welke dat zijn, weet nog niemand.

Sommige teams zeggen dat ze gestopt zijn met schatten. In de praktijk tellen ze het werk dat in een periode is afgerond, nemen ze daarvan het gemiddelde en projecteren ze dat tempo op de rest. Dat is eerlijker dan gokwerk. Maar het blijft een voorspelling. Een aanname over de toekomst is vervangen door een extrapolatie van het verleden. En als deze teams zover gekomen zijn, dan komt dat doordat er om hen heen nog altijd prognoses worden gevraagd.

Een prijs vastleggen op een aanname

Een prijs vastleggen op deze aannames veroorzaakt de meerkosten waar veel projecten nooit meer van herstellen. En de software is in de maanden van ontwikkeling evenmin bruikbaar.

Een prijs op basis van een lijst met functionaliteiten behandelt het project als één blok, dat aan het eind wordt opgeleverd. Maar software is geen groep vastgelegde functionaliteiten. Het is een geheel van functionaliteiten die elk afzonderlijk te gebruiken zijn, en die één voor één kunnen worden opgeleverd. Het blok dwingt ertoe alles vooraf te plannen, en daarna tot het eind op alles te wachten.

Wanneer de prijs en de lijst met functionaliteiten tegelijk worden vastgelegd, komt al het risico bij een van beide partijen te liggen. En niemand kan zich nog aanpassen. Elke ontdekking onderweg wordt een meerwerkopdracht. Elke meerwerkopdracht vergroot het verschil met de offerte. De sturing van het project komt uiteindelijk neer op één ding: een lijst verdedigen die is geschreven op de dag dat iedereen er het minst van wist.

Intussen wachten uw teams. Ze maken pas kennis met de software als het budget al op is. En op dat moment ontdekt u wat ze echt nodig hadden. Niet eerder.

Wat kost software op maat?

De kosten van het ontwikkelen van software op maat hangen af van de tijd die u besluit te investeren in de ontwikkeling ervan en in de dagelijkse aanpassingen om met uw bedrijf mee te bewegen, afgewogen tegen wat het ontbreken ervan u kost.

Wat het ontbreken ervan u kost, weet u al. Dezelfde gegevens, ingevoerd in meerdere tools die niet met elkaar communiceren. De fouten die dat oplevert. Die ene persoon in het bedrijf die dat allemaal bijhoudt. De dure software waarvan uw teams maar een deel gebruiken, en waarvan de leverancier de aanpassingen die u vraagt niet doorvoert. Met dat bedrag moet u de investering vergelijken. Niet met een schatting.

Het leven van software begint in productie. De software behandelen als een opgeleverd project en het onderhoud daarna tot het minimum terugbrengen: dat maakt er een bodemloze put van in plaats van een asset. Onderhoud kost overigens drie tot vier keer meer dan ontwikkeling (Applied Software Measurement, Capers Jones). De einddatum van het project doet er dus weinig toe. Wat telt, is wat u over de hele levensduur investeert.

Wilt u weten wat de ontwikkeling van uw software met onze aanpak kost, waarbij die binnen een maand bruikbaar is? Neem contact met ons op.

Maand na maand beslissen hoeveel tijd u investeert

Voordat u een ontwikkeling start, verwacht u waarschijnlijk een doorlooptijd en een prijs. Die worden gewoonlijk gegeven. Alsof alles te voorzien is. Wij weten niet alles van tevoren. Dat zeggen we liever. Toch een doorlooptijd noemen, zou betekenen dat we u een onzekere aanname geven, die ons vak ten onrechte een schatting noemt. Dat doen we niet.

De adaptieve aanpak voorspelt wat voorspelbaar is: het maandbudget en de ontwikkeldagen per maand. Hij probeert niet het onvoorspelbare te voorspellen: wat uw gebruikers met een functionaliteit zullen doen voordat ze die in handen hebben. Hij stelt één vraag: wat is nu het nuttigste om te doen? En hij beantwoordt die met wat er op dat moment bekend is. Niet met wat men zich op de dag van de offerte voorstelde.

Ook zoekt die aanpak niet naar de volledige oplossing voordat er iets wordt opgeleverd. Aan die zoektocht komt geen einde: “een probleem volledig of perfect willen oplossen, is de belofte van een doorlooptijd die naar oneindig neigt” (Frédéric Leguédois, lezing “Éloge de la simplicité” (Frans)). Een onvolledige oplossing wordt aanvaard, zo vroeg mogelijk in handen van uw teams gelegd en bijgesteld op basis van wat zij erover zeggen.

Zo werken wij. Wij ontwikkelen uw applicatie op maat tegen een vast budget, aan het einde van elke maand gefactureerd voor het geleverde werk. Binnen een maand is ze bruikbaar. Bruikbaar betekent niet af: uw teams gebruiken haar vanaf de eerste maand, en dat gebruik bepaalt wat we de maand daarna ontwikkelen. Daarna passen we haar aan uw veranderende behoeften aan, zolang u dat wenst. Het budget verandert niet. Wat we ontwikkelen, volgt wel wat uw teams leren door haar te gebruiken.

Met uw budget koopt u werk aan dit probleem, niet de oplossing ervan. Elke maand ziet u wat het oplevert, en beslist u of u doorgaat.

En om ervoor te zorgen dat wat vorige maand werkte, ook deze maand werkt, hanteren we de Nulregressiegarantie: elke regressie wordt verholpen en afgedekt door een geautomatiseerde test, zodat ze niet terugkomt, zonder meerkosten.

Een proefperiode tot 15 werkdagen in de eerste maand, en de opgeleverde resultaten zijn van u zodra u betaalt.

Er is geen schatting meer die overschreden kan worden. Er is een budget dat u hebt gekozen, en software die uw teams al gebruiken.

Verder lezen

Onze gids behandelt deze bronnen uitgebreid. U vindt er ook de vragen die u moet stellen voordat u een offerte voor softwareontwikkeling tekent.

Hebt u software die ontwikkeld moet worden, of een tool die niet meer met uw bedrijf meegroeit? Zullen we het erover hebben?