Wanneer begint een project te zinken?
Elk IT-project begint op een vergelijkbare manier. Er zijn ambitieuze plannen, een planning, presentatie van de eerste mockups en het vertrouwen dat het bedrijf over enkele maanden van een modern systeem zal profiteren. In het begin ziet alles veelbelovend uit, maar na verloop van tijd duiken de eerste vertragingen op. De deadline schuift een week op, later een maand. Het aantal fouten groeit, de communicatie met de leverancier wordt steeds lastiger, en de antwoorden klinken steeds vaker: "Nog even", "Het is maar een kleine correctie" of "We zitten al op de eindstreep."
Op een gegeven moment blijkt dat het bedrijf in plaats van een kant-en-klaar product een onaf project heeft dat niemand wil overnemen.
Dat scenario komt veel vaker voor dan je zou denken.
Het grootste probleem is niet de code
De meeste ondernemers gaan ervan uit dat als een project niet werkt, de slecht geschreven code de schuldige is. Soms is dat inderdaad zo. In de praktijk ligt het probleem echter vaak dieper.
Er ontbreekt documentatie. De architectuur is “on the fly” opgezet. Er zijn geen geautomatiseerde tests. Integraties zijn provisorisch uitgevoerd. Functies werden toegevoegd zonder analyse van hun impact op het gehele systeem. Daardoor veroorzaakt zelfs een kleine wijziging nieuwe fouten.
Het is een beetje alsof je een huis renoveert zonder plan. Je kunt elke kamer afwerken, maar na verloop van tijd blijkt dat muren niet op de juiste plek staan, leidingen lukraak lopen en de verbouwing steeds duurder wordt.
Wanneer is het tijd om "stop" te zeggen?
Een van de moeilijkste momenten voor een ondernemer is het besluit om de samenwerking met de huidige leverancier te beëindigen. Veel ondernemers stellen dat besluit te lang uit.
Waarom?
Omdat het project al veel geld heeft opgeslokt.
Omdat het zonde van de tijd is.
Omdat het misschien "toch nog lukt".
De psychologie noemt dat het sunk cost–effect. Hoe meer we al geïnvesteerd hebben, hoe moeilijker het is toe te geven dat de huidige koers nergens naartoe leidt.
Soms is de beste beslissing dan ook niet om meer budget in hetzelfde probleem te blijven pompen, maar het project stil te leggen en de situatie rustig te analyseren.
Kan elk project gered worden?
Nee. - En dat moet eerlijk gezegd worden.
Er zijn projecten waarvan het herstel meer zou kosten dan het opnieuw opbouwen. Soms is de gebruikte technologie al verouderd of is de architectuur zo ontworpen dat verdere ontwikkeling onmogelijk is.
Daarom zou de eerste stap nooit het doen van beloften moeten zijn.
De eerste stap moet een audit zijn.
Pas na een grondige analyse van de code, documentatie, infrastructuur en processen kan worden bepaald of het rendabeler is het bestaande systeem te repareren of een nieuw project te starten.
Een goede technologische partner zegt niet wat de klant wil horen.
Die zegt wat zakelijk gezien het beste is.
Hoe ziet het redden van een project er in de praktijk uit?
Tegen de verwachting in begint het niet met programmeren.
Eerst moet je begrijpen waar je mee te maken hebt.
We analyseren de systeemarchitectuur, de kwaliteit van de code, de communicatie tussen modules, gegevensbeveiliging, prestaties en de mogelijkheden voor verdere ontwikkeling. We controleren documentatie, wijzigingsgeschiedenis en gebruikte technologieën. Vaak is al na een paar dagen duidelijk waar het echte probleem zit.
Pas dan wordt een actieplan opgesteld.
Soms volstaat het de code op te ruimen en een paar cruciale onderdelen te verbeteren. Soms is het nodig bepaalde modules te herbouwen. Het komt ook voor dat de meest redelijke oplossing is om een nieuw systeem te bouwen waarbij gebruik wordt gemaakt van wat al is bereikt.
Er zijn geen twee identieke projecten.
Net zo is er geen universeel recept om ze te redden.
Waarom is het overnemen van een project moeilijker dan het vanaf nul opbouwen?
Die vraag horen we vaak van klanten.
Het antwoord is eenvoudig.
Als we een systeem vanaf het begin bouwen, kennen we elke ontwerpbeslissing. We weten waarom een specifieke oplossing is gekozen en wat de uitgangspunten waren.
Bij het overnemen van een buitenlands project moeten we die kennis eerst reconstrueren.
Het is een beetje alsof je de bouw van een huis overneemt van een ploeg die de bouwplaats zonder plannen, zonder documentatie en zonder informatie over wat al gedaan is heeft achtergelaten.
Daarom vereist het redden van projecten niet alleen programmeervaardigheden, maar ook architectonische, analytische en ontwerpervaring.
Een technologische partner moet ook bij je blijven als er problemen ontstaan
Een goed softwarehuis herken je niet aan hoe het een project start.
Je herkent het aan hoe het reageert wanneer er moeilijkheden optreden.
Niet alles is voorspelbaar. Businessbehoeften, technologieën en gebruikerswensen veranderen. Cruciaal is of het team oplossingen kan vinden, risico’s helder kan communiceren en samen met de klant de beste beslissingen kan nemen.
Juist daardoor wordt vertrouwen opgebouwd.
Hoe werken we bij Web24?
Bij projecten die overgenomen moeten worden gaan we met veel voorzichtigheid te werk.
We doen geen beloften na het eerste gesprek.
Eerst analyseren we de situatie. We kijken wat er is gedaan, wat herbruikbaar is en wat herbouw vereist. Pas daarna stellen we een aanbeveling en een plan van aanpak op.
Ons doel is niet om nog eens duizenden regels code te schrijven.
Ons doel is het project naar een punt te brengen waarop het daadwerkelijk de groei van het bedrijf ondersteunt.
Samenvatting
Als jouw project vastloopt, de leverancier stopt met reageren, de planning alleen nog op papier bestaat en elke correctie nieuwe fouten veroorzaakt, betekent dat nog niet dat alles verloren is.
In veel gevallen is het probleem oplosbaar.
Maar je moet wel met één stap beginnen - een grondige analyse van de situatie.
Want voordat je een project gaat redden, is het goed eerst te achterhalen waarom het begon te zinken.
