Vaste prijs of regie: wie draagt het risico als de behoefte verandert?

Vaste prijs of regie: die vraag komt op zodra u software laat ontwikkelen. De meeste antwoorden vergelijken twee manieren van factureren, en gaan ervan uit dat een vaste prijs zowel de prijs als de lijst met functionaliteiten vastlegt. Toch bestaan er twee soorten vaste prijs. Een vaste prijs met vaste scope begroot een programma van eisen. Een vaste prijs met vast budget en flexibele scope legt het budget en het op te lossen probleem vast, en laat de functionaliteiten die dat probleem oplossen meebewegen.

Een vaste prijs met vaste scope en regie hebben iets gemeen: allebei steunen ze op een voorspelling. De eerste voorspelt wat een lijst met functionaliteiten kost. De tweede voorspelt een aantal dagen. En die voorspelling wordt op één vraag getoetst: wie betaalt er als de behoefte onderweg verandert?

Want de behoefte verandert. 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). Niemand weet van tevoren welke. Dat blijkt pas bij het gebruik.

Vaste prijs of regie: wat is het verschil?

Bij een vaste prijs met vaste scope verbindt de leverancier zich ertoe een lijst met functionaliteiten op te leveren, beschreven in een programma van eisen, voor een prijs die bij ondertekening vastligt.

Bij regie stelt de leverancier mensen beschikbaar en factureert hij de bestede tijd, per dag. Wat bij ondertekening vastligt, is het dagtarief.

Bij een vaste prijs met vast budget en flexibele scope ligt de prijs vast, en het op te lossen probleem ook. Wat flexibel blijft, is de manier waarop het wordt opgelost: de functionaliteiten die worden ontwikkeld.

Een vaste prijs met vaste scope legt dus de totaalprijs en de lijst vast. Regie legt alleen het dagtarief vast. Een vaste prijs met vast budget legt het budget en het probleem vast, niet de lijst. Wie wil begrijpen wie het risico draagt, moet kijken hoe elk model aan zijn cijfers komt.

Hoe een vaste prijs met vaste scope tot stand komt

Alles begint bij het programma van eisen. De leverancier deelt de lijst op in taken en schat elke taak in werkdagen. Hij telt op. Hij vermenigvuldigt met zijn tarief. Daar komt een prijs uit.

Die prijs rust volledig op schattingen. En een schatting blijft een gok over werk dat nog niet gedaan is. Vasco Duarte beschrijft in NoEstimates (hfst. 1) de gegevens die hij tussen 2001 en 2003 bij één bedrijf verzamelde, over zeventien projecten. De gemiddelde vertraging ten opzichte van de schatting bedroeg daar 62 %. Een project dat op drie maanden was gepland, duurde bijna vijf maanden.

Een leverancier die zich aan een prijs verbindt, kent dat risico en verwerkt het in zijn bedrag. Evan Leybourn zegt het in How Much Does It Cost? A Guide to Agile Contracts (deel “Fixed contracts”) zonder omwegen: als prijs en scope allebei vastliggen, gaat de marge voor onvoorziene zaken omhoog voordat de offerte de deur uitgaat. Tomas Rybing beschrijft in Applied Capacity Planning With NoEstimates (p. 4-5) dezelfde praktijk van binnenuit: een factor op gevoel, waarmee de schatting wordt vermenigvuldigd om rekening te houden met de obstakels waarvan je weet dat ze komen, zonder te weten welke. Hij noemt waarden als 30 % of een verdubbeling.

Duarte (hfst. 2) laat zien waar dat ophoudt. Een te ruime marge maakt de offerte duurder dan die van de concurrenten. En als de tijd eenmaal is toegekend, rekt het werk zich uit tot het die tijd vult: de wet van Parkinson.

Hoe een project met vaste scope wordt gepland

De planning volgt dezelfde logica als de prijs. De geschatte taken worden in volgorde gezet, vaak in een Gantt-diagram, en gegroepeerd in mijlpalen. Elke mijlpaal heeft zijn datum. De acceptatietest komt aan het eind, als alles is opgeleverd.

Die planning is gedetailleerd, en juist dat maakt haar moeilijk te wijzigen. Duarte (hfst. 7) wijst erop: wie in een gedetailleerd plan de volgorde van het werk verandert, moet alles opnieuw doen: de opeenvolging van de taken, hun inhoud, wie ze uitvoert. Hoe eenvoudiger het plan, hoe makkelijker het veranderingen opvangt.

Maar de lijst wordt geschreven voordat de software bestaat, op de dag dat u het minst weet over hoe uw teams haar zullen gebruiken. Onderweg verschuift de behoefte. Een geplande functionaliteit is niet meer nodig. Een andere, waar niemand aan had gedacht, wordt dringend. Elk van die ontdekkingen valt buiten de getekende lijst. Er volgt een wijzigingsverzoek, apart begroot. Het wordt meerwerk, en dat meerwerk betaalt de klant.

De verschillen kunnen fors zijn. Bij 4.677 IT-projecten bedragen de werkelijke kosten gemiddeld 1,8 keer de geschatte kosten, oftewel 80 % meer (Flyvbjerg et al., JMIS 2022). Dat gemiddelde wordt omhooggetrokken door een minderheid van projecten met extreme overschrijdingen: in dezelfde steekproef ligt de mediane overschrijding dicht bij nul. Maar niemand weet bij ondertekening aan welke kant zijn project zal uitkomen.

Een vaste prijs met vaste scope dekt dus de schattingsfout, binnen de grenzen van de getekende lijst. Een veranderende behoefte dekt hij niet. Leybourn gaat verder voor het geval waarin prijs, scope en datum alle drie vastliggen: volgens hem heeft zo’n project weinig kans van slagen zonder enige flexibiliteit.

Hoe het budget op regiebasis tot stand komt

Bij regie is de prijs van een dag bekend. Het aantal dagen niet.

Toch wordt het startbudget op dezelfde manier opgesteld als bij een vaste prijs met vaste scope: iemand schat het aantal benodigde dagen en vermenigvuldigt dat met het tarief. Het verschil is dat dit bedrag niemand bindt. Het is een indicatief budget. De factuur volgt de werkelijk gewerkte dagen, elke maand onderbouwd met een urenverantwoording.

Duurt het werk twee keer zo lang als gepland, dan kost het twee keer zoveel. Het schattingsrisico ligt volledig bij de klant.

Toch ziet Leybourn (deel “Time and material contracts”) hierin het meest flexibele contract. De klant kan stoppen zodra wat het vervolg kost hoger is dan wat het oplevert. Om de uitgaven te begrenzen, beschrijft hij een variant met een plafond, dat hoog genoeg moet blijven om de investering rendabel te houden. Het budget wordt dan weer een grens, maar wel een grens die opnieuw is geschat.

Hoe een project op regiebasis wordt gepland

Dit is de kracht van regie: de lijst blijft aanpasbaar. De klant verschuift prioriteiten wanneer hij wil, zonder meerwerk. Veel teams werken dan in korte iteraties, van bijvoorbeeld twee weken. Ze schatten elk item in story points, meten hoeveel punten ze per iteratie afronden en leiden daar een datum uit af.

Duarte (hfst. 2) wijst op de zwakke plek van dat mechanisme: naarmate het team het werk beter begrijpt, schat het opnieuw wat er overblijft, en het gemiddelde waarmee wordt voorspeld, blijft verschuiven.

Hij stelt iets anders voor (hfst. 5). De omvang van items niet meer schatten, maar ze zo klein opdelen dat ze op elkaar lijken. Tellen hoeveel er per week klaar zijn. Dat tempo doortrekken om de rest te voorspellen. Hij voegt eraan toe dat werk dat onderweg wordt ontdekt geen scope creep is: het is ontdekte waarde (“value discovered”). En hij verdedigt een principe dat de vaste prijs met vaste scope op zijn kop zet (hfst. 2): leg de duur en de kosten vast, en laat de lijst variëren.

Rybing past dat idee toe onder de naam capaciteitsplanning (p. 2-6). Elke vrijdag telt zijn team de afgeronde taken op het bord, wat minder dan vijf minuten kost. Het gemiddelde geeft een capaciteit: 18 taken per week in zijn voorbeeld. Daarna volstaat een simpele deling: 213 bugs op te lossen, 18 per week, dus 12 weken, het dubbele van de 6 weken uit de planning. Of, binnen die 6 weken, ongeveer de helft van de oplossingen.

Duarte spreekt overigens niet meer van schatten, maar van voorspellen. Deze instrumenten zijn het beste wat er is als je verplicht bent te voorspellen. Ze beperken de schade, en ze duwen richting een flexibele scope. Maar ze steunen nog altijd op een vorm van schatten: ze gaan ervan uit dat het tempo van het verleden ook voor de rest geldt. Een gok over de toekomst is ingeruild voor een extrapolatie van het verleden.

Wat regie ten slotte verkoopt, zijn dagen. Niets in het model verplicht ertoe om elke maand bruikbare software in handen van uw teams te leggen. En de leverancier moet het gezag houden over de mensen die hij beschikbaar stelt. Als de klant hun werk dagelijks aanstuurt, kan de constructie naar Frans recht worden aangemerkt als verboden uitlening van arbeidskrachten: het Franse arbeidswetboek verbiedt elke activiteit met winstoogmerk die uitsluitend het uitlenen van arbeidskrachten tot doel heeft (artikel L8241-1).

Vaste scope of regie: zicht is nog geen grip

Voor Leybourn wordt een contract in de eerste plaats bepaald door het risico dat elke partij bereid is te dragen. De vaste prijs met vaste scope en regie worden als tegenpolen gepresenteerd. Toch gaan ze uit van dezelfde stap: het werk schatten voordat het wordt gedaan. De vaste prijs met vaste scope maakt van die schatting een prijs. Regie maakt er een indicatief budget van, en probeert daarna zicht te houden: urenverantwoordingen, bijhouden van het verbruik, een herberekende einddatum.

Waarom hechten we zo aan die voorspellingen? In zijn training “Un retour à l’essence de l’Agilité” zet Frédéric Leguédois de behoeften op een rij waaraan schattingen tegemoetkomen. Zicht geven en geruststellen horen daarbij. En in zijn lezing “Éloge de la simplicité” (Devoxx France, in het Frans) noemt hij de planning, tegenover de onzekerheid, een geruststellend beeld: “De planning is een organisatorische knuffel” (eigen vertaling).

Een knuffel stelt gerust. Hij beschermt nergens tegen. Een planning die elke week opnieuw wordt berekend, geeft de indruk dat u het budget stuurt. Het budget zelf blijft volgen wat het werk werkelijk kost.

Het probleem is niet de vaste prijs als zodanig. Het probleem is het budget en de lijst met functionaliteiten tegelijk vastleggen. Wie beide vastlegt, legt al het risico van de onzekerheid bij een van beide partijen, en niemand kan zich nog aanpassen. Wie niets vastlegt, laat het budget juist ontsporen.

Er blijft één combinatie over die geen van beide biedt: het budget en het op te lossen probleem vastleggen, de scope die dat probleem oplost flexibel laten, en ophouden te voorspellen wat niet te voorspellen is.

Vaste prijs met vast budget en flexibele scope: hier houdt het budget stand

Leybourn beschrijft een verwante vorm: een vaste prijs per week of per iteratie, een vaste datum, een flexibele lijst met functionaliteiten. De prijs komt niet meer uit een schatting: “The cost is effectively budgeted, instead of estimated” (de kosten worden gebudgetteerd, niet geschat). Toch blijft hij het tempo van acceptatie meten om te voorspellen hoeveel items er in de beschikbare tijd passen. Dat is nog altijd een voorspelling.

Op dat punt wijkt ons model ervan af. Het is een vaste prijs: een vast maandbudget, zonder einddatum die voorspeld of tempo dat doorgetrokken moet worden. Wat vastligt, is het budget en het op te lossen probleem. Wat flexibel blijft, is de scope, met andere woorden de functionaliteiten die dat probleem oplossen. Elke functionaliteit is een experiment dat steeds dezelfde vraag toetst.

Hoe het budget wordt bepaald. Het maandbudget wordt samen met u opgebouwd, op basis van uw cijfers en doelen, tijdens een tweede gesprek. Het gaat niet uit van een lijst met functionaliteiten die begroot moet worden, maar van de tijd die u besluit in uw software te investeren, afgewogen tegen wat het ontbreken ervan u kost. Het contract omvat 15 werkdagen per maand per teamlid. Wij ontwikkelen uw applicatie op maat tegen een vast budget, aan het einde van elke maand gefactureerd voor het geleverde werk.

Hoe het werk wordt gepland. Er is geen Gantt-diagram, er zijn geen mijlpalen met een datum, er wordt geen tempo doorgetrokken om een einddatum te voorspellen. De 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 past in wat Leguédois werken zonder projectie noemt. En hij komt op een andere manier tegemoet aan de behoefte aan zicht en geruststelling: Leguédois stelt voor daaraan te voldoen door het werk in kleine stukken op te knippen, snel in productie te gaan en geautomatiseerde regressietests in te zetten. Volgens hem zijn het die dingen die vertrouwen opbouwen. En de aanpak stelt één vraag: wat is nu het nuttigste om te doen?

Uw applicatie is binnen een maand bruikbaar. Bruikbaar betekent niet af: uw teams gebruiken haar vanaf de eerste maand. Wat het gebruik ons over een functionaliteit leert, passen we nog dezelfde dag toe. Elke dag ziet u de applicatie vooruitgaan op uw acceptatieomgeving.

Wat er gebeurt als de behoefte verandert. Het probleem blijft hetzelfde. Wat verandert, is de manier waarop het wordt opgelost, en er hoeft niets opnieuw onderhandeld te worden. De functionaliteit die niet meer nodig is, gaat van de lijst. De functionaliteit die dringend wordt, gaat voor. Het budget verandert niet. Wat we ontwikkelen, volgt wel wat uw teams leren door de applicatie te gebruiken.

Regie is het daarmee nog niet. Wat u elke maand ontvangt, is geen urenoverzicht. Het is software die uw teams gebruiken.

Het is een vaste prijs, maar geen vaste prijs met vaste scope. Met uw budget koopt u werk dat dit probleem voortdurend kleiner maakt, vanaf de eerste ontwikkeldag. We streven ernaar het volledig op te lossen, maar kunnen dat niet garanderen en er geen datum op zetten. U hoeft niet op die dag te wachten tot het probleem kleiner wordt. Elke maand ziet u wat het oplevert, en beslist u of u doorgaat. U kunt het contract op elk moment schriftelijk opzeggen, zonder opgaaf van redenen.

Een resultaatgarantie dient om een klant te beschermen die niet weg kan. Hier kunt u elke maand weg.

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.

Wie draagt het risico, per model?

Bij een vaste prijs met vaste scope draagt de leverancier de schattingsfout op de getekende lijst. De klant draagt de veranderende behoefte, meerwerk na meerwerk.

Bij regie draagt de klant allebei. Een wijziging levert geen meerwerk op, maar elke extra dag komt bij de factuur.

Bij een vaste prijs met vast budget en flexibele scope is er geen schatting meer die overschreden kan worden. Het budget is bekend voordat het werk begint, en het houdt stand, omdat niets van een voorspelling afhangt. Een veranderende behoefte verandert wat er wordt ontwikkeld, niet wat er wordt betaald. En de klant beslist elke maand zelf of hij doorgaat. Zijn technische partner heeft er dus alle baat bij goed werk te leveren, zodat de klant het contract de maand erna niet opzegt. Elke nuttige maand geeft de klant een reden om door te gaan, en zijn technische partner een reden om werk te maken van de volgende: een positieve spiraal.

Een vaste prijs met vaste scope blijft geschikt voor een behoefte die niet zal veranderen. Werk dat telkens precies hetzelfde terugkomt, wordt voorspelbaar. Software daarentegen wordt altijd voor het eerst ontwikkeld.

Verder lezen

Waarom een prijs uit opgetelde schattingen zo vaak het geplande budget overschrijdt: dat is het onderwerp van ons artikel over budgetoverschrijdingen.

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

Wilt u software laten ontwikkelen, of hebt u een tool die niet meer met uw bedrijf meegroeit? Zullen we kennismaken?

Bronnen

• V. Duarte, NoEstimates: How to Measure Project Progress Without Estimating, v1.21, Oikosofy, 2015: hfst. 1 (gegevens van 17 projecten, 2001-2003), hfst. 2 (marges en de wet van Parkinson, velocity, waardegerichte aanpak), hfst. 5 (afgeronde items tellen, “value discovered”), hfst. 7 (planning en het Gantt-diagram).
• B. Flyvbjerg, A. Budzier, J. S. Lee, M. Keil, D. Lunn, D. W. Bester, “The Empirical Reality of IT Project Cost Overruns: Discovering a Power-Law Distribution”, Journal of Management Information Systems, 39(3), 607-639, 2022 (5.392 IT-projecten verzameld, geschatte en werkelijke kosten beschikbaar voor 4.677; tabel 2: gemiddelde 1,8, mediaan 1,0).
• R. Kohavi en S. Thomke, “The Surprising Power of Online Experiments”, Harvard Business Review, september-oktober 2017.
• E. Leybourn, How Much Does It Cost? A Guide to Agile Contracts (essay): delen “The context of contracts”, “Time and material contracts”, “‘Fixed’ contracts” (gevallen 4, 5 en 7).
• T. Rybing, Applied Capacity Planning With NoEstimates, v1.0, 2015: p. 2-3 (wekelijkse meting), p. 4-5 (de factor), p. 5-6 (voorbeeld van de 213 bugs).
• F. Leguédois, “Éloge de la simplicité”, lezing, Devoxx France, video (vanaf 9 min 22 s), in het Frans.
• F. Leguédois, training “Un retour à l’essence de l’Agilité”, Ex Novo / Moovence, januari 2026, in het Frans: programma (module “Passer de Scrum à un fonctionnement sans projection”) en cursusmateriaal, deel IV “Le pourquoi des estimations” en deel V-B “Donner de la visibilité”.
• Frans arbeidswetboek (Code du travail), artikel L8241-1, Légifrance.