Vastgelopen projecten crashen niet, ze verzanden
U herkent het misschien. Het project is niet dood. Niemand heeft de stekker eruit getrokken, er is geen dramatisch moment geweest. Het is alleen al maandenlang “bijna klaar”. Elke update klinkt redelijk, elke vertraging heeft een verklaring, en toch staat er nog steeds geen werkende software waar u op kunt klikken. Het project crasht niet — het verzandt.
Dat is precies wat het zo verraderlijk maakt. Een crash dwingt u tot handelen. Verzanding doet dat niet. U blijft wachten, hopen op de volgende sprint, en ondertussen lopen de kosten door en brokkelt het vertrouwen af. De dure fout is bijna nooit de redding zelf. De dure fout zijn de maanden die u wacht voordat u de beslissing neemt om in te grijpen.
Dit artikel geeft u een eerlijke beslisvolgorde: eerst vroeg signaleren, dan snel diagnosticeren, vervolgens eerlijk kiezen tussen redden en opnieuw bouwen, daarna mensen en governance resetten, en tot slot zorgen dat het beklijft. Geen schuldigen aanwijzen — daar wordt een project niet beter van. Wel een nuchtere route terug naar werkende software, gemaakt voor een drukke MKB-ondernemer die de zaak ondertussen gewoon moet laten doordraaien. Wij denken daarbij in EU-gehoste oplossingen met een mens in de lus: techniek die u kunt vertrouwen, en mensen die verantwoordelijkheid nemen.
Waarom vroeg ingrijpen het hele spel is
De eerste vraag die elke ondernemer stelt is: wanneer grijp ik in? Het eerlijke antwoord: zodra de waarschuwingssignalen zich opstapelen, niet pas wanneer de deadline definitief gemist is. Tegen de tijd dat de einddatum sneuvelt, bent u meestal al maanden te laat.
Het gaat om wat we beslis-latentie noemen: de tijd tussen “er klopt iets niet” en “we doen er iets aan”. Elke week twijfel telt op. De kosten stapelen, en wat misschien nog het pijnlijkst is: het aandeel herbruikbare code neemt af naarmate er langer in een wankele richting wordt doorgebouwd. Wachten maakt de uiteindelijke ingreep niet alleen duurder, maar ook ingrijpender.
Hanteer daarom een eenvoudige vuistregel: twee of meer waarschuwingssignalen die langer dan twee sprints aanhouden, zijn de trigger voor een diagnose. Niet voor paniek, niet voor het ontslaan van uw team — voor een diagnose. Dat is goedkope verzekering. Onderzoek van McKinsey & Company samen met de Universiteit van Oxford laat zien dat de kosten van grote IT-projecten meegroeien met de looptijd: elk extra jaar duwt de overschrijdingen verder omhoog. Die cijfers gaan over grote, vaak enterprise-projecten, maar de les is voor het MKB onverkort geldig: tijd is de vijand. Vroeg ingrijpen is goedkoper dan later gelijk krijgen.
De 7 waarschuwingssignalen van een vastlopend project
Hieronder een bruikbare checklist. Bij elk signaal staat in één zin wat het werkelijk betekent.
Eén. De planning schuift herhaaldelijk op. Wat het echt betekent: niet één tegenvaller, maar een patroon — het team heeft geen grip meer op de scope of de complexiteit.
Twee. De scope groeit zonder schriftelijke afspraken. Wat het echt betekent: er wordt steeds meer beloofd in de wandelgangen, en niemand bewaakt nog wat “klaar” eigenlijk inhoudt.
Drie. De technische schuld groeit sneller dan de functionaliteit. Wat het echt betekent: er gaat meer energie naar het lapwerk van gisteren dan naar de waarde van morgen.
Vier. Sleutelfiguren vertrekken. Wat het echt betekent: met elke vertrekkende ontwikkelaar loopt ongedocumenteerde kennis de deur uit — kennis die in niemands hoofd anders zit.
Vijf. De communicatie wordt reactief en defensief. Wat het echt betekent: updates gaan over verklaren waarom iets niet af is, niet over wat wel werkt.
Zes. Demo’s tonen telkens dezelfde functies. Wat het echt betekent: er wordt beweging gesuggereerd, maar er is geen werkelijke voortgang onder de motorkap.
Zeven. Er is geen aantoonbaar werkende software waar u zelf op kunt klikken. Wat het echt betekent: dit is het zwaarstwegende signaal — als u het na maanden nog steeds niet kunt aanraken, bestaat het waarschijnlijk nog niet.
Doe de zelftest: hoeveel van deze zeven herkent u? Bij één los signaal is er doorgaans niets aan de hand. Maar herkent u er twee of meer, en houden die langer dan twee sprints aan, dan is dat geen pech meer — dan is het een patroon, en het moment voor een eerlijke diagnose.
De diagnose in 48 uur: waar we echt naar kijken
Een goede diagnose is strak in de tijd gezet. Wij doen het in zo’n 48 uur, en dat is geen toeval: een diagnose die zelf gaat verzanden, is onderdeel van hetzelfde probleem. U heeft geen rapport van zes weken nodig om te weten dat het niet goed gaat. U heeft een eerlijk oordeel nodig voordat u nog een euro uitgeeft.
We kijken naar vier dingen. Ten eerste de code: hoe is de structuur, zijn er tests, en is de kennis gedocumenteerd of zit die alleen in de hoofden van mensen? Code die niemand durft aan te raken is een waarschuwing op zich.
Ten tweede de mensen. We spreken de betrokkenen apart — ontwikkelaars, projectleider, en u als opdrachtgever. Apart, want pas dan komt het verschil naar boven tussen de gerapporteerde status en de werkelijke status. Dat gat is vaak het echte probleem.
Ten derde het fundament: de architectuur. Is dit een huis met een slechte verflaag, of zit de scheur in de fundering? Dat onderscheid bepaalt straks bijna alles.
Ten vierde schatten we in hoeveel van de bestaande code werkelijk herbruikbaar is. Niet hoeveel er gemaakt is, maar hoeveel er deugt en bruikbaar blijft.
De uitkomst is bewust simpel: één pagina met een eerlijk oordeel — doorgaan of niet — plus een herstelplan met een prijskaartje eraan. Geen vaagheid, geen “nog even kijken”. Een diagnose die geen knoop doorhakt, heeft zijn werk niet gedaan.
Redden of opnieuw bouwen: waarom de vuistregel geen oordeel is
Wij hanteren een vuistregel die houvast geeft: is minder dan ongeveer 30% van de code herbruikbaar, dan neigt het naar opnieuw bouwen; is meer dan ongeveer 50% bruikbaar, dan neigt het naar redden. Let op het woord neigt. Deze regel is een startsignaal, geen beslissing. Hij vertelt u waar het gesprek begint, niet waar het eindigt.
Wat er zwaarder weegt dan het percentage, is de architectuur. Twintig procent herbruikbare code op een gezonde fundering is vaak meer waard dan zestig procent op een verrotte. Een verkeerd gekozen fundament laat zich niet wegpoetsen met goede modules erbovenop.
Dan is er de sunk-cost-val, de valkuil van de verzonken kosten. “We hebben er al zoveel ingestoken” is een gevoel, geen argument. Het geld dat al is uitgegeven, krijgt u nooit meer terug — of u nu doorgaat of stopt. De enige relevante vraag is wat het goedkoopste pad naar werkende software van hier af is.
En onderschat de verborgen kosten van opnieuw beginnen niet. Joel Spolsky waarschuwde in zijn bekende essay “Things You Should Never Do” dat u bij een herschrijving vanaf nul iets weggooit wat onzichtbaar is maar enorm waardevol: jaren aan ingebouwde bugfixes en domeinkennis. Elke rare “if” in oude code is vaak een stille oplossing voor een probleem dat u anders opnieuw gaat ontdekken — met schade en al.
Daartegenover staat de moderne, incrementele visie: niet alles bewaren, maar ook niet alles weggooien. Tussen “redden” en “opnieuw” ligt een derde weg, en die missen de meeste ondernemers.
De middenweg die de meeste ondernemers missen: stapsgewijs vervangen
Die derde weg heet het strangler-patroon, vernoemd en beschreven door Martin Fowler. De naam komt van de wurgvijg, een plant die langzaam om een boom heen groeit tot zij die uiteindelijk vervangt. In gewone ondernemerstaal: u laat de werkende delen gewoon draaien, herbouwt het slechtste onderdeel als eerste, en leidt het verkeer er stuk voor stuk overheen. Module voor module verdwijnt het oude systeem, zonder dat er ooit een groot “uit met de oude, aan met de nieuwe”-moment is.
Het grote voordeel: waarde landt continu in plaats van na een stilte van twaalf maanden. U ziet elke paar weken een echt verbeterd onderdeel live gaan, en u kunt bijsturen op basis van wat werkt in plaats van op basis van een plan dat al maanden oud is.
Deze aanpak verslaat zowel een volledige redding als een volledige herbouw wanneer de fundering grotendeels deugt maar specifieke modules verrot zijn, én wanneer u de bedrijfsvoering niet kunt stilleggen — wat voor het MKB bijna altijd geldt. U kunt nu eenmaal niet maanden zonder uw systemen. Door in kleine stukken te vervangen, blijven risico en budget beheersbaar: gaat er iets mis, dan is het mis in één module, niet in het hele bedrijf.
Niet alleen de code resetten, maar ook de mensen
Dit is het deel dat technische draaiboeken overslaan. Een vastgelopen project heeft niet alleen technische schuld — het heeft een vertrouwenstekort dat net zo echt is. De ondernemer is teleurgesteld, het team voelt zich aangevallen, en iedereen is voorzichtig geworden in wat hij nog durft te beloven. Zonder dat te herstellen, lost geen enkele technische ingreep iets duurzaam op.
De reset begint met een eerlijke erkenning zonder schuldigen. Niet “wie heeft dit gedaan”, maar “hier staan we, en dit is de weg vooruit”. Vervolgens reset u de verwachtingen tegen een realistische nieuwe nullijn — geen optimistische data meer die toch weer sneuvelen, maar een basislijn waar iedereen achter kan staan.
Er komt één aanspreekbare beslisser. Een vastgelopen project heeft vaak te veel stuurlui en te weinig kapitein; één persoon die knopen doorhakt, houdt de latentie laag. En u, de ondernemer, neemt weer actief plaats aan het roer. Niet als micromanager, maar als betrokken opdrachtgever die de richting bewaakt.
Vergeet ten slotte het signaal van vertrokken sleutelfiguren niet: leg de kennis vast voórdat er meer de deur uit loopt. Laat wat in hoofden zit op papier komen, in documentatie en in gedeelde afspraken, zodat het volgende vertrek geen nieuwe stilstand veroorzaakt.
Governance die terugval voorkomt
Een geredd project kan zo weer verzanden als u niets verandert aan hóé u stuurt. U heeft governance nodig — maar dan op maat van een MKB-bedrijf, niet de zware stuurgroepenstructuur van een multinational. Licht, ritmisch en praktisch.
Begin met een kort, vast stuurritme met u erbij. Een overleg van een halfuur per week of twee weken, waarin de voortgang aantoonbaar wordt gemaakt, is genoeg. Het gaat niet om de vergadering, het gaat om het ritme: regelmatig zicht houdt iedereen scherp.
Herdefinieer daarna de scope tot een minimale MVP die de scope-creep terugsnoeit naar de kernwaarde. Wat is het kleinste dat echt waarde levert? Bouw dat eerst, en bewaak het hard. Elke wens daarbuiten gaat op een lijst voor later, niet stilletjes de sprint in.
Houd de besluitvorming snel — lage latentie was het hele punt en blijft dat. Bouw QA-poorten in zodat bugs worden opgelost en niet weggemoffeld; een gelapte fout komt altijd terug. En leg afspraken over scope-wijzigingen schriftelijk vast, zodat niemand zich later iets anders herinnert.
Definieer ten slotte expliciet wat “hersteld” betekent, zodat u het kunt herkennen: ongeveer vier weken of meer aaneengesloten consistente levering van wat is afgesproken, elke cyclus aantoonbaar werkende software, en herstelde voorspelbaarheid en vertrouwen. Geen optimistisch statusrapport, maar zichtbare, klikbare voortgang. Pas dan is een project echt terug op de rails.
Een uitgewerkt voorbeeld, op hoofdlijnen
Hoe ziet dit er in de praktijk uit? Neem onze redding bij Imani Security Services — op hoofdlijnen, want de details horen bij de klant. Het project vertoonde de bekende signalen: een traject dat maar “bijna klaar” bleef, terwijl er weinig aantoonbaar werkends op tafel kwam.
We begonnen met een snelle, eerlijke diagnose: wat werkt, wat deugt niet, en hoeveel van het bestaande is werkelijk bruikbaar? Op basis daarvan maakten we een heldere keuze tussen redden en opnieuw bouwen — een beslissing op grond van de fundering en het herbruikbare deel, niet op grond van wat er al was uitgegeven.
Vervolgens brachten we het project stap voor stap terug naar de oorspronkelijke doelen, met de juiste werkafspraken eronder: één aanspreekbare lijn, een realistische nullijn en een ritme dat de ondernemer weer grip gaf. De volgorde — signaleren, diagnosticeren, beslissen, resetten, bestendigen — was geen theorie maar de feitelijke route terug. Geen wonderverhaal, wel een project dat weer leverde.
Conclusie: wanneer u hulp moet inschakelen
De beslisvolgorde is eenvoudig te onthouden: signaleer vroeg, diagnosticeer snel, beslis eerlijk, reset mensen én techniek, en bestendig met lichte governance. De vraag die u uzelf voortdurend moet stellen is nooit “is dit perfect?” — maar “liggen we nog op koers naar het oorspronkelijke doel, en zo niet, wanneer grijpen we in?”
Het eerlijke antwoord op dat “wanneer” is bijna altijd: eerder dan u nu denkt. Vroeg ingrijpen is goedkoper dan later gelijk krijgen.
Knipperen er bij u twee of meer signalen tegelijk, langer dan twee sprints? Dan is een korte, eerlijke diagnose veruit de goedkoopste volgende stap. Daarna weet u waar u staat — en kunt u beslissen met cijfers in plaats van met onderbuikgevoel.