Een offerte aanvragen voor een webapplicatie of portaal voelt soms alsof je een aannemer belt zonder te weten hoeveel kamers je huis moet hebben. Je weet dat je iets wil bouwen, je hebt een idee van het resultaat, maar de details zijn nog vaag. Dat is geen probleem op zich, want een goede developer helpt je om die details scherp te krijgen. Het probleem ontstaat wanneer die details onbesproken blijven en er toch een prijs op tafel komt. Want een offerte die is gebaseerd op een vage omschrijving, is eigenlijk geen offerte. Het is een gok.
Wat een scope eigenlijk is, en waarom het je geld bespaart
Scope is het antwoord op de vraag: wat gaan we precies bouwen, en wat niet? Klinkt simpel, maar in de praktijk bevat bijna elk project aannames die nooit hardop zijn uitgesproken. Neem een dienstverlener die een klantenportaal wil waarbij klanten hun eigen facturen kunnen bekijken. Duidelijk genoeg, totdat de vraag komt: mogen klanten ook betalingen doen vanuit het portaal? Kunnen ze documenten uploaden? Krijgen ze een notificatie als er een nieuwe factuur klaarstaat? Elk van die vragen vertegenwoordigt uren aan ontwikkeling, en als ze niet besproken zijn, gaat de een ervan uit dat het erbij hoort en de ander niet.
Goede scopebepaling voorkomt dat discussie achteraf. Wat op papier staat, is wat er gebouwd wordt. Alles daarbuiten valt onder meerwerk, met een apart prijskaartje. Dat is niet onaardig of rigide, het is eerlijk voor beide partijen.
De meest directe manier om scope vast te leggen is een functionele beschrijving per scherm of per proces. Niet "klanten kunnen inloggen", maar: welk type account bestaat er, hoe reset iemand zijn wachtwoord, wat ziet een klant na het inloggen als eerste, en welke acties kan hij vanaf die pagina nemen? Die detaillaag kost tijd om te schrijven, maar het is tijd die je anders betaalt in discussies, aanpassingen en herstelwerk tijdens of na het project.
Vaste prijs werkt alleen als de scope dicht zit
Een vaste prijs is aantrekkelijk omdat je weet waar je aan toe bent. Geen verrassingen op de eindrekening, een duidelijk budget, en de zekerheid dat het project klaar is wanneer het klaar is. Maar een vaste prijs is alleen houdbaar als de scope nauwkeurig gedefinieerd is. Is dat niet het geval, dan heeft de developer twee opties: hij rekent een ruime buffer in om het risico te dekken, of hij maakt keuzes tijdens de bouw die jij nooit bewust hebt gemaakt.
Een ruime buffer klinkt logisch vanuit het perspectief van de developer, maar het betekent dat jij betaalt voor onzekerheid die je zelf had kunnen wegnemen. In projecten waar ik een vaste prijs afgeef, besteed ik altijd eerst tijd aan het doorlopen van het volledige proces samen met de opdrachtgever. We beschrijven scherm voor scherm, stap voor stap, inclusief uitzonderingen en foutpaden. Dat kost een paar uur aan voorbereiding, maar het voorkomt dat ik halverwege het project ontdek dat "eenvoudig rapportage" eigenlijk drie exportformaten, een datumfilter en een rolgebaseerde toegangscontrole betekende.
Wil je echt met een vaste prijs werken, dan is mijn advies: stel die gedetailleerde functionele beschrijving op vóórdat je een offerte vraagt. Stuur die naar drie developers en kijk of ze dezelfde scope lezen. Als hun offertes sterk van elkaar afwijken, is dat vrijwel altijd een teken dat ze verschillende aannames hebben gemaakt over wat er gebouwd wordt.
Wanneer uurtarief verstandiger is
Er zijn projecten waarbij een vaste prijs simpelweg niet eerlijk is, voor geen van beide partijen. Dat zijn de projecten waar de kern van het product nog niet vaststaat. Denk aan een nieuwe webapplicatie waarbij de werkwijze van de eindgebruiker pas duidelijk wordt als ze het product in handen hebben. Of een project waarbij de integratie met een extern systeem afhankelijk is van documentatie die nog niet beschikbaar is. In die gevallen is werken op uurtarief de eerlijkere aanpak, mits je de juiste afspraken maakt over rapportage en budget.
Werken op uren betekent niet dat je blanco een opdracht geeft. Je spreekt een weekbudget af, een maximum aantal uren per fase, en je spreekt af wanneer je bijgestuurd wilt worden als de realisatie afwijkt van de schatting. Wat je wilt voorkomen is dat je aan het einde van de maand een rekening krijgt zonder dat je gedurende die tijd inzicht had in waar de uren naartoe gingen. Vraag wekelijkse updates met een korte omschrijving per activiteit. Dat geeft je de controle die je bij vaste prijs vanzelfsprekend vindt, maar die je bij uurtarief actief moet inregelen.
Ik merk in projecten dat uurtarief het beste werkt in de ontdekfase, de eerste weken van een project waarbij de architectuur bepaald wordt, de keuzes voor datastructuren worden gemaakt en de eerste versie van de applicatie tot stand komt. Daarna is de scope doorgaans duidelijk genoeg om per fase of per onderdeel een vaste prijs te zetten. Dat gecombineerde model geeft de meeste zekerheid zonder de starheid van een volledig vaste-prijs-contract voor iets dat nog niet scherp te definiëren is.
De stap die de meeste projecten overslaan
Vrijwel elk project waarbij het budget ontspoorde of de oplevering later was dan verwacht, had één gemeenschappelijke oorzaak: er was geen moment geweest waarop de scope door beide partijen expliciet was goedgekeurd. De offerte was geaccepteerd, het project was gestart, en de verwachtingen liepen ergens halverwege uiteen.
De oplossing daarvoor is een scopedocument dat allebei ondertekenen. Niet als juridisch wapen, maar als bewijs dat je dezelfde tekening hebt bekeken. Een scopedocument hoeft niet uitgebreid te zijn. Een Google Doc met per scherm een korte beschrijving van de werking, aangevuld met een lijst van wat expliciet buiten scope valt, is al genoeg om de meeste misverstanden te voorkomen. Die buitenscope-lijst is minstens zo belangrijk als de beschrijving van wat er wél gebouwd wordt. Als ik in een project beschrijf dat de webshop bestellingen verwerkt maar geen retourmodule bevat, weet de opdrachtgever dat hij later een apart gesprek en een apart budget nodig heeft als hij die mogelijkheid wil toevoegen.
Beslissers die voor het eerst een webapplicatie laten bouwen, onderschatten soms hoeveel invloed zij zelf hebben op de prijs en de doorlooptijd van een project. Hoe nauwkeuriger jij je wensen beschrijft, hoe scherper de offerte wordt die je terugkrijgt. Een developer kan je helpen om die beschrijving te schrijven, maar hij kan jouw bedrijfsproces niet kennen. Jij bent de expert op dat vlak. Zie scopebepaling daarom niet als iets dat de developer voor jou regelt, maar als een samenwerking waarbij jij de inhoud levert en de developer de technische vertaalslag maakt.
Als je me vraagt wat het verschil maakt tussen een project dat soepel verloopt en één dat stroef gaat, is het antwoord negen van de tien keer niet de techniek. Het is de kwaliteit van het gesprek dat vóór het eerste coderegeltje heeft plaatsgevonden. Een goed voorbereid project is ook gewoon prettiger om aan te werken. Beide partijen weten wat er moet gebeuren, er is ruimte voor overleg over details zonder dat het meteen meerwerk is, en aan het einde van het project is de oplevering een bevestiging van wat was afgesproken, geen verrassing in positieve of negatieve zin.
Webapplicaties, portalen en maatwerk-webshops zijn precies de projecten waarbij ik dit soort scopegesprekken standaard aan het begin doe. Op https://pimvdmolen.nl/diensten/webapplicaties lees je hoe ik dat aanpak en welke typen projecten ik bouw. Wil je sparren over jouw project of een offerte aanvragen, dan kun je terecht via https://pimvdmolen.nl/contact.