Waarom vaste-prijsdeals in IT-projecten vaker verlies opleveren dan je denkt

Je maakt een offerte voor een softwareproject. Je schat 400 uur, rekent met een interne kostprijs van €75 per uur en zet er 20 procent marge op. De klant gaat akkoord met een vaste prijs (fixed price) van €37.500. Na oplevering blijkt de marge nog geen 5 procent te zijn.

Wij zien dit vaak bij IT-dienstverleners en softwarebureaus, ook bij bureaus die netjes calculeren. De calculatie is correct. De oorzaken zitten in wat er na de calculatie gebeurt, en die oorzaken zijn goed beschreven in de literatuur over projectmanagement. Dit artikel loopt ze langs en laat zien hoe je de marge per sprint meet in plaats van bij de nacalculatie.

Waarom een vaste prijs de koppeling tussen kosten en omzet doorknipt

Bij een vaste prijs ligt de omzet van het project vast op het moment dat de klant tekent. De kosten liggen niet vast. Die bestaan uit de uren die je team er daadwerkelijk in stopt, tegen de kostprijs van de mensen die het werk doen. Alles wat na de handtekening verandert, komt daardoor volledig ten laste van je marge.

Je verkoopt met een vaste prijs in feite een verzekering op je eigen schatting. De klant koopt zekerheid, jij draagt het risico dat de schatting te laag was. Een verzekeraar rekent daar een premie voor. In de meeste offertes die wij zien staat die premie er niet expliciet in, of hij zit verstopt in een buffer die zelden overblijft (zie oorzaak 1).

Bij een uurtariefproject zie je een overschrijding op de eerstvolgende factuur. Bij een vaste prijs zie je hem alleen als iemand de gewerkte uren, tegen kostprijs, naast de afgesproken prijs legt. Dat gebeurt vaak pas bij de nacalculatie, als het project al is opgeleverd.

Vijf oorzaken die dieper liggen dan een verkeerde schatting

1. De buffer wordt opgemaakt voordat hij nodig is

Vrijwel elke calculatie bevat een buffer. In het voorbeeld is dat 40 van de 400 uur: de netto schatting was 360 uur, de 10 procent erbovenop is bedoeld voor tegenvallers. In de praktijk is die buffer aan het einde van het project bijna altijd op, en meestal zonder dat er een echte tegenvaller is geweest.

De verklaring is al in 1955 beschreven door Cyril Northcote Parkinson: werk zet uit tot het de beschikbare tijd vult. Eliyahu Goldratt werkte dit in Critical Chain (1997) uit voor projecten. Zodra een engineer weet dat er 400 uur beschikbaar is, wordt 400 uur het plan. De veilige schatting wordt de norm, de bufferuren worden gebruikt voor extra afwerking, voor werk dat toch nog even anders moet, of gaan verloren aan wat Goldratt het studentensyndroom noemt: pas beginnen als de deadline nadert, omdat er toch ruimte is. Komt er daarna wel een echte tegenvaller, dan is de buffer al weg.

Daar komt bij dat een schatting in veel bureaus impliciet een belofte is. Een engineer die 360 uur schat en er 380 nodig heeft, moet dat uitleggen. Bij 400 geschat en 400 gebruikt vraagt niemand iets. Het systeem beloont dus het opmaken van de buffer.

De oplossing die Goldratt voorstelt werkt ook bij softwareprojecten: laat het team schatten zonder veiligheidsmarge per taak, en zet de buffer als één post op projectniveau, onder beheer van de projectleider of de eigenaar. Het team plant tegen 360 uur. De 40 uur staan er wel, maar zijn geen doel. Per sprint rapporteer je hoeveel van de buffer is aangesproken tegenover hoeveel van het project af is. Is bij 40 procent voortgang al 60 procent van de buffer op, dan weet je genoeg.

2. De engineer bouwt een Mercedes, de klant heeft een Golf besteld

Een goede programmeur werkt naar perfectie toe. Dat is een eigenschap die je wilt hebben in je team, en tegelijk een van de grootste kostenposten in een vaste-prijsproject. De klant heeft een oplossing gekocht die zijn probleem oplost, en is tevreden met een acht. De laatste twee punten naar een tien kosten onevenredig veel uren: nettere code, een extra abstractielaag voor een toekomst die misschien nooit komt, een interface die mooier is dan gevraagd. In projectmanagementtermen heet dit gold plating.

Nergens is vastgelegd wat een acht is. Zonder expliciete acceptatiecriteria betekent "klaar" in de praktijk "de engineer is tevreden", en die lat ligt hoger dan de lat van de klant. De uren die daartussen zitten, worden gemaakt zonder dat iemand ervoor heeft gekozen.

De oplossing is een Definition of Done per feature, afgestemd met de klant voordat de sprint begint: wat moet het doen, wat moet het niet doen, wanneer is het geaccepteerd. Daarnaast helpt het om per feature een urenbudget mee te geven en dat zichtbaar te maken voor de engineer. Wie weet dat er twaalf uur voor een onderdeel staan, maakt andere keuzes dan wie alleen weet dat het "goed" moet worden. Het kwaliteitsniveau wordt daarmee een commerciële beslissing die je vooraf neemt, in plaats van een uitkomst die je achteraf constateert.

3. Meerwerk zonder commerciële reflex

Tijdens het project vraagt de klant om een aanpassing die niet in de scope stond. Meestal gaat het om een paar uur, en die worden gedaan zonder de prijs aan te passen, omdat niemand voor een paar uur de relatie onder druk wil zetten. Over de looptijd van een project van 400 uur loopt dat makkelijk op tot 40 of 60 uur extra. Dat is 10 tot 15 procent van de begroting, en het staat nergens.

Het onderliggende mechanisme is asymmetrie in herinnering. De klant onthoudt dat er "ja" is gezegd en beschouwt de aanpassing daarna als onderdeel van de afspraak. Het bureau onthoudt de uren niet, omdat ze nooit als meerwerk zijn geregistreerd. Bij de eindfactuur is er dus geen basis meer om erover te praten.

De oplossing is een meerwerkregister dat ook wordt bijgehouden als je besluit niets in rekening te brengen. Elke afwijking van de scope krijgt een regel: wat, hoeveel uur, wel of niet gefactureerd. Die regels komen als aparte post op de factuur, ook als er €0 achter staat. Dat maakt zichtbaar wat je weggeeft, geeft de klant een reëel beeld van wat hij ontvangt, en geeft je een onderhandelingspositie bij het volgende project. Daarnaast helpt een drempel: aanpassingen boven een bepaald aantal uren (bijvoorbeeld vier) gaan langs iemand met commerciële verantwoordelijkheid voordat ze worden gebouwd.

4. De bezetting wijkt af van de calculatie

De offerte rekent met een medior developer van €75 per uur. Die zit op een ander project of valt uit, en een senior van €95 neemt het over. Het werk wordt gedaan en de klant merkt niets, maar de kostprijs van die uren ligt 27 procent hoger dan begroot. In het voorbeeld gaat het om 60 uur, dus €1.200 aan marge.

Dit gebeurt meestal zonder dat iemand ernaar kijkt: er wordt gepland op beschikbaarheid, en de kostprijs komt in de planning niet voor. De oplossing is eenvoudig, maar vraagt dat de calculatie per rol wordt gemaakt en dat de urenregistratie de rol vastlegt: je volgt per project het gerealiseerde gemiddelde kostprijstarief tegenover het gecalculeerde. Wijkt dat af, dan is dat óf een bewuste keuze die je vastlegt inclusief het margegevolg, óf een signaal om de planning aan te passen.

5. Schattingen zijn te optimistisch, en vroeg in het proces vooral te breed

Daniel Kahneman en Amos Tversky beschreven in 1979 de planning fallacy: mensen onderschatten stelselmatig hoe lang een taak duurt, ook als ze weten dat vergelijkbare taken in het verleden uitliepen. De schatting wordt gemaakt vanuit het plan (wat moet er gebeuren), niet vanuit de ervaring (hoe liepen soortgelijke projecten af). Bent Flyvbjerg noemt de remedie reference class forecasting: schat op basis van de werkelijke uitkomsten van vergelijkbare eerdere projecten, en corrigeer de schatting van binnenuit daarmee.

Daar komt een tweede probleem bij dat losstaat van optimisme: het moment waarop de schatting wordt gemaakt. Barry Boehm bracht in 1981 in kaart hoe ver schattingen van softwareprojecten naast de werkelijke omvang zaten, afgezet tegen de fase waarin ze waren gemaakt. Steve McConnell werkte dat uit tot wat nu de cone of uncertainty heet. De cijfers: bij een eerste idee ligt de werkelijke omvang ergens tussen een kwart en vier keer de schatting. Na een goedgekeurde productdefinitie is dat de helft tot het dubbele, een factor twee. Na volledig uitgewerkte requirements twee derde tot anderhalf keer. Na functioneel ontwerp en architectuurkeuze 80 tot 125 procent. Na technisch ontwerp 90 tot 110 procent.

Voor het voorbeeldproject betekent een factor twee dat de 400 uur uit de calculatie in werkelijkheid 200 of 800 uur kunnen zijn, en dat beide uitkomsten op dat moment even goed verdedigbaar zijn. Een vaste prijs van €37.500 op een project dat ook 800 uur kan kosten, is een gok met een inzet van €22.500: dat is het verlies als het de bovenkant van de bandbreedte wordt. Bij een bandbreedte van 80 tot 125 procent is het uiterste 500 uur, dus €37.500 aan kosten. In het slechtste geval levert het project dan geen marge op, maar ook geen verlies. Dat is het punt waarop een vaste prijs verdedigbaar wordt.

Daaruit volgt een praktische regel voor wat acceptabel is. Een bandbreedte van 25 procent of minder, dus na functioneel ontwerp en architectuur: een vaste prijs is verantwoord, met een risico-opslag die de afwijking naar boven dekt. Een bandbreedte van 50 procent, dus na uitgewerkte requirements: een vaste prijs kan alleen met een bevroren scope en een expliciete risico-opslag, of beter een vaste prijs per fase. Alles daarvoor, een factor twee of breder: een indicatie in een bandbreedte, en geen prijs.

De onzekerheid wordt alleen kleiner door werk te doen: requirements uitschrijven, ontwerpen, de architectuur kiezen, een eerste sprint draaien. Langer nadenken over dezelfde schatting verandert de bandbreedte niet. Daarom verkopen bureaus die dit goed doen de eerste fase apart: een betaalde scoping- of ontwerpfase van een of twee sprints, met als opleverproduct een uitgewerkt ontwerp, een schatting met een bandbreedte van 25 procent en een vaste prijs voor de rest. De klant betaalt voor die fase. Wat hij ervoor terugkrijgt is een prijs waarop hij kan vertrouwen, in plaats van een prijs die het bureau halverwege moet heronderhandelen of stilzwijgend uit de marge betaalt.

De cijfers van Boehm en McConnell zijn gemiddelden over veel projecten. De eigen bandbreedte per fase haal je uit de nacalculaties: zet per afgerond project de schatting bij offerte, bij ontwerp en bij start van de bouw naast de werkelijke uren. Na tien projecten heb je je eigen cone, en die is meestal breder dan verwacht. Dat is reference class forecasting in de praktijk. Als je laatste tien vaste-prijsprojecten gemiddeld 18 procent meer uren kostten dan bij offerte geschat, is dat geen toeval, en hoort die 18 procent in de volgende calculatie thuis.

Schat daarnaast in drie punten: optimistisch, meest waarschijnlijk en pessimistisch, en reken met het gewogen gemiddelde (optimistisch plus vier keer meest waarschijnlijk plus pessimistisch, gedeeld door zes). Voor het voorbeeld: 360, 400 en 560 uur geeft een verwachting van 420 uur. Het verschil met de 400 uit de enkelvoudige schatting, 20 uur, is de risico-opslag die in de prijs hoort.

Hoe je de marge tijdens het project meet

De vijf oorzaken hierboven hebben één ding gemeen: ze worden zichtbaar in de uren, lang voordat ze zichtbaar worden in de factuur. De methode om dat te meten bestaat al decennia en heet earned value management. Hij is ontwikkeld voor grote bouw- en defensieprojecten, maar de kern past in een spreadsheet en werkt per sprint.

Je hebt drie getallen nodig. De geplande waarde: welk deel van het budget had volgens de planning nu besteed moeten zijn. De verdiende waarde: welk deel van de scope is daadwerkelijk af en geaccepteerd, uitgedrukt in budget. En de werkelijke kosten: de bestede uren tegen de werkelijke kostprijs per rol. De verhouding tussen verdiende waarde en werkelijke kosten is de cost performance index. Staat die op 1, dan loop je gelijk met de calculatie. Staat hij op 0,85, dan kost elke euro aan opgeleverd werk €1,18.

Terug naar het voorbeeld. Het project is gepland in acht sprints van 50 uur, kostenbudget €30.000. Na drie sprints is 37,5 procent van de scope geaccepteerd, dus de verdiende waarde is €11.250. De werkelijke kosten: 150 geplande uren tegen €75 plus 20 uur meerwerk door een senior tegen €95, samen €13.150. De cost performance index is 11.250 gedeeld door 13.150, ofwel 0,86. Deel het kostenbudget van €30.000 door 0,86 en je hebt een prognose van de totale kosten: ruim €35.000. Tegenover een prijs van €37.500 is dat een verwachte marge van ongeveer 6 procent. In de offerte stond 20.

Dit weet je na sprint drie. Er zijn dan nog vijf sprints om iets te doen: het meerwerk alsnog in rekening brengen, de bezetting terugbrengen naar de gecalculeerde mix, de scope van de resterende sprints strakker afbakenen, of bewust accepteren dat dit project minder oplevert en dat verrekenen in de relatie. Na oplevering blijft alleen de nacalculatie over. In het voorbeeld komt die uit op €35.700 aan kosten en 4,8 procent marge.

Wat je hiervoor nodig hebt: urenregistratie per project en per rol, een actueel kostprijstarief per rol, en een sprintafsluiting waarin scope wordt geaccepteerd, zodat de verdiende waarde geen schatting is. Het rekenwerk zelf kost per project een kwartier per sprint.

De commerciële kant: prijs het risico dat je verkoopt

Een vaste prijs is een keuze. Wie het risico van de schatting draagt, moet daarvoor betaald worden, en die premie hoort in een aparte risicoreserve op bedrijfsniveau, los van de buffer van het team (die wordt opgemaakt, zie oorzaak 1). Concreet: het team calculeert 360 uur, de projectleider beheert 40 uur buffer, en de commerciële prijs bevat daarbovenop een opslag voor het schattingsrisico. De hoogte daarvan volgt uit de driepuntsschatting en de bandbreedte van de fase: in het voorbeeld 20 uur bij een bandbreedte van 25 procent, en meer naarmate de bandbreedte breder is.

Bij grote onzekerheid past een andere contractvorm beter. Een vaste prijs per sprint met een variabele scope legt het risico bij de klant, die bepaalt wat er in elke sprint gebouwd wordt. Een uurtarief met een plafond deelt het risico. Jeff Sutherland beschreef een variant die in agile-contracten vaker voorkomt: de klant mag op elk moment stoppen en betaalt dan een percentage van het resterende budget, en mag scope ruilen zolang de totale omvang gelijk blijft. Welke vorm past, hangt af van de fase waarin je zit en dus van de bandbreedte van de schatting (zie oorzaak 5). Bij een factor twee, dus voordat de requirements zijn uitgewerkt, is een vaste prijs in geen enkele contractvorm verstandig. Verkoop dan eerst de ontwerpfase tegen een vaste prijs en geef daarna de prijs voor de bouw.

Hoe je de marge op vaste-prijsprojecten beschermt: zes maatregelen

Om de marge op een vaste-prijsproject te beschermen, moet je de vijf oorzaken hierboven elk apart afdekken en de marge per sprint meten. Dat komt neer op zes maatregelen die je binnen een maand kunt invoeren.

1. Splits de calculatie in een netto schatting en een projectbuffer, en beheer de buffer buiten het team. Rapporteer per sprint bufferverbruik tegenover voortgang.
2. Leg per feature een Definition of Done en een urenbudget vast, afgestemd met de klant, voordat de sprint begint.
3. Houd een meerwerkregister bij en zet elke afwijking als aparte regel op de factuur, ook bij €0.
4. Calculeer per rol en registreer uren per rol, zodat je het gerealiseerde kostprijstarief per project kunt volgen.
5. Bereken per sprint de cost performance index en de kostenprognose. Spreek af bij welke waarde (bijvoorbeeld onder 0,9) er een gesprek met de klant of intern volgt.
6. Voer de nacalculatie van elk afgerond project terug in de schattingsbasis voor de volgende offerte.

Veelgestelde vragen

Waarom wordt de buffer in een projectcalculatie altijd opgebruikt?

Omdat het team de buffer kent en de veilige schatting daardoor het plan wordt (de wet van Parkinson). Daarnaast belonen de meeste organisaties het gebruiken van de volledige schatting en bestraffen ze het overschrijden van een krappe schatting, waardoor niemand belang heeft bij het overhouden van bufferuren. De oplossing uit Critical Chain (Goldratt): schatten zonder veiligheidsmarge per taak en de buffer als één post op projectniveau beheren.

Hoe voorkom je dat developers meer bouwen dan de klant nodig heeft?

Door per feature vooraf met de klant vast te leggen wat geaccepteerd wordt (Definition of Done en acceptatiecriteria) en door een urenbudget per feature zichtbaar te maken voor de engineer. Zonder die twee wordt "klaar" bepaald door de kwaliteitsnorm van de engineer, en die ligt hoger dan wat de klant heeft gekocht.

Hoe bereken je de marge van een softwareproject tijdens het project?

Met earned value: deel de waarde van de geaccepteerde scope door de werkelijke kosten tot nu toe (bestede uren tegen kostprijs per rol). Die verhouding, de cost performance index, geeft samen met het kostenbudget een prognose van de totale kosten, en dus van de marge. Dit doe je per sprint of per maand.

Werkt earned value management ook bij agile softwareprojecten?

Ja, mits de sprintafsluiting een echte acceptatie van scope is. De verdiende waarde is dan het deel van de backlog dat is opgeleverd en geaccepteerd, uitgedrukt in budget. De werkelijke kosten komen uit de urenregistratie. De formele versie van earned value is uitgebreider, maar de cost performance index en de kostenprognose zijn voldoende om per sprint te sturen.

Wanneer kun je beter geen vaste prijs afspreken?

Zolang de bandbreedte van de schatting breder is dan 25 procent. Volgens de cone of uncertainty (Boehm, McConnell) is dat het geval tot het functioneel ontwerp en de architectuur zijn uitgewerkt; na een productdefinitie alleen zit een schatting nog tussen de helft en het dubbele van de werkelijke omvang. Verkoop in die fase een betaalde ontwerpfase, een vaste prijs per sprint met variabele scope, of een uurtarief met plafond, en geef de vaste prijs pas daarna.

Wat betekent een factor twee onzekerheid in een softwareschatting?

Dat de werkelijke omvang tussen de helft en het dubbele van de schatting ligt: 400 geschatte uren kunnen 200 of 800 uur worden. Dit is de bandbreedte direct na een productdefinitie, voordat requirements en ontwerp zijn uitgewerkt. De bandbreedte wordt alleen smaller door dat uitwerkwerk te doen, niet door langer over de schatting na te denken.

Fixed price of time & material bij softwareprojecten: wat is verstandiger?

Dat hangt af van de fase. Bij een bandbreedte van 25 procent of minder (na functioneel ontwerp en architectuur) is fixed price verantwoord en geeft het de klant de zekerheid die hij zoekt. Daarvoor past time & material met een plafond, of een vaste prijs per sprint met variabele scope, omdat het bureau anders een risico draagt dat het niet kan inschatten. Een combinatie werkt vaak het best: een betaalde ontwerpfase op time & material, daarna fixed price voor de bouw.

Hoe hoog moet de risico-opslag op een vaste prijs zijn?

Minimaal het verschil tussen de gewogen driepuntsschatting en de meest waarschijnlijke schatting. In het voorbeeld: 360, 400 en 560 uur geeft een verwachting van 420 uur, dus een opslag van 20 uur (5 procent) bij een bandbreedte van 25 procent. Bij een bredere bandbreedte wordt de pessimistische schatting hoger en de opslag dus groter. Corrigeer daarnaast met de gemiddelde overschrijding uit je eigen nacalculaties van vergelijkbare projecten.

Meer lezen: Projecten winstgevend houden: van calculatie tot evaluatie en Utilization rate vs. winstgevendheid, de metric die bureaus vergeten.

← Terug naar kennisbank