Softwareontwikkeling: hoe schat je projecten het beste in?
Softwareprojecten lopen vaak uit en gaan ruim over het begrote budget, waarbij men naar elkaar wijst om de oorzaak te vinden. Zo zette het kabinet laatst nog een ict-project stop dat al flink was uitgelopen en miljoenen meer zou gaan kosten dan verwacht. Ook in dit geval werden verschillende (technische) oorzaken aangewezen als de boosdoeners.
In onze vorige blogpost lees je hoe een goede projectstart dit vingerwijzen voor een groot deel kan voorkomen en het project beheersbaar kan houden. Toch blijkt het in de praktijk onmogelijk om de duur en kosten van een project precies in te schatten. Maar waar komt die onduidelijkheid vandaan? En hoe zorg je voor een zo goed mogelijke schatting, zodat je niet voor onaangename verrassingen komt te staan?
In deze blogpost bespreken we de drie belangrijkste oorzaken van de onzekerheid rondom softwaretrajecten. Ook leggen we uit welke methodes er zijn om tot een goede schatting van de duur en kosten van je softwareproject te komen.
Drie oorzaken van onzekerheid bij softwareontwikkeling
Als je softwareproject duurder uitvalt dan gepland is dat natuurlijk teleurstellend. Je kan het gevoel hebben dat er geen goede inschatting is gemaakt van de duur en kosten van het project. Daarbij denk je dat de extra kosten voorkomen hadden kunnen worden, terwijl dit vaak niet het geval is. De reden hiervan is dat er veel onzekerheid zit in softwareprojecten die je niet vooraf kan voorspellen. Het is daarom goed om te weten wat de belangrijkste oorzaken van die onzekerheid zijn:
Organisatorische onzekerheid
Elke organisatie is anders. Hoe het softwareontwikkelingsproces gaat verlopen is daardoor lastig in te schatten. De ontwikkelaars moeten zich telkens aanpassen aan hun klant. Dat brengt vooraf onzekerheid met zich mee over de te nemen stappen. Elke klant heeft zijn technologie anders ingericht, heeft andere kennis in huis en andere gebruikers of klanten. Dezelfde software bouwen komt dus eigenlijk nooit voor. Dat maakt softwareontwikkeling leuk, maar ook complex.
Ook veranderen er tijdens het ontwikkelen constant dingen binnen een bedrijf. Denk aan: het vinden van een nieuwe database die niet bekend was, veranderende gebruikers(wensen) of een bedrijfswijziging. Elke interne wijziging heeft effect op de software en kan dus zorgen voor een vertraging van het project.
Technische onzekerheid
Daarnaast is technische onzekerheid een uitdaging. Softwareontwikkelaars weten veel over de techniek, maar het is niet mogelijk om alles te weten. Het feit dat veel projecten uniek zijn betekent dat er altijd iets nieuws kan opduiken. Dit geldt voor zowel onbekende technische uitdagingen bij de klant, als voor nieuwe innovaties die je wilt toepassen.
Je kunt het vergelijken met uitdagingen binnen de bouw. Bij het bouwen van tien identieke huizen gebruik je identieke technologie. Bij grote ict-projecten is de techniek eerder te vergelijken met het bouwen van het Sydney Opera House: alles is nieuw en onzeker. Daarom kan een aannemer van een huis een goede schatting maken, maar is het Opera House vele malen duurder geworden dan gepland. Hierdoor is het bij nieuwe, bijzondere projecten moeilijker om schattingen te maken. Elk project is uniek en dat is een uitdaging voor de software-sector.
Scope creep
De laatste oorzaak van onzekerheid komt vaker voor bij projecten: de zogenaamde ‘scope creep’. Dit betekent dat de originele vraag langzaamaan verandert, doordat de eisen of wensen veranderen. Als dit herhaaldelijk gebeurt kan het zijn dat de originele vraag nog weinig lijkt op de huidige wensen, maar dus ook dat de schatting die vooraf is gemaakt niet meer klopt.
Scope creep is lastig om te beperken bij softwareontwikkeling. Bij een huis ga je niet opeens een verdieping toevoegen, maar bij software kun je eenvoudig nieuwe knoppen, gebruikers en zelfs hele functionaliteiten toevoegen. Vaak is er een goede reden om de scope uit te breiden, maar het heeft altijd effect op de doorlooptijd. Het is daarom erg belangrijk om de scope aan het begin van het project vast te leggen om scope-veranderingen verderop in het project te kunnen herkennen. Bij een aanpassing gedurende het project kijk je samen naar de gevolgen hiervan voor de planning, zodat de verwachtingen duidelijk blijven.
Onderstaande grafiek geeft mooi weer waarom de kosten van een softwareproject lastig in te schatten zijn. Deze cone of uncertainty is in het begin breed, vanwege de vele onzekerheden die je niet kunt afvangen. Gedurende het project nemen de onzekerheid en het risico af en wordt de schatting steeds preciezer. Door een pessimistische, realistische en optimistische inschatting te maken weet je met redelijke zekerheid binnen welke marges je project gaat vallen. Dit helpt je dus de kosten van een project te voorspellen en een realistisch budget af te spreken bij wijzigingen.
Methodes voor het inschatten van softwareprojecten
Nu je begrijpt waarom het zo lastig is om een softwareproject goed in te schatten, wil je natuurlijk weten hoe je zorgt voor een zo goed mogelijke schatting.
Zorg allereerst dat je organisatie de wensen voor de software zo goed mogelijk formuleert. Als de wensen duidelijk zijn is het namelijk makkelijker om het eindproduct hierop af te stemmen. Na deze inventarisatie kunnen de ontwikkelaars schattingen maken. Schattingen kunnen erg variëren afhankelijk van de kwaliteit van het team, de beschikbare informatie en van de gebruikte methode.
Op welke manier schat je een project zo goed mogelijk in? We bespreken hier drie veelgebruikte methoden om een schatting te maken:
1. Expert gebaseerde schatting
Een expert kan op basis van zijn technische kennis een goede schatting maken. De expert houdt hierbij rekening met verschillende scenario’s. De expert kan een goede schatting maken als hij de techniek van het project goed kent en hij bekend is met de kwaliteiten van het ontwikkelteam. Zo niet, dan kan zijn schatting al snel te optimistisch zijn. Houd er wel rekening mee dat projecten altijd unieke elementen bevatten en de expert met name de technische kant beoordeelt.
2. Analogie gebaseerde schatting
Analogie gebaseerde schattingen kijken naar voorgaande projecten en proberen daar een trend en schatting uit te halen. Hierbij kijk je naar hoe goed het team alle eisen van de applicatie beheerst, welke elementen al gebouwd zijn en hoeveel kennis het team heeft van het klantprobleem. Dit geeft vaak een goede indicatie, maar het is ook tijdsintensief. Het hele team is er namelijk bij betrokken om samen tot een schatting te komen. Het voordeel is wel dat het team vanaf het begin bekend is met de opdracht. Aangezien het team verder kijkt dan de techniek krijg je met deze methode een betere schatting dan met die van de expert.
3. Algoritmisch gebaseerde schatting
Algoritmisch gebaseerde schattingen zijn gericht op formules en laten een berekening los op een project. Hierbij bekijk je de functionaliteit en complexiteit van een project, door deze in tabellen te categoriseren. Per categorie voeg je een puntentelling toe. Een complexiteitsfactor berekent hiermee een totaal aantal punten. Deze data resulteert in een berekening die een doorlooptijd en kostenindicatie geeft. Deze methode is tijdsintensief en zorgt voor schijnzekerheid als de verwachtingen gebaseerd zijn op verkeerde data. Als de data betrouwbaar is dan kan een algoritmisch gebaseerde schatting een erg precies en herbruikbaar beeld geven.
Geen van de schattingstypes is superieur, elke methode heeft zijn voor- en nadelen. Als je meerdere type inschattingen combineert, verhoog je de betrouwbaarheid. Maar dit vergt extra tijd en geeft geen garantie op een beter resultaat. Gemiddeld genomen worden veiligheidsmarges gebruikt van 67,5%, 90% of 95% voor een respectievelijk optimistische schatting, realistische schatting of pessimistische schatting. Hoe kleiner en bekender projecten zijn, hoe preciezer de schatting.
Houd hierbij in het achterhoofd dat de prijs een schatting is, geen bovengrens. Wijzigingen en toevoegingen kosten tijd om te bouwen en zorgen dus voor extra kosten. Uiteindelijk staan de scope en de kosten pas volledig vast wanneer het project is opgeleverd.
Omgaan met onzekerheid in softwareontwikkeling
De onzekerheid rondom softwareprojecten is iets waar niemand belang bij heeft, maar het is onontkoombaar onderdeel van élk traject. Daarom is het belangrijk de tijd te nemen om goede schattingen te maken en je te realiseren dat schattingen geen garanties bieden voor de uiteindelijke kosten. Reserveer dus ruime hoeveelheid tijd en budget om met onzekerheden om te kunnen gaan.
Als klant kun je daarnaast zelf ook veel doen om onzekerheid weg te nemen en een softwareproject soepel te laten verlopen. Wil je weten hoe? In een volgende blogpost bespreken we concrete tips voor een succesvol softwareproject. Houd ons blog dus goed in de gaten!
Misschien vind je dit leuk
Anderen hebben deze artikelen gelezen