Elk softwareproject begint vol optimisme. Een duidelijke opdrachtomschrijving, een enthousiast team, een stappenplan dat er op papier redelijk uitziet. Zes maanden later sta je voor een half afgebouwd platform, een budget dat stilletjes is verdubbeld en een ontwikkelingspartner die blijft beloven dat alles in de „volgende sprint“ zal worden opgelost.
Als dat je bekend in de oren klinkt, ben je niet de enige. Uit onderzoek in de sector blijkt keer op keer dat het merendeel van de maatwerksoftwareprojecten het budget overschrijdt, deadlines niet haalt of niet levert wat oorspronkelijk was beloofd. Het goede nieuws: de meeste projecten die in de problemen zitten, kunnen nog worden gered. Het slechte nieuws: dat kan alleen als je de waarschuwingssignalen vroeg genoeg herkent.
Bij Vulpo hebben we de afgelopen tien jaar tientallen vastgelopen projecten overgenomen, van interne platforms die niet meer werkten tot klantenportalen die nooit zijn afgerond. Hieronder volgen de zeven signalen die we het vaakst tegenkomen, en wat ze eigenlijk betekenen.
1. De deadlines verschuiven steeds — en niemand kan uitleggen waarom
Hier en daar een vertraging is normaal. Softwareontwikkeling is complex, en goede teams passen hun planning aan naarmate ze meer leren. Maar er is een verschil tussen een gerechtvaardigde vertraging en een vage vertraging.
Een gezonde vertraging: "We zijn tegen een probleem aangelopen bij de integratie met de API van de betalingsprovider. We hebben twee extra weken nodig om die module goed te herstructureren."
Ongewenste vertraging: "Het duurt iets langer dan verwacht. Volgende week weten we meer."
Als je geen concrete antwoorden meer krijgt, betekent dat meestal dat het team zelf het overzicht kwijt is over de stand van zaken bij het project. Dat is een alarmsignaal dat je serieus moet nemen.
2. De codebase is een black box geworden
In de beginfase van een project kunnen je ontwikkelaars vol vertrouwen zeggen: "Ja, dat kunnen we toevoegen" of "Nee, dat zou X kapotmaken." Wanneer dat vertrouwen verdwijnt, wanneer elke kleine wijziging dagenlang onderzoek vereist, wanneer bugs terugkomen nadat ze zijn verholpen, wanneer niemand bepaalde delen van de code nog durft aan te raken, dan is het project in de problemen.
Dit is meestal een teken van opgebouwde technische schuld: onder tijdsdruk genomen snelkoppelingen die nooit zijn opgeruimd. Elke nieuwe functie maakt de basis wankeler. Op een gegeven moment kost het toevoegen van iets nieuws meer dan het oplevert.
3. Je gebruikers vragen niet meer om nieuwe functies
Dit klinkt misschien tegenstrijdig, maar het is een van de duidelijkste signalen. Als de mensen die je software daadwerkelijk gebruiken geen verzoeken om nieuwe functies meer sturen, betekent dat zelden dat ze tevreden zijn. Meestal betekent het dat ze het hebben opgegeven.
Ze hebben tijdelijke oplossingen gevonden in Excel. Ze zijn stiekem een concurrerend programma gaan gebruiken. Ze zijn tot de conclusie gekomen dat het geen zin heeft om om verbeteringen te vragen. Tegen de tijd dat de stilte intreedt, is je software in feite irrelevant geworden voor de eigen gebruikers, ook al werkt het technisch gezien nog wel.
4. De oorspronkelijke ontwikkelingspartner heeft zich in de verdediging geschoven
In een gezonde samenwerking brengt je softwarepartner problemen proactief onder je aandacht. Hij wijst je op risico’s, stelt alternatieven voor en spreekt zich uit als je verzoeken op termijn tot problemen zouden leiden.
Wanneer die dynamiek verandert, wanneer op elke vraag met smoesjes wordt gereageerd, wanneer feedback persoonlijk wordt opgevat, wanneer vergaderingen veranderen in pogingen om de schade te beperken, is de werkrelatie verbroken. En uit verbroken relaties komt zelden goede software voort.
5. Niemand kan meer uitleggen wat de software eigenlijk doet
Dit klinkt absurd, maar het komt vaker voor dan je zou denken. Naarmate projecten zich voortslepen, de projectomvang steeds verder uitbreidt, de eisen veranderen en teamleden komen en gaan, raakt de oorspronkelijke visie verwaterd. Uiteindelijk krijg je een systeem waarin:
De producteigenaar kan niet alle functies opsommen
De ontwikkelaars begrijpen de bedrijfslogica niet volledig
De documentatie (voor zover die er is) is verouderd
Nieuwe teamleden hebben maanden nodig om productief te worden
Als de institutionele kennis verdwenen is, wordt elke kleine verandering een risico en is elke schatting niet meer dan een gok.
6. De kosten stijgen langzaam, zonder dat daar evenredige vooruitgang tegenover staat
Budgetoverschrijdingen komen voor. Maar er is een cruciaal verschil tussen meer uitgeven om meer te krijgen en meer uitgeven om op dezelfde plek te blijven.
Houd de verhouding in de gaten. Als je maandelijkse factuur steeds hoger wordt terwijl de changelog mager blijft, klopt er iets niet. Ofwel is het team bezig met het blussen van oude brandhaarden in plaats van nieuwe waarde te creëren, ofwel is de architectuur zo complex geworden dat eenvoudige wijzigingen nu onevenredig veel inspanning vergen. Beide zijn tekenen dat het project structurele ingrepen nodig heeft, en niet alleen maar meer uren.
7. Je ziet op tegen de wekelijkse statusvergadering
We hebben het zwakste signaal voor het laatst bewaard, omdat dat vaak het meest veelzeggend is. Je intuïtie klopt meestal wel.
Als je merkt dat je projectvergaderingen uitstelt, de map in je inbox met statusupdates links laat liggen of een vaag gevoel van onrust krijgt zodra het project ter sprake komt, let dan goed op. Ervaren leidinggevenden ontwikkelen een zesde zintuig voor projecten die uit de hand zijn gelopen. Dat gevoel is een signaal.
Hoe zo'n Project Rescue er in de praktijk uitziet
De signalen herkennen is één ding. Weten wat je eraan moet doen, is iets heel anders. Een goede rescue houdt niet in dat je er nog meer ontwikkelaars op zet of alles helemaal opnieuw schrijft. Beide benaderingen maken de situatie meestal alleen maar erger.
Een gestructureerde reddingsoperatie verloopt doorgaans in vier stappen:
1. Audit. Een extern team beoordeelt de code, de architectuur, de documentatie en de teamdynamiek. Het doel is een eerlijke diagnose, niet het toewijzen van schuld.
2. Stabiliseren. Voordat er iets nieuws wordt toegevoegd, moet het bestaande systeem betrouwbaar worden gemaakt. Dat houdt vaak in dat kritieke bugs worden verholpen, de testdekking wordt verbeterd en wordt gedocumenteerd hoe alles precies werkt.
3. De focus opnieuw bepalen. Met een stabiele basis kan het team de oorspronkelijke doelstellingen opnieuw bekijken. Wat is nog steeds belangrijk? Wat kan worden geschrapt? Wat moet opnieuw worden bekeken?
4. Het momentum weer opbouwen. Kleine, zichtbare successen herstellen het vertrouwen, zowel intern als bij de belanghebbenden. Van daaruit kan het project weer op een stevige basis verdergaan.
De belangrijkste les: het redden van een project draait zelden alleen om technologie. Het gaat om het herstellen van duidelijkheid, vertrouwen en een goed werkritme. De code is meestal wel te repareren. Het is veel moeilijker om de omstandigheden te herstellen waarin goede software kan worden gebouwd.
Wanneer moet je externe hulp inroepen?
Niet elk project dat in de problemen zit, heeft een extern team nodig. Soms volstaat een openhartig gesprek met je huidige partner, een herziening van de projectomvang of een wisseling in het projectmanagement. Maar als je drie of meer van de bovenstaande signalen herkent en de situatie al enkele maanden eerder verslechtert dan verbetert, is het waarschijnlijk tijd voor een frisse blik.
Vroegtijdig ingrijpen kost bijna altijd minder dan afwachten. Een vastgelopen project slokt niet alleen het budget op, maar houdt ook interne belanghebbenden bezig, ondermijnt het vertrouwen van de gebruikers en vertraagt de bedrijfswaarde die de software in de eerste plaats had moeten opleveren.
Hoe Vulpo Project Rescue's aanpakt
Sinds 2012 redden we vastgelopen softwareprojecten in uiteenlopende sectoren, van energie en onderwijs tot detailhandel en logistiek. Onze aanpak is pragmatisch: we gaan er niet vanuit dat het vorige team alles verkeerd heeft gedaan, en we staan er niet op om helemaal opnieuw te beginnen. We kijken naar wat er al is, wat werkt en wat er moet veranderen, en brengen het vervolgens weer op de rails.
Als u enkele van deze signalen in uw eigen project herkent, neem dan contact met ons op. Een kort gesprek maakt vaak al duidelijk of er hulp nodig is en wat daar precies bij komt kijken.
Lees meer over onze Project Rescue-service
