Wat is de waarde van de agile business case?

Een serie blogs over organisatieverandering.

BLOG – In mijn ervaring is bij opdrachtgevers vaak niet duidelijk hoe zij hun business case van waarde laten zijn binnen het agile werken. Dankzij een goede business case kun je als opdrachtgever een gefundeerde keuze maken op basis van kosten, de verwachte benefits en de risico’s. De business case helpt je zo besluiten om te starten dan wel verder te gaan met een project. Hoe zorg je voor dergelijke besluitvorming over de afweging tussen kosten, risico’s en benefits binnen het agile werken? Heeft een business case daarin nog wel waarde? Of is de business case overbodig geworden?

Door Peter Noordam. Hij is één van de grondleggers van Bisnez en organisatieadviseur op het raakvlak van business en ICT. Hij ondersteunt opdrachtgevers bij het goed inzetten van de agile business case.

Een dynamische invulling van je business case

De business case kan bij agile werken veel waarde toevoegen. Mits je als opdrachtgever de business case een andere, meer dynamische invulling weet te geven. Ik licht dit toe door een vergelijking te maken tussen het werken met de business case in het klassieke werken en het werken met de business case bij agile werken:

De business case in het klassieke werken

Bij klassieke trajecten lijken de business case en het projectplan vaak los van elkaar te staan. De business case gaat over ‘baten voor de organisatie’ en het projectplan gaat over ‘projectresultaat’. In de praktijk lopen beide zaken vaak ver uit elkaar.

De business case bij agile werken

In tegenstelling tot klassieke ontwikkeltrajecten wordt bij agile continue gehamerd op klantwaarde of ‘business value’ en wordt geëist om dit zo concreet mogelijk en liefst meetbaar in beeld te brengen. Deze filosofie helpt om in business cases de baten veel scherper te definiëren, de baten te koppelen aan sprints en het batenmanagement beter vorm te geven.

Door het verschil dat ik hierboven schets wordt de business case in agile trajecten meer een levend document. Als opdrachtgever pak je na iedere sprint de business case erbij om te bepalen of een volgende sprint nog verantwoord is vanuit kosten-baten perspectief. Je hebt daarnaast ook de mogelijkheid om te meten of de implementatie van opgeleverde features in de organisatie ook daadwerkelijk de verwachte baten oplevert. Dus veel eerder dan bij klassieke trajecten kun je al meten of je aannames over de baten klopten en hierop in een volgende sprint bijsturen.

Het MoSCoW-model

In de traditionele business case maak je een kosten-baten analyse om op basis daarvan het besluit te nemen een project te starten. Kenmerkend voor de agile manier van werken is dat op voorhand niet exact duidelijk is welke functionaliteit wordt opgeleverd aan het einde van een sprint. Dus ook de baten kunnen vooraf niet exact worden aangegeven. Je zult bij besluitvorming over de start van een project de business case anders moeten inzetten. In de business case moet meer gewerkt worden met een aantal scenario’s dat afhankelijk is van de op te leveren features. De meeste agile methoden werken volgens het zogenaamde MoSCoW-model om te bepalen welke features de komende sprint zullen worden ontwikkeld en opgeleverd. Het MoSCoW-model gaat uit van Must haves, Should haves, Could haves en Won’t haves:

• ‘Must have’ features zijn de ondergrens en moeten absoluut worden opgeleverd.
• ‘Should have’ features zijn belangrijk, maar niet vitaal. Het niet leveren van de ‘Should haves’ is pijnlijk maar de oplossing functioneert nog steeds met mogelijke dure workarounds.
• ‘Could have’ features zijn gewenst, maar minder belangrijk. Wanneer ze niet worden opgeleverd heeft dat slechts een beperkte impact.
• ‘Won’t have’ features zijn de requirements die niet zullen worden opgeleverd door dit project.

Bij het toepassen van het MoSCoW-model voor sprints wordt grofweg gewerkt met de volgende ervaringscijfers: 60 procent van de features valt in de ‘Must’ categorie, 20 procent van de features valt in de ‘Should’ categorie en 20 procent van de features valt in de ‘Could’ categorie. Opdrachtgevers kunnen de onzekerheid over de op te leveren features ondervangen door de agile business case op te stellen volgens het MoSCoW-model en de ervaringscijfers in de agile business case op te nemen:

1. één scenario waarbij alleen de ‘Must’ features worden opgeleverd (60 procent). Waarbij er extra kosten moeten worden gemaakt voor workarounds en tijdelijke tussenoplossingen met de nodige risico’s.
2. één scenario waarbij de ‘Must en Should’ features worden opgeleverd (80 procent).
3. één ideaalscenario waarbij de ‘Must, Should en Could’ features (100 procent) worden opgeleverd.

 Vooraf besluit je als opdrachtgever of je bij scenario 1, 2, of 3 akkoord gaat met de business case.

Een voorbeeld: stel er wordt een nieuwe Portal gebouwd waarmee klanten van het UWV zelf hun gegevens kunnen bijwerken. De features van het project zijn: een volgens alle specificaties werkende portal-omgeving. De opdrachtgever van het UWV heeft de benefits in een klassieke business case laten berekenen: als alle features door het project worden opgeleverd dan zijn de benefits voor zijn afdeling dat er 40 procent minder telefonisch klantcontact nodig is. Dat zorgt voor een besparing van 50 fte.

Nu is er ook een agile business case volgens het MoSCoW-model gemaakt. Hieruit blijkt dat wanneer volgens het ‘Must-scenario’ 60 procent van de features wordt opgeleverd, dit slechts een besparing van 30 fte betekent. Gaat de manager het traject ook in gang zetten nu hij dit vooraf weet? Waarbij hij ook nog bijkomende kosten gaat maken omdat er workarounds moeten worden gebouwd?

Een nieuwe manier van opdrachtgeverschap

In de praktijk zie ik dat opdrachtgevers het goed inzetten van de agile business case lastig vinden binnen de agile ontwikkelomgeving. Het vraagt immers een dynamischer gebruik van je business case waarin je denkt vanuit verschillende scenario’s én waarbij je actiever stuurt op baten management; een wezenlijk verschil met het werken met een klassieke business cases. Dit vraagt om een nieuwe manier van opdrachtgeverschap. Helaas is er nog te weinig aandacht voor dit vraagstuk.

Ik ben benieuwd naar jouw mening over dit onderwerp.

Lees ook: 4 pijlers strategische kostenreductie

Blogs in deze serie:

• De 4 systeemfouten in ons denken
• Wat is de waarde van de agile business case?