Blijf niet ploeteren bij uitdagende softwareprojecten!

Om zich te onderscheiden van de concurrentie, of omdat er geen standaardoplossing beschikbaar is, ontwikkelen veel organisaties maatwerksoftware. Of dit nu een fancy website, een hippe mobile-app of een andere manier betreft om hun klanten centraal te zetten: deze softwareoplossingen vertegenwoordigen veel waarde. Helaas verlopen softwareprojecten vaak niet conform plan en/of verwachtingen. Onze oproep is om niet te blijven ploeteren maar om hulp in te schakelen, zodat zo snel mogelijk de ‘vruchten’ van de softwareoplossing kunnen worden geplukt.

Helaas verlopen softwareontwikkelprojecten vaak niet zoals vooraf gepland. Volgens het gezaghebbende CHAOS report van de Standish Group kwam in 2020 circa 65% van de onderzochte projecten in de problemen. Oorzaken zijn er vele. Bijvoorbeeld omdat de ontwikkeling (veel) langer duurt, er onvoorziene defecten worden gevonden in de testfase of de performance tegenvalt. Dit leidt uiteraard tot teleurstellingen maar ook tot kostenoverschrijdingen en een latere inzet van het gewenste nieuwe systeem. De oorzaken hiervoor zijn talrijk, waaronder slechte softwarekwaliteit, een architectuur die niet is toegesneden op de specifieke oplossing, gebrekkige definitie van de gewenste functionaliteit en systeemvereisten, een softwarefabriek (of ontwikkelomgeving) waarin belangrijke hulpmiddelen ontbreken, een ontwikkelteam dat belangrijke competenties ontbeert en irreële verwachtingen. Maar ook een te groot optimisme van het ontwikkelteam bij de start: we fixen dit wel even.

Wat de oorzaak ook mag zijn, de uitkomst brengt natuurlijk teleurstelling. In onze praktijk blijkt dat de reactie hierop varieert veelal van apathie, ruziemaken, tot het stoppen van het project. Ook worden medewerkers bedankt voor bewezen dienst of worden leveranciers met schadevergoedingen bedreigd. Dit is vaak een langdurig proces waarbij vooral de teleurstelling blijft hangen. Vervolgens wordt doorgaans (regelmatig met onze ondersteuning) in detail uitgezocht hoe het zo gekomen is. En uiteindelijk blijkt in veel gevallen het antwoord op de schuldvraag een beetje in het midden te liggen.

Vandaar onze oproep om niet in de put te blijven zitten, maar te gaan werken vanuit de waarde die initieel aan de softwareoplossing werd toegekend. Wat gebeurd is, is gebeurd; daar verandert toch niks meer aan. Het blijft zaak om de softwareoplossing alsnog zo snel en goed mogelijk te realiseren en de beoogde resultaten te oogsten. Het genoemde CHAOS report ondersteunt deze oproep: ruim twee derde van de projecten die in de problemen kwamen leidden (uiteindelijk) tot een bruikbaar product.

Er zijn meerdere manieren om een softwareproject bij te sturen. In alle gevallen is daarbij verdieping in de details van de software en de softwareontwikkelaanpak noodzakelijk. Wij hebben in verschillende vormen in onze praktijk gezien dat een beperkte en vaak succesvolle ingreep is als een ervaren onbevooroordeelde softwarearchitect / meewerkend voorman het softwareontwikkelteam bijstaat. Geef deze specialist toegang tot de software en tot het team en vraag hem of haar de problemen te onderzoeken. Niet met het doel een uitgebreid rapport op te leveren over wat het probleem is en hoe het zo gekomen is, maar om al doende inzichten krijgen hoe de problemen opgelost kunnen worden. En met ‘al doende’ bedoelen we ook gelijk verbeteringen introduceren. Dat kan gaan om het, binnen de softwarefabriek, installeren van ondersteunende tools om de broncode geautomatiseerd te analyseren op kwaliteit, kwetsbaarheden en complexiteit, om het introduceren van applicatieframeworks, een unittestraamwerk of bewezen opensource-componenten, maar ook om daadwerkelijk specifieke routines in de broncode te vereenvoudigen of architecturele knooppunten te ontrafelen.

Essentieel in deze aanpak is dat deze softwarespecialist samenwerkt als onderdeel van het team. En deelneemt aan stand-ups en overleggen en ook zo begrip krijgt van de wijze waarop de functionaliteit en systeemvereisten zijn gespecificeerd en hoe de softwarefabriek, waarin de broncode wordt gebouwd, functioneert. Zo ontstaat een breed beeld over waar de problemen kunnen zitten.

Veelal na twee weken meedraaien met het ontwikkelteam, kan een goede softwarearchitect samen met het ontwikkelteam aan de andere stakeholders kort de bevindingen presenteren. Het is niet teveel gevraagd om in deze presentatie ook een voorstel voor vervolgstappen richting het succesvol realiseren van de gewenste softwareoplossing, inclusief nog bestaande onduidelijkheden en risico’s, op te nemen.

Bij de voorgestelde vervolgstappen hoort een tijdspad om uit de problemen te komen. Veelal blijft de softwarearchitect / meewerkend voorman daarbij betrokken, soms zijn zelfs aanvullende softwarespecialisten/competenties noodzakelijk om hiermee specifieke diepgaande kennis in te brengen of een versnelling te realiseren. Op deze manier staan de softwarearchitect als meewerkend voorman zelf met de voeten in de klei op weg naar een succesvolle afronding van het project, waarbij actief de ervaring, kennis en procesaanpak wordt overgedragen aan het al bestaande ontwikkelteam.

Vaak moet op het gebied van systeemeisen wel wat water bij de wijn. Meestal wordt er een grote verzameling systeemeisen aangetroffen waarin gesneden kan worden om toch tenminste het grootste deel van de waarde van het systeem te realiseren. Het ideale pad leidt veelal naar een Minimal Viable Product (MVP) waarmee het systeem in gebruik kan worden genomen. Bij bewezen succes kunnen na ingebruikname dan altijd nog meer functionele systeemeisen gerealiseerd worden.

Eerlijkheid is vereist: niet elk softwaresysteem in ontwikkeling is te redden. Door daar zo snel mogelijk helderheid over te geven, wordt dit probleem (en de daarmee samenhangende kostenpost) niet groter dan nodig. Ook bij de daarop volgende keuze, tussen 1) opnieuw beginnen, of 2) op een andere manier de gewenste waarde die met het systeem werd beoogd realiseren, kunnen de opgedane ervaringen van de softwarearchitect ondersteunen.

Weet je van een systeemontwikkelproject waarvan de succesvolle realisatie wordt bedreigd? Of ken je een softwareontwikkelteam dat wel wat hulp kan gebruiken? Wacht dan niet langer en neem (bijvoorbeeld) contact op met Thomas Beekman (beekman.thomas@kpmg.nl), senior manager bij KPMG. Hij en zijn team gaan graag in gesprek over hoe zij het beste kunnen helpen het softwareontwikkelproject tot een succes te maken.

Hoe sneller het softwareontwikkelproject weer op koers is, hoe eerder de waarde van het te realiseren systeem ter beschikking komt van je organisatie!