Een vaste prijs voelt veilig. Je tekent voor een bedrag, je weet waar je aan toe bent en er zijn geen verrassingen achteraf. Dat is tenminste de gedachte. Wat er in de praktijk gebeurt, is dat opdrachten groeien. Er komen wensen bij, er worden dingen anders bedacht, en wat aanvankelijk een kleine aanpassing leek wordt een discussie over wat nu eigenlijk "in scope" was. Voor je het weet, staat er een meerwerk-factuur op de mat die het initiële voordeel van die vaste prijs grotendeels wegvaagt. Dit artikel gaat niet over welk prijsmodel het beste is, want dat hangt af van het project. Het gaat over waarom budgetten ontsporen, wanneer dat jouw risico is, en hoe je dat voorkomt.
Waarom scope het echte probleem is, niet de prijs
Het misverstand is dat de prijs bepaalt of een project betaalbaar is. Dat klopt niet. De scope bepaalt dat. Een vaste prijs op een vaag omschreven project is geen garantie voor kosten, het is een garandering voor conflict. Hoe vager de beschrijving van wat er gebouwd wordt, hoe meer ruimte er is voor interpretatie aan beide kanten. De ondernemer denkt dat een "klantenportaal" ook rapporten exporteren inhoudt. De developer gaat er vanuit dat het alleen een loginpagina met een overzicht is. Allebei zijn ze overtuigd dat hun interpretatie de logische is.
Wat ik in mijn werk zie, is dat dit soort mismatches niet ontstaan door kwade wil, maar door de aard van softwareprojecten. Software is abstract totdat het bestaat. Je kunt een interieur zien voordat het gebouwd wordt, een logo beoordelen als ontwerp. Maar een webapplicatie is pas echt te beoordelen als je erin klikt. Dat betekent dat wensen pas concreet worden op het moment dat er iets te zien is, en dat is precies het moment waarop de scope verandert.
De kern van het probleem zit in functionele specificaties die te algemeen zijn. Zinnen als "de gebruiker moet kunnen inloggen", "er moet een dashboard zijn" of "klanten kunnen hun gegevens beheren" klinken concreet, maar zijn het niet. Inloggen via e-mail, via SSO, met twee-factor-authenticatie? Een dashboard met welke data, voor welke rollen, met welke exports? Elke open vraag is een potentieel meerwerk-moment.
Wanneer meerwerk terecht is en wanneer niet
Niet elke extra factuur is oneerlijk. Softwareprojecten evolueren, en dat is normaal. Als je halverwege een project besluit dat de webshop ook een abonnementenmodule nodig heeft die er in de oorspronkelijke opdracht niet in zat, is het logisch dat daar extra kosten aan vastzitten. Meerwerk is terecht wanneer er sprake is van een aantoonbare scope-uitbreiding: iets wat niet in het oorspronkelijke voorstel stond en nooit redelijkerwijs kon worden afgeleid uit de opdracht.
Problematisch wordt het wanneer meerwerk wordt ingeroepen voor dingen die eigenlijk onder normaal vakmanschap vallen. Foutafhandeling bij een formulier, een responsief ontwerp dat ook op mobiel werkt, basisbeveiliging van een loginpagina. Dit zijn geen extra's, dit is wat je mag verwachten van een professioneel gebouwde applicatie. Als een developer dit als meerwerk opvoert, klopt er iets niet in de offerte of in de werkwijze.
Het onderscheid maken vraagt om een goede offerte die expliciet omschrijft wat er wél en wat er níet in zit. Dat klinkt logisch, maar ontbreekt verrassend vaak. Een offerte die beschrijft wat er gebouwd wordt zonder te vermelden wat er buiten valt, is een uitnodiging voor discussie. Wat ik altijd doe bij een offertetraject, is expliciet opschrijven wat buiten de scope valt. Niet omdat ik wil beknibbelen, maar omdat het aan beide kanten verwachtingen scherpstelt.
Hoe een scherpe scope het budget beschermt
Een goed uitgewerkte scope is geen bureaucratisch document, het is een zakelijk instrument. Het beschermt jou als opdrachtgever tegen onverwachte kosten, en het geeft een developer het mandaat om nee te zeggen tegen verzoeken die buiten de afspraken vallen, zonder dat daar een conflict over hoeft te ontstaan. Een scope die per scherm of per functie omschrijft wat het systeem doet, maakt meerwerk objectief aantoonbaar.
Schermen uitwerken als wireframes of functionele beschrijvingen is daarvoor het meest directe middel. Per pagina of module leg je vast wat een gebruiker kan doen, welke data er getoond wordt, welke acties er zijn en wat er vervolgens gebeurt. Dat hoeven geen technische documenten te zijn. Een beschrijving van twee alinea's per scherm is al genoeg om interpretatieverschillen te voorkomen. Bij grotere projecten werk ik met een functioneel ontwerp dat voor akkoord wordt getekend voordat er een regel code wordt geschreven.
Iteratief werken helpt daarbij ook. Wanneer je een project opknipt in fasen en na elke fase evalueert wat er vervolgens nodig is, houd je controle over het budget zonder dat je op voorhand alles vast moet hebben. Fase één levert dan een werkend fundament op. Op basis daarvan kun je als ondernemer bewust besluiten wat de volgende stap is en hoeveel dat mag kosten. Dit model werkt goed bij webapplicaties en portalen waarbij de exacte behoeften pas duidelijk worden als er iets staat om op te reageren.
Wat je bij een offerte altijd moet controleren
Vraag bij elke offerte door op wat er níet in staat. Niet als wantrouwen, maar als voorbereiding. Zijn revisieronden inbegrepen, en zo ja, hoeveel? Is het ontwerp inclusief responsief gedrag op mobiel? Valt het koppelen aan externe systemen zoals een boekhoudpakket of CRM binnen de vaste prijs, of is dat apart? Is er een testfase voorzien en wie is verantwoordelijk voor het aanleveren van testgevallen? Dit soort vragen levert soms ongemakkelijke antwoorden op, maar dat is de bedoeling: je wil weten waar de grens ligt voordat je erin loopt.
Kijk ook naar de betalingsstructuur. Een developer die de volledige betaling bij oplevering vraagt, heeft een ander risico-profiel dan iemand die werkt met een aanbetaling, een tussentijdse mijlpaal en een slottermijn. Gespreid betalen op basis van zichtbare resultaten geeft jou als opdrachtgever controlemomenten. Het dwingt ook af dat er daadwerkelijk tussentijds iets opgeleverd wordt en dat je niet pas na maanden ontdekt dat het project een andere richting is opgegaan.
Tariefsvorm, vaste prijs of uren, maakt pas echt verschil als de scope helder is. Met een vage scope is een vaste prijs een gok voor beide partijen. Met een scherpe scope kun je ook werken op uren zonder dat het budget compleet openligt, omdat je per fase afspreekt hoeveel uur er beschikbaar is en wat daarvoor opgeleverd wordt. De combinatie van een heldere scope én een redelijke tariefsvorm is wat projecten betaalbaar en beheersbaar houdt.
Wat ik merk bij projecten die wél goed verlopen, is dat er aan het begin meer tijd in de voorbereiding zit dan de opdrachtgever aanvankelijk verwacht. Die tijd betaalt zichzelf terug doordat er gedurende het project minder bijgestuurd hoeft te worden, minder discussie is over wat er afgesproken was, en minder onverwachte facturen op de mat vallen. Investeren in een goede briefing en een uitgewerkt voorstel is geen overhead, het is risicobeheer.
Als je een webapplicatie, portaal of maatwerk-systeem wilt laten bouwen en wil weten hoe ik met scope, offerte en meerwerk omga, vind je meer informatie op https://pimvdmolen.nl/diensten/webapplicaties. Neem gerust contact op via https://pimvdmolen.nl/contact als je een project wilt bespreken of een tweede mening wilt over een offerte die je hebt ontvangen.