Je begint met een helder plan. Vijf features, acht weken, een vast budget. Drie maanden later heb je twaalf features, een overschreden planning en een team dat elkaar de schuld geeft.
Dit noemen ze scope creep. En het is bijna nooit de schuld van het bureau.
Het begint altijd hetzelfde
In het eerste gesprek zegt iemand: "en kunnen we ook even...". Dat ene zinnetje. Vermenigvuldig dat met vijf stakeholders over tien weken en je begrijpt waarom projecten ontsporen.
Ik zag het bij een middelgroot e-commercebedrijf. Ze wilden een nieuwe checkout bouwen. Simpel, overzichtelijk, snel. Maar in week drie vroeg marketing of het formulier ook kon worden gebruikt voor een nieuwsbriefinschrijving. In week vijf wilde sales een upsell-mechanisme toevoegen. In week zeven vroeg de directeur of we meteen ook de productpagina's konden aanpakken.
Elke aanvraag was op zichzelf logisch. Samen maakten ze het project onbeheersbaar.
Waarom je brein scope creep toelaat
Er is een psychologisch mechanisme dat hier een rol speelt: het sunk cost effect. Hoe meer je al hebt geïnvesteerd in een project, hoe moeilijker het wordt om nee te zeggen tegen uitbreidingen. Het voelt alsof je kansen laat liggen.
Maar elke toevoeging heeft een prijs die verder gaat dan de uren die het kost. Extra features betekenen extra afhankelijkheden, extra testwerk, extra documentatie en extra kansen op fouten. Een project dat twee keer zo groot wordt, duurt niet twee keer zo lang: het duurt drie of vier keer zo lang.
Er is ook een organisatorisch probleem: bij de meeste bedrijven is er niemand die officieel nee mag zeggen. De projectmanager wil niet moeilijk doen. Het bureau wil de klant tevreden houden. En dus groeit het project, stilletjes, week na week.
De drie duurste woorden in een digitaal project
"Terwijl we toch..."
Terwijl we toch de checkout aanpakken, kunnen we meteen ook de loginpagina verbeteren. Terwijl we toch het CMS vervangen, kunnen we meteen ook de blog opnieuw inrichten. Terwijl we toch een nieuwe productpagina bouwen, kunnen we meteen ook het filtermechanisme verbeteren.
Elke zin begint logisch. Samen zorgen ze ervoor dat je MVP een volledig herontwikkeld platform wordt.
Wat helpt: eigenaarschap over de scope
De oplossing is niet een strikter bureau of een gedetailleerder contract. De oplossing is één persoon die eigenaarschap neemt over de scope en die nee durft te zeggen: niet om moeilijk te doen, maar omdat een goed nee het verschil maakt tussen een product dat werkt en een project dat blijft hangen.
In de praktijk betekent dat:
Een harde scope-definitie aan het begin. Wat zit er wel in, wat zit er niet in. Niet als vage omschrijving, maar als concrete lijst. Alles wat niet op die lijst staat, is een change request: met eigen prijs en eigen tijdlijn.
Een beslissingsbevoegde stakeholder. Niet drie mensen die allemaal iets vinden, maar één persoon die de eindverantwoordelijkheid draagt. Als die persoon iets wil toevoegen, weet hij ook wat er af moet.
Wekelijkse scope-check. Elke week een korte vraag: zijn we nog bezig met wat we hebben afgesproken? Die vraag lijkt overbodig, maar stelt teams in staat om kleine afwijkingen te corrigeren voordat ze groot worden.
Het echte probleem is niet de scope
Als ik eerlijk ben, is scope creep meestal een symptoom van iets anders: onduidelijkheid over wat het product moet oplossen.
Als het doel helder is: meer conversie, minder klantenservicevragen, snellere doorlooptijd: dan is het makkelijk om te bepalen wat wel en niet in scope is. Als het doel vaag is: "een betere website" of "een modernere checkout": dan vult iedereen dat in op zijn eigen manier.
Daarom begin ik elk project met twee vragen. Wat is het probleem dat we oplossen? En hoe meten we of we dat hebben opgelost? Pas als die vragen beantwoord zijn, heeft het zin om te praten over features.
Hoe klein is klein genoeg?
Een MVP: Minimum Viable Product: is niet het kleinste product dat je kunt bouwen. Het is het kleinste product waarmee je kunt leren of je aanname klopt.
Dat verschil is belangrijk. Een MVP mag onaf aanvoelen. Het mag functies missen. Het mag niet schaalbaar zijn. Maar het moet het kernprobleem oplossen voor de kerngebruiker. Alles daarbuiten is een aanname die je nog niet hoeft te valideren.
Ik heb projecten gezien waarbij het MVP uiteindelijk groter was dan het originele product. Dat is geen MVP meer. Dat is gewoon een nieuw product met een misleidend label.
Praktisch: hoe voorkom je dit bij je volgende project?
Begin met een brutale prioritering. Schrijf alle gewenste features op. Verdeel ze in drie categorieën: moet (zonder dit werkt het product niet), wil (dit maakt het beter) en droom (dit zou fantastisch zijn). Bouw alleen de moet-categorie. Alles wat daarna nog tijd en budget over is, mag naar de wil-categorie.
Stel een change request proces in. Elke aanvraag buiten de originele scope krijgt een eigen beoordeling: wat kost het, wat levert het op, wat schuiven we op om het te kunnen doen?
En zoek iemand die de bewaker van de scope is. Iemand die de zakelijke doelen begrijpt, die technisch genoeg is om te snappen wat iets kost en die de positie heeft om nee te zeggen.
Als je dat iemand niet intern hebt, is dat precies waar een freelance product owner waarde toevoegt.
Herken je dit patroon in je eigen projecten? Een gesprek van 30 minuten is genoeg om te kijken waar het misgaat: en wat je eraan kunt doen.