Aanpak

Waarom softwareprojecten ontsporen, en hoe u de omschakeling ontmijnt

Grote softwarevervangingen lopen zelden op één dag vast. Ze schuiven, kwartaal na kwartaal. De uitweg is geen beter plan maar een andere opzet: golven, met een go/no-go op elke stap.

4 min lezenDirectie en IT

In het kort

  • Gemiddeld lopen grote IT-projecten 45% over budget en leveren ze 56% minder waarde dan beloofd. Bij 17% loopt het zo slecht af dat het het voortbestaan bedreigt (McKinsey/Oxford, 2012).
  • Het geld verdwijnt niet in de techniek maar in de opzet: één groot blok, één einddatum, en een cutover waarop alles tegelijk moet werken.
  • Golven draaien dat om. Elke golf zet een werkend stuk in productie, met een go/no-go erna, en de legacy blijft draaien tot de nieuwe module zich bewijst.
  • De eerste golf staat binnen 90 dagen live. Valt een go/no-go op no-go uit, dan stopt de base fee en houdt u de code, want die staat vanaf dag één in uw repository.

Een groot softwareproject valt zelden om op de dag dat u het verwacht. Het zakt weg. Een release schuift een kwartaal op, een module gaat naar de volgende fase, de oude en de nieuwe omgeving draaien maanden naast elkaar. Tegen de tijd dat de grote omschakeling er is, blijkt de helft van wat beloofd was er niet te zijn. De rekening is dan al betaald.

Het patroon is gemeten

McKinsey onderzocht samen met de University of Oxford (2012) meer dan 5.400 grote IT-projecten, elk met een initiële prijs boven 15 miljoen dollar. Gemiddeld liepen ze 45% over budget en 7% uit in tijd, en leverden ze 56% minder waarde dan vooraf voorspeld. De helft overschrijdt het budget fors. Een groter budget beschermt niet, het vergroot alleen de inzet.

17% van de grote IT-projecten loopt zo slecht af dat het het voortbestaan van de onderneming bedreigt. McKinsey & University of Oxford, 2012.

Waarom het misgaat

De oorzaak is zelden één verkeerde technische keuze. Het is de opzet. Een vervanging wordt aanbesteed als één groot blok, met één einddatum waarop alles tegelijk live moet. De scope wordt vooraf dichtgetimmerd, terwijl het bedrijf ondertussen doorverandert. Hoe verder het project vordert, hoe meer geld erin zit, en hoe zwaarder het weegt om te stoppen of bij te sturen. Slecht nieuws reist traag naar boven, want niemand wil de brenger ervan zijn.

Zo ontstaat een project dat te groot is om te falen en te log om te slagen. De beslissing om door te gaan is op elk moment al genomen, lang voordat iemand kan zien of het werkt.

Denk niet dat dit alleen over projecten van 15 miljoen dollar gaat. De mechaniek schaalt naar beneden. Een ERP-migratie, een nieuw kassasysteem, een CRM dat eindelijk aan de boekhouding hangt: het is dezelfde opzet van één grote knal op één datum. Voor een bedrijf van tweehonderd mensen is een mislukte omschakeling even bedreigend als een afschrijving van tientallen miljoenen voor een concern. De verhouding tot de omzet telt, niet het absolute bedrag.

De omschakeling is het echte risico

Vraag een directie waar de pijn zit, en het antwoord is bijna altijd hetzelfde: de cutover. De dag waarop de oude tool uitgaat en de nieuwe aanstaat. Alles wat maanden op papier klopte, moet dan in één keer werken, met echte data, echte klanten en een balie die niet kan wachten. Faalt die dag, dan valt het bedrijf terug op het systeem dat het net wilde loslaten.

Daar laat een big bang zijn prijs zien. Al het risico wordt opgespaard tot één moment. Wie dat risico wil verkleinen, moet dat moment opknippen.

Een project dat te groot is om te falen, is ook te groot om te sturen. De enige echte controle is de vrijheid om na elke stap te stoppen.

Golven in plaats van een big bang

Wij bouwen in golven. Elke golf levert één werkend stuk van het platform op, in productie, met echte gebruikers, voordat de volgende begint. Aan het eind van elke golf staat een go/no-go. Geen stuurgroep die een statusrapport doorbladert, maar een besluit op basis van iets dat draait.

Een gate wordt pas groen als dat werkende stuk aan een paar harde voorwaarden voldoet:

  • de gebruikers doen hun echte werk in de nieuwe module, niet in een testomgeving
  • de data is gemigreerd en nagekeken door de mensen die er dagelijks mee werken
  • de meetbare doelen van die golf zijn gehaald, in cijfers, niet in indruk
  • finance heeft de kosten van de stap gezien en medeondertekend

Tot een golf die drempel haalt, blijft de legacy gewoon draaien. U schakelt nooit een werkend systeem uit voor iets dat zich nog moet bewijzen. De oude en de nieuwe module lopen naast elkaar tot de nieuwe stabiel is, en pas dan gaat de oude eruit. Er is geen dag meer waarop alles tegelijk moet lukken, omdat er nooit meer dan één golf tegelijk op het spel staat.

Snel iets in handen, en de vrijheid om te stoppen

De eerste golf levert binnen 90 dagen een werkend resultaat op, iets dat in productie staat en dat uw mensen echt gebruiken. Geen demo, geen rapport dat om vertrouwen op krediet vraagt. Vanaf dat punt neemt u elke volgende golf apart. Valt een go/no-go op no-go uit, dan stopt de base fee. U betaalt niet door voor een richting die zich niet bewijst, en u zit nergens aan vast, want de code staat vanaf dag één in uw eigen repository.

Dat draait de logica van het grote project om. Het momentum ligt niet langer bij doorgaan omdat er al zoveel in zit. Het ligt bij bewijzen. Elke stap moet zichzelf verdienen voordat de volgende begint. En omdat de legacy blijft draaien tot dat bewijs er is, kost een no-go u tijd en wat leergeld, geen bedrijf.

Een softwarevervanging hoeft geen weddenschap op één datum te zijn. Wie in golven bouwt, weet na de eerste 90 dagen of de aanpak klopt, en houdt bij elke stap de keuze om te stoppen, bij te sturen of door te zetten. De volgende golf begint pas als de vorige in productie draait en de cijfers gehaald zijn. Dat is niet trager. Het is het verschil tussen een project dat blijft schuiven en een dat elke maand iets oplevert dat u kunt gebruiken.

Wilt u dit toepassen op uw eigen situatie?

Belgisch, founder-led en gebouwd om over te dragen. Eén e-mail volstaat.