Door Arne Van Raepenbusch

Tijdens de eerste gesprekken tussen een klant en een softwareleverancier wordt vaak de focus gelegd op het aanleveren van de requirements voor een bepaalde oplossing. De klant heeft dan zelf een lijst van functionaliteiten opgesteld die zeker in de oplossing moeten aanwezig zijn, en die lijst van wensen wordt vaak ook bevestigd na analyse van de leverancier. Dat zou moeten betekenen dat de opgestelde requirements duidelijk en compleet zijn. Of niet? 

Meer dan de helft van digitalisatieprojecten levert niet de verwachte businesswaarde

Helaas blijkt dat niet altijd het geval te zijn. Volgens dit artikel faalt maar liefst 70% van de softwareprojecten. Volgens deze McKinsey-analyse kunnen er vier redenen benoemd worden waarom softwareprojecten falen:

• Focus: de doelstellingen zijn niet duidelijk, het lukt business niet om een duidelijke visie over te brengen naar de ontwikkelaars.
• Scope: er is geen eenduidige richting, waardoor de requirements van het softwareproject veranderen tijdens de uitvoering. 
• Skills: het team is niet gebalanceerd en er is een tekort aan technische expertise.
• Uitvoering: de deadline die vooropgesteld wordt is onrealistisch.

Het document focust vooral op grote projecten, maar dezelfde redenen zijn ook van toepassing op kleinschalige projecten.

Bij het evalueren van het succes van een softwareproject komt de scope het vaakst naar boven als de grootste storende factor. Waarom? De scope kan te groot zijn voor de ingerekende tijd, kan veranderen door de business, of kan onduidelijk zijn door gebrek aan analyse. Maar het artikel beschrijft een nog groter probleem: maar liefst 56% van de projecten haalt de toegevoegde waarde die het zou moeten opleveren niet. Dat betekent dat naast de kans dat het project over budget gaat of te laat wordt opgeleverd, er ook nog eens de helft kans bestaat dat het project minder businesswaarde oplevert dan verwacht.

De oorzaak? Te sterk oplossingsgericht denken

Veel softwareleveranciers hebben nog voor de klant volledig uitgesproken is al een oplossing klaar. Dat is vrij logisch, want ze willen de klant overtuigen dat ze hun problemen op een elegante manier kunnen oplossen. Vaak tonen ze dan ook cases van gelijkaardige problemen bij andere klanten waar er al een gepaste oplossing in plaats werd gesteld. Hierbij verliezen ze vaak het probleem uit het oog.

Wanneer de scope van een softwareproject gewijzigd wordt, dan houdt dat vaak in dat het probleem duidelijker is geworden waardoor de requirements van de oplossing moeten worden aangepast. Een vaak voorkomende situatie is dat een bepaalde evidentie voor business over het hoofd werd gezien door de softwareleverancier, waardoor die niet in de scope werd opgenomen. Hoewel je die situatie nooit volledig kan elimineren – we zijn ook maar mensen – kunnen we wel stappen ondernemen om ervoor te zorgen dat dat zo weinig mogelijk gebeurt.

Je kan geen oplossing bouwen als het probleem niet duidelijk is

De grootste uitdaging bij het bouwen van software-oplossingen is dat de leverancier en de business niet altijd dezelfde taal spreken. De jarenlange ervaring die de organisatie heeft opgebouwd binnen hun industrie is niet overdraagbaar in een gesprek van enkele uren. Organisaties blijven ook graag vaag als het neerkomt over hun ambities, doelstellingen en strategische plannen om ervoor te zorgen dat die plannen niet zomaar bij de concurrentie terechtkomen. Dat kan een probleem vormen voor de softwareleverancier: die gaat aan de slag met incorrecte of onvolledige informatie, waardoor de kwaliteit van de oplossing dan helaas te wensen overlaat.

Het is voor een softwareleverancier van belang om zo veel mogelijk context te verzamelen over het probleem zodat er een geschikte oplossing ontwikkeld kan worden. Maar dat kost tijd en geld, waardoor veel softwareleveranciers zo snel mogelijk proberen over te schakelen naar de fase van oplevering. Hierdoor verliezen ze de eigenlijke doelstellingen van de organisatie en hun probleem uit het oog.

Elke digitalisatie begint bij een return-on-investment

Het is een evidentie dat een project een return-on-investment moet hebben, maar toch is dat iets dat tijdens de eerste gesprekken met een softwareleverancier zelden aan bod komt. Softwareleveranciers verwachten vaak dat de klant de relevantie van hun oplossing voor hun business zélf evalueert, maar het is voor de organisatie in kwestie heel moeilijk om in te schatten welke impact de oplossing op hun organisatie zal hebben. 

Bij jstack vinden we dat het bepalen van de return-on-investment een oefening is die samen moet worden gemaakt. Als softwareleverancier moeten we niet alleen de verantwoordelijkheid nemen over de oplevering van de oplossing, maar ook over hoe de oplossing er moet uitzien in het kader van de gestelde problematiek. 

Dat betekent dat we op twee manieren naar een bepaald topic kunnen kijken:

• Problem-space: wat is het probleem? Waarom is het een probleem? Hoe ziet de organisatie eruit als het probleem er niet zou zijn? Deze denkwijze gaat vooral in op de strategie van een organisatie. Het gaat in op de reden waarom een probleem opgelost moet worden. In deze space praten we vooral over benefits.
• Solution-space: hier leggen we de focus op hoe het probleem zal worden opgelost. Hoe ziet de applicatie er uit? Wie gaat ermee werken? Wanneer wordt de applicatie gebruikt? Hoe maken we de interface intuïtief? In deze space praten we vooral over requirements.

Ga op zoek naar voordelen in plaats van features

Het is soms heel moeilijk om een return-on-investment te berekenen omdat er menselijke voordelen zijn die niet gekwantificeerd kunnen worden. Hoeveel is de retentie van een werknemer bijvoorbeeld waard? Daarom is het belangrijk om de return-on-investment wat te nuanceren en vooral op zoek gaan naar het voordeel dat de organisatie uit de oplossing zou moeten halen. In deze fase is het nog onbelangrijk hoe je dit voordeel precies gaat aanleveren. In deze fase wordt enkel de problematiek onderzocht, en gaan we nog niet op zoek naar een oplossing. 

Door op zoek te gaan naar voordelen krijgen we meer inzicht in het probleem op twee verschillende manieren:

• Haalbaarheid: hoe groot is het probleem en hoe diep reikt het?
• Prioriteit: hoe belangrijk is het om dit probleem op te lossen?

Enkel wanneer er een goede balans is tussen prioriteit en haalbaarheid is het een goed idee om op zoek te gaan naar een oplossing voor het gestelde probleem.

De oplossing? Het probleem niet uit het oog verliezen

Om ervoor te zorgen dat digitalisatieprojecten wel de verwachte businesswaarde opleveren, mogen softwareleveranciers het probleem niet uit het oog verliezen. Bij jstack houden we steeds de focus op het probleem door de volgende zaken toe te passen:

• We gaan actief oplossingen uit de weg in de eerste fases van een project. Mensen tonen graag dat ze in staat zijn om problemen op te lossen, dus tijdens de eerste gesprekken duurt het vaak niet lang vooraleer iemand zegt “dat kunnen we zo oplossen” of “dat zullen we zo doen”. Daarmee verlies je de focus op het probleem.
• We faciliteren discussies. We proberen tijdens het brainstormen naar oplossingen regelmatig te checken of iedereen in de ruimte nog weet welk probleem er opgelost moet worden. Als we merken dat er geen constructieve discussies ontstaan, of mensen naast elkaar beginnen te praten, vestigen we de aandacht opnieuw op het probleem.
• We communiceren vanuit het perspectief van het probleem. We praten over de voordelen van de applicatie in plaats van de features en gaan op zoek naar de meerwaarde in plaats van mogelijkheden.

Hoe we probleemgericht werken aanpakken bij jstack

Bij jstack hebben we de afgelopen jaren een shift gemaakt waarbij we meer met de klant willen meedenken bij het ontwerpen van een geschikte oplossing. Dat kan enkel als we probleemgericht werken. Daarom leggen we tijdens de eerste fases van een project de focus op het begrijpen van de klant in de problem-space. Daarbij nemen we de Double Diamond van Service Design mee in onze 4xO Methode. Meer weten over onze digitalisatietrajecten volgens de 4xO-methode? Lees hier meer over onze aanpak.