Vaste prijs of nacalculatie? Zo besteedt u software uit zonder twee keer te betalen

Op uw bureau liggen twee offertes voor hetzelfde systeem. In de eerste staat € 60.000, vaste prijs. In de tweede € 95 per uur, met een schatting van 500 tot 700 uur, dus ergens tussen € 47.500 en € 66.500. De eerste voelt veiliger, want u kent het bedrag.

Vaak is dat niet zo. Een vaste prijs neemt het risico van een verkeerde schatting niet weg. Hij bepaalt alleen wie het draagt en hoe u ervoor betaalt.

Wat beide modellen echt betekenen

Vaste prijs: de leverancier belooft een afgesproken resultaat voor een afgesproken prijs. Duurt het werk langer dan geschat, dan betaalt de leverancier. Daarom rekent hij een buffer in de prijs en bewaakt hij de afgesproken scope: elke wijziging wordt een meerwerkverzoek met een eigen offerte.

Nacalculatie (time and materials): u betaalt de werkelijk gewerkte tijd tegen een afgesproken tarief. Duurt het werk langer, dan betaalt u. In ruil daarvoor kunt u op elk moment van richting veranderen, zonder het contract opnieuw te onderhandelen.

	Vaste prijs	Nacalculatie
Wie draagt het schattingsrisico	De leverancier, als buffer in de prijs	U
Wijzigingen tijdens het project	Meerwerk en een nieuwe offerte	Een nieuwe prioriteit in de backlog
Wat u nodig hebt voor de start	Een gedetailleerd programma van eisen	Een helder doel en prioriteiten
Budgetbeheersing	Eén bedrag, zolang er niets verandert	Een maandplafond en regelmatige reviews
Waarvoor de leverancier betaald wordt	De afgesproken scope, in zo weinig mogelijk uren	Werk dat u graag blijft betalen
Past het best bij	Klein, duidelijk afgebakend werk	Alles wat onderweg zal veranderen

Waarom een vaste prijs vaak duurder uitvalt

Software schatten is moeilijk, voor iedereen. Onderzoek van McKinsey en de Universiteit van Oxford naar meer dan 5.400 IT-projecten liet zien dat grote projecten gemiddeld 45 % boven budget en 7 % boven planning uitkomen, met 56 % minder waarde dan voorspeld. Een vaste prijs maakt schatten niet makkelijker. Hij verplaatst de discussie over de schatting naar het contract.

In de praktijk zie je dat op vier manieren:

1. De buffer. Wie het bedrag garandeert, rekent een marge voor het onbekende. U betaalt die ook als alles goed gaat.
2. Meerwerk. Bedrijfssoftware verandert bijna altijd zodra gebruikers haar zien. “In het rapport moet nog één kolom” is twee dagen werk, en in een vaste-prijsproject een nieuwe offerte, een nieuwe goedkeuring en een nieuwe factuur.
3. Besparingen die u niet ziet. Als de uren opraken, wordt bespaard waar bij de oplevering niemand kijkt: tests, documentatie, beveiliging.
4. De discussie aan het eind. Is dit een fout of een wijziging? Elke onduidelijke zin in de specificatie wordt een discussie, net als u live wilt.

Er is ook een juridisch verschil. In Duitsland is een vaste-prijsproject meestal een Werkvertrag (§ 631 BGB): de leverancier is een resultaat verschuldigd, en u neemt het formeel af (Abnahme, § 640 BGB). Nacalculatie is meestal een Dienstvertrag (§ 611 BGB): de leverancier is het werk verschuldigd, niet een bepaald resultaat. Dat heeft gevolgen voor garantie en voor wie welk risico draagt. Andere landen kennen vergelijkbare onderscheidingen. Dit is geen juridisch advies; laat het contract door een jurist bekijken.

Wanneer een vaste prijs zinvol is

• Klein, duidelijk afgebakend werk. Eén koppeling, één rapport, een upgrade van .NET 8 naar .NET 10 met een bekende scope.
• Een specificatie die niet verandert. Bijvoorbeeld een koppeling die een toezichthouder of een ander systeem voorschrijft.
• De analyse aan het begin. Een paar weken om de processen te begrijpen, de eisen op te schrijven en de rest te schatten. Dat is de veiligste plek voor een vaste prijs.

Wanneer nacalculatie zinvol is

• De eisen gaan veranderen zodra gebruikers de eerste versie zien. Bij bedrijfssoftware is dat bijna altijd.
• Doorontwikkeling en onderhoud op lange termijn, waar het werk eigenlijk nooit af is.
• Het overnemen van een bestaand systeem, waar niemand weet hoeveel er in de code verborgen zit. Meer daarover in ons artikel over het overnemen van een .NET-applicatie.

De combinatie die in de praktijk het best werkt

1. Stap 1Analyse tegen een vaste prijs
2. Stap 2Eerste versie, maandplafond
3. Stap 3Demo elke twee weken
4. Stap 4Doorontwikkeling in maandblokken

De eerste beslissing heeft een bekende prijs: een analyse van een tot drie weken, waarna u de eisen, een globale architectuur en een schatting in bandbreedtes hebt. Daarna loopt het werk op nacalculatie met een maandplafond, en elke twee weken ziet u werkende software. U zit nooit langer dan een maand vast, en als de samenwerking niet werkt, vertrekt u met de analyse en de code.

Zo beschermt u zich bij nacalculatie

• Een maandplafond op papier. De leverancier waarschuwt u bij 80 % van het budget, niet pas als het op is.
• Een demo elke twee weken. Werkende software, geen statusrapporten.
• Uren per taak. Elk uur hangt aan een ticket dat u kunt openen.
• De code in uw repository, vanaf de eerste dag.
• Maandelijks opzegbaar. Als het niet werkt, kunt u stoppen.
• Schattingen in bandbreedtes, regelmatig bijgewerkt. “Drie tot vijf weken” is eerlijk. “Precies 27 dagen” niet.

Waarschuwingssignalen in een vaste-prijsofferte

• Een prijs zonder gedetailleerd programma van eisen. De leverancier heeft zijn eigen aannames geprijsd, niet uw systeem.
• “Meerwerk wordt apart berekend” zonder tarief en zonder procedure.
• Geen acceptatiecriteria. Niemand weet wanneer het werk af is.
• Geen woord over tests, documentatie of overdracht.
• Een prijs ver onder de andere. Het verschil komt meestal terug via meerwerk.

Realistische prijsbandbreedtes vindt u in ons artikel Wat kost een applicatie laten maken?, en dagtarieven in het artikel over het uurtarief van een freelance .NET developer.

Hoe u een specificatie schrijft die leveranciers eerlijk kunnen prijzen, leest u in ons artikel over het programma van eisen.

Hoe wij werken

Precies zo werken wij. ProCoding is een .NET-studio uit Split, Kroatië, en we bouwen en onderhouden bedrijfsapplicaties in .NET en Blazor. Meestal beginnen we met een korte analyse tegen een afgesproken prijs en werken we daarna in maandblokken met een plafond, met een demo elke twee weken en de code in uw repository vanaf de eerste dag, maandelijks opzegbaar. Voor grotere projecten kunt u ook een freelance .NET developer fulltime voor de duur van het project inzetten. De eerste stap is een gratis gesprek van 30 minuten, waarin we uw project en de offertes die u al hebt bekijken.

Bronnen

• Delivering large-scale IT projects on time, on budget, and on value, McKinsey, 1 oktober 2012
• § 631 BGB, Werkvertrag, § 640 BGB, Abnahme en § 611 BGB, Dienstvertrag, Gesetze im Internet