Waarom softwareprojecten altijd uitlopen

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

Er kwam meer overleg dan verwacht. De scope werd gaandeweg uitgebreid, soms op verzoek van de opdrachtgever, soms op initiatief van het bureau. Mijlpalen verschoven en het budget klopte niet meer. Uiteindelijk kwam de oplevering later dan gepland, en kostte hij meer dan begroot.

Het zijn zelden de technische problemen

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

Technische problemen zijn oplosbaar. Onduidelijkheid is dat minder: onduidelijkheid vreet tijd, en bij uurtje-factuurtje betaal jij die tijd.

Het probleem zit in het businessmodel

Een bureau dat per uur factureert, heeft er geen belang bij dat het sneller gaat. Meer uren, langere projecten en extra wensen leveren allemaal meer omzet op.

De ondernemer heeft geen enkel mechanisme om dit te sturen, tenzij je vooraf vastlegt wat er precies gebouwd wordt en alle meerwerk stuk voor stuk goedkeurt. Maar hoe leg je dat vast als je aan het begin nog niet precies weet wat je wil?

Wat het voorkomt

Het antwoord is de volgorde omdraaien: eerst vastleggen wat er gebouwd wordt, dan een prijs, dan pas bouwen. Hoe dat werkt, staat in hoe een bouwer vooraf een vaste prijs kan geven.

Dit is geen garantie dat elk project vlekkeloos verloopt. Maar het haalt de twee meest voorkomende oorzaken van overschrijdingen weg: onduidelijkheid aan het begin en een businessmodel 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.