Waarom mislukken software projecten?

Als je een project aangaat met een app ontwikkelaar wil je graag dat het resultaat op tijd, binnen budget en met alle vooraf aangegeven functionaliteit wordt opgeleverd. Waarom mislukt dit soms en hoe kun je ervoor zorgen dat het eindresultaat voldoet aan de verwachtingen?

3 minuten - Gepubliceerd door Julian de Lange op 5 maart 2021

Staande lucifers als symbool voor software projecten

Wat zijn de oorzaken?

Het ontwikkelen van software kent een duidelijk proces. Er is een idee van een opdrachtgever wat door een ontwerper wordt vormgegeven. Vervolgens bekijkt een software architect de wensen, stelt kritische vragen en komt met een onderbouwd plan voor de technische realisatie. Zodra er een akkoord is op dit plan gaat een team van software engineers het product realiseren.

In de praktijk blijkt dat veel software projecten niet de beoogde doelstellingen wat betreft geld, tijd en kwaliteit bereiken. De oorzaken hiervan zijn bij veel van deze projecten gelijk en kunnen verdeeld worden over vier categorieën:

  • De verwachtingen en doelstellingen zijn niet duidelijk omschreven
  • Er ontbreekt ownership
  • Slechte of gebrekkige communicatie
  • De scope van het project wordt verkeerd ingeschat
Staande lucifers als symbool voor software projecten

Formuleer heldere verwachtingen

Wanneer de verwachtingen en doelstellingen voor een software project niet duidelijk zijn omschreven, weet een ontwikkelaar niet precies wat hij moet bouwen en waarom hij dat moet bouwen. Zonder deze informatie begint een project met een valse start. Met de volgende vier vragen kunnen de verwachtingen worden gekaderd:

  • Wat moet er gebeuren?
  • Waarom moet dit gebeuren?
  • In welke volgorde moet dit gebeuren?
  • Bij wie ligt de verantwoordelijkheid voor elk van deze werkzaamheden?

Verschillende visies en meningen kunnen ervoor zorgen dat de antwoorden op deze vragen uiteenlopen. Kom samen tot een concrete definitie van het doel en de wensen, zodat deze als uitgangspunt voor het project dienen.

Stel een Product Owner aan

Een gebrek aan ownership en betrokkenheid vanuit de opdrachtgever zorgt voor onduidelijkheid naarmate een project verder in het proces raakt. Stel daarom een Product Owner aan die frequent overleg voert met de ontwikkelaar of leverancier.

Samen kun je afstemmen hoe om te gaan met onduidelijke ontwerpen, voortschrijdend inzicht, ellenlange overlegmomenten, onverwachte tegenslagen en alle andere mogelijke aspecten tijdens een project. Een goede Product Owner voldoet aan de volgende kenmerken:

  • Kennis over het te ontwikkelen product
  • Visie op het te ontwikkelen product
  • Mandaat om namens de stakeholders beslissingen te kunnen nemen
  • Is beschikbaar voor vragen en overleg
  • Stelt kritische vragen
Staande lucifers als symbool voor software projecten

Maak afspraken over communicatie

Zonder effectieve communicatie mist er transparantie tussen de opdrachtgever, de ontwikkelaars en de stakeholders. Om resultaatgericht te kunnen werken is het nodig om duidelijke contactmomenten te hebben.

De aanwezigheid van een Product Owner vanuit de klant houdt niet automatisch in dat de communicatie vlot zal verlopen. Hanteer daarom duidelijke afspraken over wanneer er gecommuniceerd wordt en via welke kanalen. Zo ontstaat er een eenduidig beeld en worden frustraties vermeden.

Goede communicatie is de sleutel tot een kwaliteitsproduct.

Stel kritische vragen over de scope

De scope bepaalt welke punten binnen het project vallen en welke daarbuiten. Denk hierbij vooral aan functionaliteit, koppelingen en specifieke technische requirements. Wanneer de scope van een project onjuist blijkt, ligt dat meestal aan de volgende oorzaken:

  • De vraagstelling van de klant was onduidelijk
  • De vraagstelling was goed, maar de schatting van de leverancier was te optimistisch
  • De schatting was prima, maar de leverancier daalt in prijs om een contract te winnen

De scope evolueert tijdens de ontwerpfase als gevolg van voortschrijdend inzicht en nieuwe afwegingen. Als app ontwikkelaar splitsen we projecten daarom op in twee afzonderlijke trajecten, de Tekentafel en de Bouw.

Tijdens de Tekentafel creëren we het volledige ontwerp, komen we tot een technisch plan en stemmen we samen met de klant de definitieve requirements af. Zo komen we tot een helder totaalbeeld en beginnen we pas met bouwen wanneer we precies weten wat de wens is, zodat we tot een succesvol eindresultaat kunnen komen.

Staande lucifers als symbool voor software projecten