Follow Us on Twitter

Agile Business Case management

Gepubliceerd in

Een Business Case is een duur woord voor de rechtvaardiging om project te starten en te continueren. Die rechtvaardiging is in zowel agile projecten als traditionele projecten een essentieel sturingsinstrument. In de traditionele waterval aanpak is het probleem dat het moeilijk is om de Business Case tussentijds te toetsen en bij te werken. In de agile aanpak is het probleem dat bij de start van het project de scope nog onduidelijk is. Dit whitebook beschrijft aan de hand van PRINCE2 en Scrum op welke wijze het management van de Business Case agile gemaakt kan worden.

Waarom een Business Case?

De filosofie achter waterval is dat het eindresultaat voorspelbaar is door analyse, ontwerp en planning. De doorlooptijd van idee tot resultaat is daardoor meestal lang. De opdrachtgever moet meteen bij de start een groot deel van het projectbudget vrijgeven. Door die grote initiële investering stelt de opdrachtgever meer eisen aan de detaillering van de Business Case.

Bij een agile project is de filosofie dat het eindresultaat níet voorspelbaar is. Het eindresultaat ontstaat door een proces van ontdekken, leren en bijsturen. Dat proces verloopt in veel iteraties met een kleine doorlooptijd van 1 week tot maximaal 1 maand. Het voordeel hiervan is dat de opdrachtgever iedere keer maar een beperkt deel van het projectbudget hoeft vrij te geven, namelijk alleen voor de volgende iteratie. Het nadeel is dat de opdrachtgever niet goed weet wat hij voor dat geld gaat krijgen.

In beide gevallen is de noodzaak voor een Business Case universeel. De opdrachtgever wil nu eenmaal van te voren en tijdens het project weten of investeren (nog) zinvol is. In meer complexe omgevingen, waarbij er sprake is van meerdere parallelle projecten en programma's, spelen additionele overwegingen voor het starten en stoppen van projecten. In het proces van portfoliomanagement wordt ook gekeken naar het rendement van projecten. Hierdoor kan een rendabel project toch stop gezet worden omdat andere projecten meer opleveren of beter passen in de strategische doelstellingen. Ook hierbij is het essentieel dat de Business Case van het project op orde is.

Noodzakelijk afval

Een belangrijke vraag is of de extra overhead voor het maken en bewaken van een Business Case gerechtvaardigd is. In de "lean" wereld, die het gedachtengoed vormt achter agile,  wordt onderscheid gemaakt tussen activiteiten die waarde voor de eindklant creëren en activiteiten die dat niet doen. De laatste categorie wordt gekenmerkt als "waste", afval. Daarbij is sommige "afval" noodzakelijk en andere niet. De noodzakelijke afval moet beperkt worden, de niet-noodzakelijke afval kan komen te vervallen.

Een Business Case valt zeker binnen de categorie "noodzakelijk afval". Het zou naïef zijn te denken dat de vragen "is dit project wel nodig?" en "heeft het zin door te gaan?" niet gesteld hoeven te worden. Deze vragen worden gesteld, het is wel zaak een antwoord te krijgen op deze vragen met zo weinig mogelijk inspanning.

Bij een agile project hoort een agile sturingsproces

Hoe ziet zo'n Business Case er eigenlijk uit? Op Wikipedia staat een aardige samenvatting van wat er zoal in een Business Case kan staan. In de praktijk zal de inhoud van een Business Case veel beperkter zijn, met minder onderwerpen en minder diepgang van die onderwerpen. Dat is heel normaal en wenselijk in kleinere projecten en overmijdelijk bij de start van agile projecten.

Een agile project kent bij de start verschillende onzekerheden. Zo kan het zijn dat de klantwens scherp in beeld is, maar de weg om daar te komen niet. Kosten en doorlooptijd zijn daarom onzeker. Een andere mogelijke situatie is dat de projectscope begrensd wordt door een vastgesteld budget- en/of oplevermoment. In alle gevallen heeft deze onzekerheid consequenties voor de Business Case. Voor een zuivere besluitvorming moet de Business Case niet alleen dezelfde onzekerheden expliciet verwoorden, maar ook aangeven op welke wijze omgegaan wordt met deze onzekerheden. Het kan niet zo zijn dat aan het einde van het project geconstateerd wordt dat het project niet zinvol is geweest. Tussentijdse toetsing van de validiteit van het project is geen optie maar een harde randvoorwaarde voor continuering.

Business Case binnen PRINCE2

PRINCE2 schrijft geen specifieke aanpak voor. Geen waterval, ook geen agile. PRINCE2 zegt wel dat de Business Case leidend moet zijn voor het besluit een project te starten of te continueren. PRINCE2 zegt ook dat het project gestuurd moet worden op realisatie van producten, niet op het uitvoeren van activiteiten. Daarom moet bij de start van het project het te leveren projectproduct benoemd worden.

Gelukkig geeft PRINCE2 (versie 2009) ook aan dat je mag beginnen met een globale productbeschrijving en Business Case. Als deze maar voldoende inhoud heeft voor besluitvorming en je deze vaak genoeg aanscherpt. Hier zit een duidelijke opening naar een agile aanpak. Het is dan wel zaak om fases toe te passen binnen PRINCE2 waarbij iedere fase een werkend deel van de oplossing creëert. Dus niet een ontwerp-, bouw- en testfase, maar per fase een werkende oplossing. Op deze wijze ben je in staat om de Business Case aan te scherpen op reële projectresultaten.

Business Case in combinatie met Scrum

Agile Business CaseScrum is geen management methode, maar een productontwikkeling methode. Scrum kent daarom niet het concept van een Business Case. Het enige raakvlak naar de validiteit van het project ligt in de rol van de Product Owner; het sturen naar return on investment. Scrum geeft niet aan op welke wijze de Product Owner dat kan doen.
Naar onze mening geeft PRINCE2 hiervoor een heel goede invulling. De Business Case kan bij de start opgesteld worden en na iedere iteratie aangescherpt worden.

Scrum biedt hiervoor de volgende instrumenten:

  • De scope wordt beschreven in User Stories (wensen). Deze hebben ieder een eigen Business Value (hoe belangrijk is dit voor de business?) en Story Points (hoe groot is de inspanning?).
  • Het projecttempo (Velocity) kan gemeten worden door de hoeveelheid gerealiseerde Story Points per iteratie op te tellen.
  • De combinatie van Velocity, reeds gerealiseerde User Stories en User Stories te gaan (inclusief Business Value) geeft inzicht in waar het project gaat eindigen en wat het project gaat opleveren.
  • Iedere iteratie levert een werkend product op. Hierdoor kunnen uitstekend aannames t.a.v. de businessvoordelen van de oplossing getoetst worden.

Alhoewel een agile project begint met een geringe detaillering van de scope, kan de Business Case wel meteen scherp afgebakend worden. Je kan bijvoorbeeld de Business Value van User Stories baseren op MOSCOW en in de Business Case verlangen dat minimaal alle Must haves en Should haves geleverd worden. Door goed te prioriteren (belangrijke User Stories eerst) en na iedere iteratie te meten wat er nog open staat aan wensen (inclusief wat er bij komt aan nieuwe wensen) en hoe belangrijk deze wensen zijn, onstaat na iedere iteratie een scherper beeld of de Business Case haalbaar is. 

Conclusie

Een Business Case voegt waarde toe aan een agile project doordat de opdrachtgever hiermee meer grip krijgt op het project. Dat is goed omdat een agile project veel vertrouwen in de aanpak vraagt en met dit instrument de drempel om te starten met een agile aanpak wat lager wordt. Daarnaast is de Business Case ook belangrijk om de continuering van het project te verantwoorden. PRINCE2 biedt hierin een goede aanvulling op Scrum.

Links

Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.