De businesscase

Dat het succes van projecten regelmatig tegenvalt, is algemeen bekend. De kosten lopen uit de hand, de baten stellen teleur, de oplevering is te laat of de kwaliteit blijft achter bij de verwachtingen. We zoeken de oorzaak graag – en soms terecht – bij bijvoorbeeld scope changes, gebrekkige communicatie en een zwakke uitvoering. Maar vaak worden essentiële fouten al gemaakt op het moment dat het project nog moet beginnen. In dit artikel staat het fundament van het project centraal, namelijk de businesscase, een document dat als volgt door Wikipedia wordt gedefinieerd: een businesscase of een haalbaarheidsstudie is een projectmanagement term waarin de zakelijke afweging om een project of taak te beginnen beschreven wordt. In de businesscase worden de kosten tegen de baten afgewogen, rekening houdend met de risico’s. Vaak wordt aan de hand van de businesscase besloten om wel of niet te starten en/of verder te gaan met een project.

Bedrijfseconomen zullen waarschijnlijk onmiddellijk ageren tegen het gebruik van de termen “kosten” en “baten” en dit is natuurlijk ook terecht, omdat we bij de financiële doorlichting – de investeringsselectie – juist redeneren in termen van “uitgaven” en “ontvangsten”, maar er zijn ook niet-financiële opbrengsten en –kosten die een grote rol kunnen spelen bij de besluitvorming en wellicht doelt de auteur daar op. Dat ook de risico’s rond het project in de businesscase moeten worden benoemd, is volstrekt juist. Maar ben je er dan? Er moet natuurlijk nog veel meer vermeld worden. Dat maakt de auteur ook duidelijk door te wijzen op de doelstellingen van de businesscase. Hij stelt dat het proces dat moet leiden tot het opstellen van een businesscase garandeert dat: 

• de belangrijkste eisen beschouwd en gedocumenteerd zijn
• voldoende informatie beschikbaar is om eerlijk verschillende voorstellen te evalueren
• zowel de winst als de risico’s, die inherent zijn aan het project, helder zijn
• het project wordt gefinancierd, en de toewijding heeft van, een manager of directielid met de capaciteiten en bevoegdheid om de voordelen van het project waar te maken
• de benodigde experts en/of afdelingen aangeven dat het project technisch uitvoerbaar is
• de oplevering van het eindresultaat en de voordelen traceerbaar en meetbaar zijn

Op zich is er weinig mis met de bovenstaande opsomming, maar als we wat kritischer kijken, dan zien we dat er heel wat “vage” begrippen in staan die ertoe kunnen leiden dat het fundament waarop het project wordt gebaseerd zwak is. Zo lijkt de businesscase vooral te draaien om het verbeteren van de winstgevendheid van de organisatie, maar ten eerste is dat begrip in het kader van projectmanagement ongelukkig gekozen, want toegevoegde waarde is immers echt iets anders. Ten tweede zijn er tal van projecten die als primair doel helemaal niet het verbeteren van het financiële resultaat hebben. Denk aan het realiseren van infrastructurele werken en het ontwikkelen van digitale leeromgevingen in het onderwijs. De baten van dergelijke projecten liggen bijvoorbeeld in het verbeteren van de mobiliteit of het verhogen van het studierendement of de studenttevredenheid. De vraag is natuurlijk hoe je die baten kwantificeert. Een andere vage term is het begrip “toewijding” dat managers of directieleden moeten hebben om de projectvoordelen waar te maken. Hoe bepaal je de mate van toewijding?

Batenmanagement

De theorie van batenmanagement, ook wel benefits realisation management genoemd, wil een bijdrage leveren aan het opstellen van betere businesscases door het toepassen van een aantal methoden en technieken. Deze theorie verschilt op 6 punten van reguliere businesscase. Deze zijn:

1. Niet-financiële baten worden ook geïdentificeerd.
2. Aan alle baten worden prestatie-indicatoren gekoppeld, dus ook aan de kwalitatieve en subjectieve.
3. Er wordt actief gezocht naar de te verwachten omvang van alle individuele baten.
4. Er worden “eigenaren” benoemd voor elke individuele bate.
5. De te realiseren baten worden expliciet gelinkt aan het project en de organisatieverandering die nodig is om de baten te realiseren.
6. Er wordt “eigenaren” benoemd die verantwoordelijk zijn voor de organisatieverandering. 

Een toelichting

Elk project leidt tot een organisatieverandering. Er zijn drie mogelijke doelen van die verandering: we gaan iets nieuws doen, we gaan iets verbeteren of we stoppen met iets waarmee we nu bezig zijn, bijvoorbeeld omdat dit besparingen oplevert. Die veranderingen moet voordelen – dus baten -opleveren en al die voordelen worden geïdentificeerd en vervolgens ingedeeld in de juiste categorie. Er zijn vier categorieën voordelen, namelijk financiële, kwantificeerbare, meetbare en observeerbare. Dit leidt tot de volgende tabel (ontleend aan Ward e.a., 2008)

De voordelen in de bovenstaande tabel zijn gepland, dus vooraf voorzien door de betrokkenen. Er kunnen ook onvoorziene voordelen optreden, zoals een lager ziekteverzuim. Het projectvoorstel kan overigens ook nadelige gevolgen hebben. Ook de negatieve baten kunnen zowel gepland als ongepland zijn. Een voorbeeld van een gepland, dus voorspelbaar negatief gevolg van een reorganisatie met gedwongen ontslagen is onrust bij het personeel en een oplopend ziekteverzuim. Een ongepland negatief gevolg zou het verslechteren van de reputatie kunnen zijn bij toeleveranciers. De werkwijze bij negatieve baten is dezelfde als bij de voordelen.

Elke bate die de organisatie probeert te bewerkstellingen c.q. elk nadelig gevolg van de potentiële investering, heeft dus een “eigenaar” die al bij het opstellen van de businesscase bij de investeringsmogelijkheid is betrokken. Als het topmanagement van de organisatie besluit dat het project kan worden gestart, blijven de eigenaren dus bij het project betrokken. Zij zijn immers verantwoordelijk voor de toekomstige realisatie van de voordelen en het beperken van de nadelen. In tabel 2 (ontleend aan Ward, 2004) staat de batenmanagementmatrix die aangeeft welke taken van de “bateneigenaar” worden verwacht.

Een veel gebruikte techniek om met positieve en negatieve baten om te gaan is management by exception. De projectcontroller speelt hierbij een belangrijke rol door informatie te verschaffen over de werkelijke ontwikkeling rond de meetbare, kwantificeerbare en financiële baten en de verschillen tussen de werkelijkheid en de verwachtingen/normen te analyseren. De “bate-eigenaar” heeft – binnen bepaalde grenzen – taken, bevoegdheden en verantwoordelijkheden om bij te sturen als dat nodig wordt geacht.

Om de baten echt te kunnen incasseren, moet de organisatie veranderen. Daarvoor is het project waarover de businesscase gaat, dan ook bedoeld. Dat betekent dat individuele personeelsleden benoemd moeten worden die verantwoordelijk zijn voor de noodzakelijke veranderingen. Zo zou mevrouw X verantwoordelijk kunnen zijn voor de scholing van de medewerkers, de heer Y voor de nieuwe formulierenstroom en mevrouw Z voor de aanschaf van bepaalde benodigdheden. Ook hun namen worden in de businesscase genoemd.

Enkele slotopmerkingen

1. Ook de businesscase die door het toepassen van batenmanagement ontstaat, is niet statisch. Gedurende het hele projectmanagementproces kunnen er inzichten ontstaan die ertoe leiden de businesscase aan te passen.
2. Het meten, rapporteren en analyseren van prestatie-indicatoren is niet gratis. Als blijkt dat het kostentechnisch onverstandig is om bepaalde baten in de plan-do-check-act-cyclus op te nemen, dan blijft dat natuurlijk achterwege.
3. Ook het benoemen van mensen die eigenaar zijn van baten of organisatieveranderingen moet op basis van gezond verstand worden gedaan. Wellicht is het verstandig om voor bepaalde zaken niemand verantwoordelijk te maken omdat het tot een te grote bureaucratie leidt. Maar het moet wel een bewuste keuze zijn om ervan af te zien, want het toekennen van taken, bevoegdheden en verantwoordelijkheden op deze terreinen kan het projectsucces duidelijk verbeteren.
4. Op een gegeven moment stopt het batenmanagement en zullen de relevante resultaten via de reguliere planning & controlcyclus worden gerapporteerd. Een voorbeeld ter verduidelijking. Een bouwbedrijf schaft een nieuw ERP-pakket aan om hierdoor de financiële administratie en de interne communicatie soepeler te laten verlopen. De geschatte implementatietijd is 2 maanden en het pakket gaat naar verwachting 8 jaar mee. De specifieke informatie over de beoogde baten van het pakket en de organisatieverandering stopt waarschijnlijk niet meteen na de implementatietijd, want dan zijn nog niet alle baten geïncasseerd. Anderzijds is het waarschijnlijk ook niet nodig om gedurende 8 jaar te rapporteren over de batenontwikkeling die het gevolg is van dit nieuwe pakket. Het zal meestal de (project)controller zijn die kan beoordelen of de informatievoorziening uit hoofde van het batenmanagement voor een bepaald project geheel of gedeeltelijk kan worden beëindigd.

Geraadpleegde literatuur

• Meijs, S. van der. (2007). Grip op batenmanagement. Sturen op de baten van verandering. De EDP-Auditor nummer 2, 6-14
• Ward, J.M., Daniel, E.M., Peppard, J. (2008). Building Better Business Cases for IT Investments. MIS Quarterly Excecutive vol. 7, no. 1 March 2008 1-15
• Ward, J.M., Murray, P., Daniel, E.M. (2004). Benefits Management – best practice guidelines. Document number: ISRC-BM-200401. Information System Research Centre. Cranfield School of Management.
• Wikipedia, zoekterm: businesscase. Geraadpleegd op 6 november 2017.