Waarom softwareprojecten altijd uitlopen

In bijna elk gesprek dat ik voer met een ondernemer die eerder een softwareproject heeft laten bouwen, kom ik hetzelfde verhaal tegen. Niet altijd in dezelfde bewoording, maar de structuur is vrijwel identiek.

Het begon goed. Er was enthousiasme, een globaal idee, een offertetraject. Er werd een partij gekozen. En toen begon het langzaam te veranderen.

Meer overleg dan verwacht. Een scope die gaandeweg werd uitgebreid — soms op verzoek van de opdrachtgever, soms op initiatief van het bureau. Mijlpalen die verschoven. Een budget dat niet meer klopte. En uiteindelijk een oplevering die later was, duurder was en minder was dan gedacht.

Het zijn zelden de technische problemen

Als mensen uitleggen waarom hun project uitliep, noemen ze zelden technische fouten als hoofdoorzaak. Ze noemen: onduidelijkheid over scope, gebrekkige communicatie, wisselende contactpersonen, aannames die pas later expliciet werden.

Technische problemen zijn oplosbaar. Onduidelijkheid is dat minder — want onduidelijkheid kost tijd, en tijd kost geld, en bij uurtje-factuurtje is dat geld van jou.

Het probleem zit in het businessmodel

Uurtje-factuurtje beloont traagheid. Niet bewust, niet kwaadwillig, maar structureel. Een bureau dat per uur factureert heeft geen prikkel om efficient te zijn. Meer uren = meer omzet. Langere projecten = meer omzet. Scope-uitbreidingen = meer omzet.

De ondernemer heeft geen enkel mechanisme om dit te sturen — tenzij je de scope kunt bevriezen en alle meerwerk handmatig goedkeurt. Maar hoe freeze je scope als je aan het begin nog niet precies weet wat je wil?

De blauwdruk als antwoord

Elk project dat ik doe begint met twee weken analyse. We brengen precies in kaart wat er gebouwd moet worden, in welke volgorde, met welke technische keuzes. Aan het einde van die twee weken is er een klikbaar prototype en een vaste prijs voor de bouw.

De klant kan het prototype klikken voordat er meer geld wordt uitgegeven. Hij weet wat hij krijgt. Hij weet wat het kost.

Pas als hij dat prototype goedkeurt, begint de bouw — en de prijs verandert niet meer.

Dit is geen garantie dat elk project vlekkeloos verloopt. Maar het elimineert de twee meest voorkomende oorzaken van overschrijdingen: onduidelijkheid aan het begin en een business model dat profiteert van die onduidelijkheid.

Als iemand je een prijs geeft zonder eerst grondig te begrijpen wat je wil bouwen, is die prijs een gok. En de kans is groot dat jij opdraait voor de consequenties van die gok.