Het probleem van de Business Case

Hoewel de term Business Case vaak valt, blijkt effectief gebruik tegen te vallen. De term wordt op verschillende manieren gebruikt; eenduidig begrip is vaak ver te zoeken. Ik gebruik de definitie die PRINCE2 en MSP aan de term Business Case toekennen.

De Business Case gaat over de “waarom” vraag

Wanneer een verandering (project, programma) wordt overwogen, is het zinnig om eens goed na te denken of de verandering gerechtvaardigd is. Is het een leuk idee? Of is er echt een goede reden? Welke verbetering kan worden gerealiseerd?

Het hart van de Business Case is daarom een analyse van de verwachte baten en de verwachte kosten. Dat zijn niet alleen de kosten van het project zelf; het zijn ook de kosten die te maken hebben met het gebruik, onderhoud en beheer die samengaan met de realisatie van de baten. Het grootste gedeelte van een Business Case gaat dus over de verwachting van wat er na het project gaat gebeuren.

Wat kost dat?

Dat lijkt een logische vraag. Maar helaas is die vraag in veel gevallen volledig contraproductief wanneer het over verandering gaat. De vraagsteller heeft in die gevallen geen interesse in de mogelijke verbetering die wordt voorgesteld en daarmee ook niet voor de rechtvaardiging. De vraagsteller heeft slechts oog voor de effecten die op korte termijn optreden; die uitgaven die op korte termijn gefinancierd moeten worden.

Daarmee is niet gezegd dat deze vraag volledig onbelangrijk is. Een Business Case analyseert ook hoeveel financiering op welke momenten nodig zal zijn en dus ook of een voorstel financieel haalbaar is. Maar om elk voorstel te reduceren tot de vraag wat het kost, is in de gedachte van een Business Case contraproductief.

Een Business Case werkt niet in de publieke zaak?

Ik krijg met regelmaat te maken met de volgende opmerking: “Een Business Case werkt nooit in de publieke zaak. Anders zou het wel business zijn”. Toegegeven: de term Business Case is een modieus en verwarrend staaltje “management consultancy babble”.

Maar omdat de Business Case de rechtvaardiging van verandering analyseert, is er ook geldigheid in het publieke domein. Baten treden op wanneer belanghebbenden (stakeholders) die ervaren. Dit kan binnen de organisatie spelen waar de verandering optreedt. Maar baten kunnen ook worden ervaren door belanghebbenden buiten de organisatie: klanten of, in het geval van de overheid, de burgers.

Meten is weten

Het is van belang om zo snel mogelijk te meten wat de gevolgen zijn van verandering. Het is daarom verbazingwekkend, zelfs extreem kortzichtig om te stellen dat de gevolgen niet gemeten kunnen worden en dat meten ook niet zinvol is, zoals een prominent politicus hier stelde. Gevolgen niet meten zorgt ervoor dat niet bijgestuurd kan worden en dan ook niet geleerd kan worden van ervaringen. Het levert “beleid” op basis van Wishful Thinking op.

De Politiek werkt dus ook niet mee

Het verbaast mij elke keer weer dat de politieke partijen hun plannen altijd presenteren in termen van: “wij willen meer geld voor …”. Zou het niet veel zinniger zijn om te praten over duidelijke doelen en geld te zien als consequentie? Zeker als de ervaring is dat potjes verdelen zonder duidelijke doelen vrijwel altijd leidt tot geldverspilling?

Ook vallen politici bij de presentatie van nieuwe plannen over elkaar heen met de vraag: “hoe gaat u dat betalen?”. Waar men vooraf pretendeert alle financiële gevolgen tot op de laatste punt en komma te kunnen voorspellen, is men blijkbaar achteraf niet van plan om de gevolgen te willen meten, zoals hiervoor werd aangetoond.

Negatieve gevolgen

Overigens zullen er ook meestal negatieve gevolgen worden ervaren door belanghebbenden. Het is ook zaak om de negatieve kant goed in kaart te brengen in een Business Case. Aangezien slecht nieuws veel sneller rondgaat dan goed nieuws, zal veel aandacht moeten worden besteed aan mogelijke negatieve gevolgen voor belanghebbenden.

Een Business Case is geen budget

Nu het toch over de politiek gaat: een aantal jaren geleden kwam daar een ander probleem op de voorgrond.

In het JSF-dossier werd een aantal jaren geleden duidelijk dat het vliegtuig fors duurder was geworden dan bij aanvang werd gedacht. Tijdens een uitzending van Pauw en Witteman werd een PvdA politicus gevraagd of de Business Case voor de JSF nog geldig was. Want waar bij het opstellen van de Business Case ruim 4 miljard was uitgetrokken voor ongeveer 90 vliegtuigen, was het door de gestegen prijs nog slechts mogelijk om minder dan 40 vliegtuigen te kopen.

Het antwoord van de politicus? De Business Case was onveranderd want destijds was er ruim 4 miljard voor uitgetrokken en dat bedrag staat nog altijd.

Deze politicus verwarde dus een Business Case met het budget.

Een Business Case is er niet voor de boekhouders

Nu het toch over de JSF gaat: de Business Case voor de het JSF-project is geschreven door de toenmalige minister van Financiën, Gerrit Zalm. Dit is, in navolging van het vorige punten, ook weer een gevaarlijke misvatting.

Omdat een Business Case gaat over nut en noodzaak had voor de JSF de Business Case geschreven moeten worden door – en onder verantwoordelijkheid van de minister van Defensie. Natuurlijk hadden er bijdragen kunnen en moeten zijn van de minister van Economische Zaken (effecten voor het bedrijfsleven) en van Financiën (financierbaarheid), maar de JSF is er primair voor Defensie en zeker niet voor de stafafdeling Financiën.

Wanneer het hoofd Boekhouding de Business Case opstelt, zal voorspelbaar de nadruk liggen op budgetten en de vraag: “wat kost dat”? Het gevolg is een vrijwel nutteloze bureaucratische exercitie en geen goede Business Case.. Deze praktijk is een voorbode van nutteloze verspilling.

Wanneer het hoofd Financiën de Business Case opstelt, zal voorspelbaar de nadruk liggen op budgetten en de vraag: “wat kost dat”?
Het gevolg is een nutteloze bureaucratische exercitie en geen goede Business Case.

Een Business Case is niet stabiel

Maar al te vaak wordt een Business Case eenmalig opgesteld, bijvoorbeeld omdat dat nu eenmaal moet van de afdeling Financiën, om vervolgens nooit meer te worden bekeken. Maar wat heb je er dan aan? Dat is toch verspilling van moeite?

Een Business Case geeft een bepaald beeld op een bepaald moment en is, mede vanwege de onzekerheden die samengaan met het voorspellen van de toekomst, subjectief en aan wijzigingen onderhevig. Het doel is om de investering doorlopend te kunnen beoordelen en verdedigen. Of natuurlijk om het project voortijdig te beëindigen bij gebrek aan rechtvaardiging.

Subjectief

Wanneer wordt gekeken naar het omstreden PGB-dossier dan wordt als belangrijke component vaak genoemd dat fraude bestreden zou worden. Als we door deze (beperkte?) bril kijken, is de Business Case niet te verdedigen. Om een fraude van minder dan 20 miljoen Euro aan te pakken is tegen de 200 miljoen Euro uitgegeven.

Maar er is meer. Misschien is het een principieel vraagstuk waarbij de stelling is dat fraude kost wat kost aangepakt moet worden. Ook zou er sprake zijn van een bezuinigingseffect.

Diverse belanghebbenden hebben verschillende belangen en dus verschillende visies op de Business Case. De vraag is: was er in het geval van PGB überhaupt een expliciete Business Case? Of was dit een kortzichtige, budgettaire affaire die er slechts in de spreadsheets van bureaucraten goed uitzag?

Doorlopende beoordeling

Hier kan de JSF weer als voorbeeld dienen. Als belangrijke onderdeel van de rechtvaardiging werd het verdieneffect van de Nederlandse industrie genoemd die inmiddels deels meetbaar zijn. Wanneer de verdieneffecten tegenvallen, zoals sommigen menen, wordt de Business Case minder verdedigbaar.

De problemen met ontwikkeling en tests geven mij het gevoel dat de JSF structurele ontwerpproblemen en daarmee inferieure kwaliteit heeft. Als dat gevoel terecht is (dat is van grote afstand natuurlijk niet hard te maken) dan zal het operationele gebruik gepaard gaan met zeer hoge kosten van onderhoud. De Business Case wordt daardoor negatief beïnvloed en wordt daardoor mogelijk niet meer valide.

Door technische ontwikkeling zijn er inmiddels mogelijk betere opties. Er zijn altijd alternatieven voor een Business Case en in de tijd kan een optie minder goed en een andere optie beter worden. Herbeoordeling kan daarom leiden tot het voortijdig stoppen van investering of project en het starten van een ander.

Wie stelt de Business Case op?

Eerder is beschreven dat deze verantwoordelijkheid niet bij de afdeling Financiën thuishoort. Maar ook:

Zeker niet de leverancier!

In discussies met ICT-ers hoor ik vaak dat zij de Business Case opstellen. Dit is een zeer ineffectieve, slechte praktijk. Om twee reden:

Een (interne) leverancier kan baten en kosten van gebruik niet inschatten

Ten eerste is het voor een leverancier onmogelijk om in te schatten wat de opbrengsten van een investering of een project zullen zijn. Zij hebben onvoldoende inzicht in de organisatie waarin het gebruik zal plaatsvinden en kunnen daardoor behalve de opbrengsten ook de kosten van gebruik en onderhoud onmogelijk inschatten.

Dit geldt ook voor een interne leverancier, zoals een interne ICT-afdeling, zoals dit dramatische voorbeeld laat zien.

Een (interne) leverancier heeft tegenstrijdige belangen

Een klant en een leverancier hebben per definitie tegengestelde belangen: de kosten van een klant zijn de opbrengsten van een leverancier. Wanneer een leverancier de Business Case opstelt zal dit resulteren in een overmatig positief verkoopverhaal. Ook dit gegeven geldt voor een interne leverancier. Dit zal een interne leverancier, bijvoorbeeld een CIO, meestal ontkennen maar in de praktijk zal het ontkennen van tegenstrijdige Business Cases resulteren in politieke spelletjes om meer budget – en dus macht – te verkrijgen.

Een Business Case gaat niet over de “wat” vraag

In het verleden deed ik advieswerk voor een zeer grote multinational. Mijn opdracht ging over het verbeteren van het projectmanagement in de Europese tak met gebruik van PRINCE2. Na verloop van tijd kreeg ik een vraag van mijn opdrachtgever. Het Amerikaanse hoofdkantoor vroeg zich af wat ze in Europa aan het doen waren want: wat was eigenlijk dat PRINCE2? In Amerika was PMBoK (PMI) gangbaar en hoe was PRINCE2 daarmee te vergelijken.

Mijn analyse van dit vraagstuk is elders op deze site te vinden en bleek in 2009 het startpunt voor de PRINCE2 Principes (hoewel dit slechts officieus, nooit officieel werd erkend).

PRINCE2 ziet een project als investering met de Business Case als rechtvaardiging.
PMI ziet een project als kostenpost met de Business Case als beschrijving van de omvang.

Later had ik een discussie met een van de schrijvers van de oorspronkelijke PMBoK. Hij bevestigde mijn visie over de verschillen tussen PMBoK en PRINCE2 en vertelde dat ook PMI inmiddels het belang van de Business Case onderkende. In een volgende versie zou ook in de PMBoK de Business Case aan de orde komen. Tijdens de discussie kreeg ik het gevoel dat wij dezelfde terminologie gebruikten maar het toch over verschillende zaken hadden. Dat gevoel bleek terecht. In de visie van Amerikanen is een project iets dat door een leverancier wordt gedaan en waarvoor de klant betaalt terwijl PRINCE2 een project ziet als een investering die door een klant wordt gedaan en waarbij een leverancier moet worden betrokken. In de PMI-visie is een PRINCE2 Business Case daarom onbruikbaar. Dat bleek ook wel want de PMI-expert bleek de Business Case te zien als beschrijving van de op te leveren scope van het project.

Ten slotte

Een Business Case is bij juist gebruik een zeer krachtig instrument om zo objectief mogelijk te kunnen oordelen over zin en onzin van een project (investering). Maar dan moet er wel juist mee worden omgegaan door de juiste personen. Daar schort het in de praktijk nog veel aan. Ik hoop dat deze bijdrage misverstanden uit de wereld zal helpen en ook helpt bij de verbetering van projecten.

Vragen of opmerkingen?

Vragen en opmerkingen zijn altijd welkom en worden op prijs gesteld. U kunt hieronder reageren!

Over de auteur

Specialist in effective change.

Accredited MSP™ and PRINCE2® trainer.

comments powered by Disqus