Door Arne Van Raepenbusch

In gesprekken tussen klant en softwareleverancier verschuift de focus al snel naar het aanleveren van requirements voor een gewenste oplossing. Klanten komen dan met een lijst van functionaliteiten die de software zeker moet bevatten. Leveranciers bevestigen die lijst vaak na een eerste analyse, wat de indruk wekt dat de requirements duidelijk en volledig zijn. Maar is dat wel zo?

Meer dan de helft van de digitalisatieprojecten faalt

In de praktijk blijkt dat tegen te vallen. Vaak is zo’n lijst van requirements eerder een opsomming van functies die de klant denkt nodig te hebben, dan een reflectie van de onderliggende noden. En dat zorgt voor problemen.

Onderzoek toont namelijk aan dat maar liefst 70% van de softwareprojecten faalt. Volgens een analyse van McKinsey zijn daar vier belangrijke oorzaken voor:

• Focus: doelstellingen zijn onduidelijk; de business slaagt er niet in om een heldere visie over te brengen naar ontwikkelaars.
• Scope: de scope is vaag of onstabiel, waardoor de requirements blijven veranderen tijdens de uitvoering.
• Skills: het team is niet goed uitgebalanceerd en mist technische expertise.
• Uitvoering: de vooropgestelde deadlines zijn onrealistisch.

Hoewel deze analyse gericht is op grote projecten, gelden deze risico’s evengoed voor kleinere softwareprojecten.

De scope is de factor die het vaakst voor problemen zorgt. Ze bepaalt immers wat er precies gebouwd moet worden. Wanneer de scope te breed is voor de beschikbare tijd, verandert tijdens de ontwikkeling, of onduidelijk blijft door gebrekkige analyse, leidt dat onvermijdelijk tot tijdsgebrek en budgetoverschrijding.

Maar McKinsey wijst op een nog fundamenteler probleem: 56% van de opgeleverde projecten levert de verwachte meerwaarde niet op. Met andere woorden: op tijd en binnen budget afgerond wordt, levert de helft van die projecten uiteindelijk minder businesswaarde op dan verwacht.

We denken te snel in oplossingen

Een belangrijke oorzaak? Veel softwareleveranciers denken al in oplossingen nog voor de klant het probleem volledig heeft uitgelegd. Dat is begrijpelijk: ze willen hen tonen dat ze hun probleem snel en elegant kunnen oplossen, vaak aan de hand van gelijkaardige cases. Maar net daardoor verliezen ze het echte probleem uit het oog.

Wanneer een scope tijdens het softwareproject wijzigt, is dat vaak omdat het probleem duidelijker is geworden. Zaken die voor de klant vanzelfsprekend zijn, worden niet altijd uitgesproken en soms over het hoofd gezien door de leverancier. Ze ontbreken in de analyse en komen pas tijdens de ontwikkeling aan het licht. Als je dan geen budget meer over hebt om die features alsnog te ontwikkelen, eindig je met een project dat de gewenste businesswaarde niet oplevert.

Hoewel je zulke situaties nooit volledig kan uitsluiten (we blijven tenslotte mensen), zijn er wel manieren om ze tot een minimum te beperken.

Geen oplossing zonder een helder probleem

De grootste uitdaging? Klanten en leveranciers spreken niet altijd dezelfde taal. De diepgaande kennis die een organisatie heeft opgebouwd, laat zich niet zomaar overbrengen in een paar gesprekken. Bovendien zijn klanten vaak bewust terughoudend over strategische ambities, uit schrik dat die bij de concurrentie terechtkomen. Het resultaat: de softwareleverancier werkt met onvolledige of foutieve informatie, wat de kwaliteit van de oplossing ondermijnt.

Daarom is het cruciaal dat leveranciers voldoende context verzamelen over het probleem voor ze naar de oplossing springen. Maar dat kost tijd en geld. Veel partijen houden die fase liever kort om snel te kunnen opleveren. Dat lijkt efficiënt, maar is het zelden. Zonder voldoende probleeminzicht bouw je op foutieve aannames. En die zorgen later voor dure herwerkingen of gemiste kansen.

Elk digitalisatietraject start met een ROI

Een softwareproject moet een duidelijke return-on-investment (ROI) opleveren. Dat is evident, maar toch komt dat onderwerp zelden aan bod in de eerste gesprekken. Vaak verwacht de leverancier dat de klant zelf inschat of de voorgestelde oplossing relevant is. Maar de klant heeft meestal onvoldoende zicht op de technologische mogelijkheden en hun potentiële impact op de organisatie.

Bij jstack geloven we dat het bepalen van de ROI een gezamenlijke oefening moet zijn. Als leverancier dragen we niet alleen verantwoordelijkheid voor de oplevering van software, maar ook voor het vormgeven van een oplossing die daadwerkelijk waarde oplevert. De keuzes die we maken hebben rechtstreeks invloed op de businessimpact. Goede keuzes kan je maken als je samen het probleem en de doelstelling scherp hebt.

Van probleemgericht denken naar oplossingsgericht denken

Om een oplossing met maximale ROI te bouwen, bekijken we elk project vanuit twee invalshoeken:

• Problem-space
  Waarom moet dit probleem worden opgelost? Wat is de impact op de organisatie als het verdwijnt? Hier draait alles om strategie en voordelen. 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 we het probleem oplossen. 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 spreken we vooral over functionaliteiten en requirements.

Denk in voordelen, niet in features

De ROI van een project is moeilijk te berekenen wanneer voordelen moeilijk te kwantificeren zijn. Denk bijvoorbeeld aan werknemerstevredenheid: hoeveel is het waard als een medewerker langer blijft? Daarom gaan we in de beginfase niet meteen op zoek naar oplossingen, maar naar de voordelen die de organisatie met het project wil realiseren.

Door die voordelen centraal te stellen, dwingen we onszelf en de klant om scherper te formuleren waarom het project nodig is. Wat moet er concreet verbeteren? Wat wil de organisatie vermijden? Zulke vragen brengen de echte pijnpunten naar boven, en dat levert waardevolle inzichten op in het onderliggende probleem.

Zo krijgen we een beter beeld van:

• Haalbaarheid: hoe groot en complex is het probleem?
• Prioriteit: hoe dringend is het om dit probleem op te lossen?

Pas wanneer een probleem belangrijk genoeg is om aan te pakken én realistisch genoeg is om op te lossen binnen de context van de organisatie, is het zinvol om een oplossing uit te werken.

De oplossing? Verlies het probleem niet uit het oog

Om de verwachte businesswaarde te realiseren, moet de focus op het probleem blijven liggen. Bij jstack doen we dat op drie manieren:

• We mijden oplossingen in de beginfase.
  Het is verleidelijk om meteen oplossingen aan te reiken, maar dat leidt vaak tot tunnelvisie. We nemen bewust afstand van oplossingen tot het probleem helder is.
• We faciliteren discussies.
  Tijdens brainstorms houden we continu de vinger aan de pols. Weten we nog welk probleem we proberen op te lossen? Als het gesprek afwijkt, brengen we de focus terug naar het probleem.
• We communiceren vanuit het probleem.
  In plaats van over features te praten, leggen we de nadruk op de voordelen en de toegevoegde waarde van een oplossing.

Hoe we probleemgericht werken aanpakken

We hebben er bewust voor gekozen om dichter bij onze klanten te staan en actief mee te denken bij het ontwerpen van een passende oplossing. Dat lukt alleen als we probleemgericht werken. Daarom focussen we in de eerste fases van elk project op de problem-space. Daarbij gebruiken we onder meer de Double Diamond uit Service Design, geïntegreerd in onze eigen 4xO-methode.

Nieuwsgierig naar hoe we dat in de praktijk aanpakken? Lees hier meer over onze aanpak.