Procurement ziet dit als een commerciële voorkeur. Dat is het niet. Het gaat erom wie de kosten van ongelijk gelijk draagt, en het verkeerd kiezen is hoe softwareprojecten adversarial worden.
Wat elk model eigenlijk zegt
Fixed price zegt: we spreken af wat gebouwd wordt, en ik neem het risico als de schatting fout uitvalt. De leverancier rekent dat risico in. Je betaalt een premie voor zekerheid — meestal 20–40% boven de eerlijke schatting.
Time and materials zegt: we spreken af een richting, en jij draagt het risico als het langer duurt. Je betaalt alleen voor gedaan werk. Je betaalt ook voor elk uur dat in de verkeerde richting gaat.
Geen van beiden is genereus. Beiden zijn rationeel. Het falen is het kiezen van het model dat niet aansluit hoe goed je het werk begrijpt.
Wanneer fixed price juist is
- De scope is echt bekend — een redesign van een bepaalde set schermen, een migratie met bekende bron en doel, een specifieke integratie.
- Je hebt een hard extern deadline (een funding milestone, een vakbeurs, een regelgevingsdatum) en wil dat iemand anders daar verantwoordelijk voor is.
- Je kunt budgetvariatie niet hebben en accepteert scope verkleining om het getal te beschermen.
- De relatie is nieuw en je wil een begrensd eerste engagement voordat je meer inzet.
De clausule die alles bepaalt: wat gebeurt er als scope verandert. Als het antwoord "we bespreken het" is, heb je een time-and-materials contract met extra stappen en een slechtere stemming.
Wanneer time and materials juist is
- Je bent nog aan het ontdekken wat het product moet zijn. Een prijs vastleggen op iets onbekends legt eigenlijk de scope vast, en die zal fout zijn.
- Je hebt iemand technisch aan je kant die kan beoordelen of de uren reëel zijn.
- Het werk is continu — eerder een roadmap dan een project.
- Prioriteiten zullen veranderen en je ziet liever omschakelen dan heronderhandelen.
De foutmodus
Fixed price faalt door elk gesprek in een onderhandeling te veranderen. De marge van de leverancier hangt nu af van minder doen, dus een goed idee in week drie wordt een change request. Kwaliteit wordt stilletjes de ontlastingsklep, omdat dat het enige is wat niemand uitgewerkt heeft. Je krijgt precies wat opgeschreven was, wat zelden wat je nodig had.
Time and materials faalt door het deadline weg te halen. Zonder vaste afloop geen forcing function op scope, en "terwijl we toch bezig zijn" wordt de duurste zin in het project. Zes maanden later heb je uitstekende code en geen product — zie waarom bureaus zes maanden nemen.
Het model dat ik zou aanraden
Een fixed-price, fixed-duration window met verhandelbare inhoud. Twee weken, één prijs, van tevoren afgesproken. Wat in die twee weken gaat ligt vast en kan tot het moment dat je eraan begint veranderen.
Dit inverteert de gebruikelijke ruil. De leverancier draagt het delivery-risico (datum en prijs zijn vast) en jij houdt de flexibiliteit (wat gebouwd wordt kan schuiven). Niemand wordt prikkeld om over scope te ruziën, omdat scope niet wat beschermd wordt — de window is.
Het werkt alleen als de window kort is. Een vast twaalfmaands engagement met flexibele scope is dit niet; het is een retainer met een mooi verhaal.
Wat gebeurt er eigenlijk als scope verandert
Dat zal. De vraag is wat het contract mensen ertoe aanzet om eraan te doen.
Bij fixed price is een change request een onderhandeling met een marge eraan. De leverancier moet het prijzen, jij moet het goedkeuren, en nu staan jullie allebei iets tegenover elkaar. De rationale zet voor de leverancier is de originele scope eng uit te leggen; de rationale zet voor jou is het breed uit te leggen. Niemand handelt verkeerd en de relatie verslechtert toch.
Bij time and materials is een verandering gewoon volgende week's werk. Wrijvingsloos — wat het probleem is. Niemand wordt gedwongen om af te vragen of de verandering het waard is, omdat de kosten nooit als een keuze zichtbaar worden. Die verschijnen drie maanden later als een burn rate.
Bij een fixed window kost een verandering iets zichtbaars en direct: het verdringt iets anders in dezelfde twee weken. Dat is de gezondste versie, omdat de trade-off expliciet is en gemaakt door wie het moet maken — jij.
De hybride die de meeste mensen echt willen
In de praktijk werkt voor meeste productwerk deze vorm:
- Een kleine betaalde discovery, fixed price. Een paar dagen tot een week. Eindigt in een scope die jullie allebei geloven, niet in een deck. Als de leverancier dit niet doet, plannen ze te discovery op jouw budget.
- Fixed-price, fixed-duration delivery windows. Twee of drie weken elk, van tevoren geprijsd, inhoud afgesproken aan het begin van elk. Schip iets echts aan het einde van elke window.
- Time and materials voor de staart. Support, kleine wijzigingen, de lange stille periode na launch. Niemand moet een prijs vastleggen op werk dat nog niet bedacht is.
De discovery stap is wat de fixed prices eerlijk maakt. Zonder die, is een leverancier die een prijs vastlegt aan het gokken, en de gok bevat een marge voor hun eigen onzekerheid die jij betaalt.
Tarief versus totale kosten
Een € 400/dag leverancier die twee weken opstarttijd nodig heeft kost meer dan een € 900/dag leverancier die dinsdag begint te produceren. Dit is de meest voorkomende valse besparing in softwareprocurement, en ze overleeft omdat het dagtarief het getal in de spreadsheet is en opstarttijd niet.
Als je leveranciers vergelijkt, vraag elk: wanneer zie ik het eerste werkende ding? Die enkele datum codificeert opstarttijd, processgewicht, personeelsrealiteit en vertrouwen. Het is meer voorspellend voor totale kosten dan het tarief.
Clausules waard meer dan het tarief
Welk model je ook pikt, deze bepalen of het werkt:
- IP assignment bij betaling, niet bij completion. Als het project vroeg stopt, zul je eigenaar van wat je betaald hebt.
- Sourcetoegang van dag één. Niet handoff op het einde. Als je de repository niet ziet, kun je niets verifiëren.
- Een naamgenoemde persoon. Contracten zijn met bedrijven; werk wordt gedaan door mensen. Noem ze en zeg wat er gebeurt als ze wisselen.
- Een exit die niet strafbaar is. Een leverancier vertrouwvol in hun werk heeft geen lock-in clausule nodig.
- Definition of done. Opgeschreven, van tevoren, in termen die een niet-engineer kan controleren.
Als je deze vijf goed doet, speelt het prijsmodel veel minder mee dan iemand in de kamer nu gelooft.