Is de duivelsdriehoek nog steeds gevaarlijk voor een software project?
29 februari 2024
Als je vaker in een project hebt gewerkt komt deze term zeker bekend voor: de ‘duivelsdriehoek’. Deze naam is niet voor niets bedacht want deze driehoek kan je voor duivelse dilemma’s plaatsen.
Welke dilemma’s hebben we het over?
In onderstaande grafiek kun je zien welke aspecten de duivelse driehoek vormen.
De duivelsdriehoek impliceert dat er een inherent evenwicht moet zijn tussen tijd, scope en kosten. Als één aspect verandert, heeft dit directe gevolgen voor de andere aspecten. Bijvoorbeeld, als de scope van het project wordt vergroot, kan dit leiden tot een langere doorlooptijd en hogere kosten. Omgekeerd kan het verkorten van de tijdlijn leiden tot beperkingen in de scope of hogere kosten.
In een traditioneel project wordt de scope vooraf vastgesteld. Vervolgens probeert men in te schatten hoeveel geld en tijd dit gaat kosten. In de praktijk is dit een lastige exercitie.
Waarom is het zo lastig om in te schatten hoeveel tijd/budget het kost om een software project af te ronden?
Er zijn meerdere redenen aan te wijzen waarom het erg lastig is om deze inschatting te maken. De 4 belangrijkste factoren zijn:
Software projecten zijn erg complex
Het bouwen van een software systeem kan erg complex zijn. Vooral in grotere projecten zijn er zoveel bewegende delen dat het een uitdaging is om dit vooraf volledig te overzien.
Onzekerheid over de vereisten
Het is vaak erg lastig om vooraf compleet te bepalen wat je nodig hebt. Er is meestal sprake van voortschrijdend inzicht gedurende het traject. Het is goed om vooraf al goed na te denken wat je nodig hebt. Het is een utopie om te denken dat je alles 100% vooraf in kaart zult hebben.
Externe factoren
Binnen een software project zijn er vaak ook veel externe facturen. Het maken van een koppeling bijvoorbeeld met andere systemen. Daar heb je vooraf niet altijd controle over. Als het externe systeem problemen of bugs heeft kan dit meteen ook weer invloed hebben op het project.
Technische belemmeringen
Het is vooraf niet altijd duidelijk tegen welke technische problemen je aan gaat lopen. Systemen kunnen soms vreemd gedrag vertonen waardoor een ontwikkelaar extra tijd nodig heeft om dit probleem op te lossen.
Waardoor belemmerd de duivelse driehoek in traditionele projecten de voortgang van het project?
Vaak denken klanten dat ze volledige zekerheid hebben bij de keuze voor deze traditionele aanpak. Vooral lijkt het alsof alle aspecten (budget, scope en doorlooptijd) vast staan. Op papier een ideaal model.
In de praktijk zul je echter merken dat geen enkel van deze aspecten zal verlopen zoals je het vooraf verwacht door de eerder genoemde onzekerheden in een project.
Hoe kunnen we aan de duivelse driehoek ontkomen?
Binnen EchoNova werken wij volgens een agile / SCRUM model. In dit model. Daarmee draaien we de piramide om:
Vooraf stel je precies vast hoeveel tijd en budget je beschikbaar hebt. De enige factor die dynamisch is is daarmee de scope. Voordeel is dat deze factoren ook niet zullen veranderen.
Hoe krijg in controle over de scope?
Door te werken in sprints van twee weken bepaalt de klant per twee weken welke functionaliteit gaat worden opgeleverd. Door in kleine iteraties te werken kun je ook steeds bijsturen. Voorschrijdend inzicht is binnen deze aanpak geen enkel probleem.
Hoe kan ik zorgen dat mijn belangrijkste features wel daadwerkelijk gebouwd gaan worden?
Het is zaak om goed te prioriteren. Zorg dat de belangrijkste features eerst worden opgepakt. Een handige aanpak daarin is het MosCow model. Dit is een acroniem voor:
Must have: wat is het allerbelangrijkste noodzakelijk voor het product om te kunnen werken voor gebruikers.
Should Have: features die erg belangrijk zijn maar een livegang niet direct in de weg staan.
Could Have: dit zijn meer de nice to haves die het product verbeteren maar geen core functionaliteit is.
Won’t Have: sommige voorgesteld features zijn (of blijken) geen meerwaarde te hebben. Deze verwijder je uit de lijst.
Zoals je hebt kunnen lezen kan deze manier van werken een goede oplossing voor software projecten. Juist door agile (flexibel) te zijn op scope kun je een goed product voor je klanten opleveren.
