Niets mis met een goede business case In veel projectmanagementmethoden is het gebruik van business cases ingebed als stuurinstrument. Prince2 gaat zelfs uit van de business case als de drijvende kracht en verantwoording achter een project. Desondanks worden in de praktijk nog zeer veel projecten uitgevoerd zonder business case of met slecht gebruik van dat instrument. Hoe komt dat? Nemen opdrachtgevers het in de praktijk niet zo nauw met de vraag of een project verantwoord is? Een van de factoren waardoor het gebruik van de business case als besturingsinstrument voor projecten misgaat is dat er misvattingen over het instrument bestaan. Zo gaf Gartner onlangs nog aan dat business cases geen noemenswaardige voorspellende waarde hebben als het gaat om het waarborgen van het succes van een project en het garanderen dat een project slaagt. Het is echter volkomen logisch dat business cases die voorspellende waarde niet hebben. In de stelling zit immers de misvatting dat de business case een maat zou zijn voor de kans van slagen van een project. Dat is natuurlijk niet het geval. Een business case is een maat voor de meerwaarde van de producten die uit het project voorkomen ten opzichte van de daarvoor benodigde investeringen en zegt dus niets over de kans dat de weg naar die producten ook succesvol afgelegd kan worden. Als indicator voor de slagingskans kan beter een risicoanalyse worden uitgevoerd. De enige relatie tussen de slagingskans en de business case is dat het treffen van risicobeperkende maatregelen meestal kostenverhogend werkt. Een tweede regelmatig voorkomende misvatting is dat verondersteld wordt dat het project er zelf voor kan zorgen dat de business case wordt waargemaakt. Meestal zorgt een project echter voor producten die slechts de mogelijkheid scheppen om er baten mee te realiseren. De reguliere organisatie is verantwoordelijk voor het verzilveren van de meerwaarde van de producten uit het project. Als het proces van verzilveren niet wordt georganiseerd en gestuurd, zal de business case waarschijnlijk niet worden bereikt. De programmamanagementmethodiek 'Managing Successful Programmes', net als Prince2 afkomstig van het Britse OGC, onderkent daarom ook expliciet het principe van benefits management, waarbij vertegenwoordigers van het reguliere management verantwoordelijk zijn voor het verzilveren van die meerwaarde. De derde vaak voorkomende misvatting is dat alleen kwantitatieve business cases bruikbaar zijn. Vaak zijn de baten van een project moeilijk te kwantificeren. Als de te verwachten baten van een project echter goed kwalitatief en eenduidig vast te stellen zijn en de opdrachtgever van mening is dat deze baten de investering rechtvaardigen, is er sprake van een bruikbare business case. Hier geldt in feite het onderscheid tussen 'bruikbaarheid' en validiteit van de business case. De bruikbaarheid als stuurinstrument is van belang voor de interactie tussen opdrachtgever en projectmanager. De validiteit voor de investeringsbeslissing is van belang voor de interactie tussen opdrachtgever en de sponsoren of financiers. Door gedurende het project op elke faseovergang opnieuw vast te stellen of de baten nog steeds (even) waarschijnlijk zijn en nog steeds tegen de kosten opwegen, kan de business case als justificatie voor voortzetting van het project worden gebruikt. Dezelfde redenering gaat op voor situaties dat de producten voortkomend uit het project 'slechts' voorwaardenscheppend zijn voor andere projecten die werkelijke baten opleveren. Een situatie die vaak voorkomt binnen programma's. De validiteit van de business case voor de investeringsbeslissing is contextafhankelijk. Voor de een zal de (politieke) meerwaarde van de projectuitkomsten meer waard zijn dan voor een ander. Vanzelfsprekend is een business case valide als er eenmaal sponsoren bestaand die de investering valide vinden.
Dan is er de misvatting dat automatisch een positief kosten/batenresultaat uit het project volgt als op elk evaluatiemoment tijdens het project een positieve business case bestaat. Het sturen met behulp van de business case betekent dat op elk evaluatiemoment, te beginnen bij de beslissing om het project te starten, wordt vastgesteld dat de te verwachten baten hoger zijn dan de resterende kosten. Het is dus onvoldoende om een business case alleen bij de start van het project te bepalen. Elke faseovergang vraagt om een her-evaluatie van de business case van dat moment. Reeds gedane uitgaven zijn daarbij weliswaar interessant, maar tegelijkertijd irrelevant voor het besluit tot voortzetting. Immers het besluit beïnvloedt uitsluitend de toekomstige uitgaven en inkomsten. Het gevolg kan dus zijn dat het zakelijk gezien beter is het project voort te zetten ondanks dat duidelijk is dat de som van de uitgaven uit het verleden en de toekomstige uitgaven niet kunnen worden terugverdiend. Het verlies bij voortzetting kan immers lager uitvallen dan het verlies van direct stoppen. Tegen het gevoel in is er dan toch sprake van correct gebruik van de business case als besturingsinstrument. In dergelijke gevallen is echter minstens bij het begin van het project en mogelijk vaker een te gunstige inschatting van de business case gemaakt. Dat kan het gevolg zijn van de tactische fout om de business case te laten vaststellen door iemand die belang heeft bij het project. Vaak wordt een projectmanager gevraagd om de business case op te stellen. Evenals een leverancier en de gebruiker bij wie de baten van het project terecht komen heeft de projectmanager belang bij het starten en voortzetten van het project. Het is daarom goed om het opstellen en bewaken van de business case te laten begeleiden door een terzake kundige zoals een controller. Daarmee wordt tevens voorkomen dat in de calculatie van de business case fouten worden gemaakt met het hanteren van financiële begrippen en calculatiemethodieken. De laatste misvatting die van belang is, is het verwarren van de begrippen 'doel' en 'business case'. Het doel van een project hoeft niet per sé te zijn dat de opdrachtgevende instantie zelf voordeel behaalt met de producten van het project. Ook als het doel niet is om geld te verdienen met het project moeten de baten van het project opwegen tegen de investering, bijvoorbeeld doordat de baten bij derden de investering justificeren. Dit zal bijvoorbeeld vaak het geval zijn bij projecten van de overheid. Er zal dan moeten worden aangetoond dat voordelen voor bijvoorbeeld de burger opwegen tegen de investering door de overheid. Is het, met zoveel misvattingen en fouten in het gebruik van business cases, nog zinvol om dit besturingsinstrument te hanteren? Maar natuurlijk! Bij elk project moet voor de opdrachtgever duidelijk zijn waarom hij het laat uitvoeren. De sponsoren moeten overtuigd worden voor hun (financiële) bijdrage en de projectmanager moeten weten welke meerwaarde de producten uit het project moeten kunnen leveren. De business case is daarvoor het enige systematische, expliciete, objectiverende instrument. De misvattingen en de fouten kunnen eenvoudig worden voorkomen door iemand die vertrouwd is met het hanteren van een dergelijk instrument, zoals een controller, bij het project te betrekken voor de bewaking van de kwaliteit en juist gebruik van de business case. Wie het besturingsinstrument zorgvuldig gebruikt, zorgt daarmee dat alle informatie wordt gebruikt die voorhanden is voor het zo goed mogelijk verantwoorden van een project. Wie ervoor kiest om het instrument niet te gebruiken accepteert kennelijk dat er informatie daarover gemist of genegeerd wordt en is daarom letterlijk onverantwoord bezig.
Kader 1: De Business Case Het begrip 'business case' heeft in het managementvak twee betekenissen. Enerzijds wordt het gebruikt om de situatie te beschrijven waarin er een gelegenheid is om met een bepaald besluit zakelijk voordeel te creëren, alle effecten van het besluit in ogenschouw genomen. Levert het opvolgen van het besluit netto een zakelijk voordeel op, dan is er een business case voor dat besluit. De tweede betekenis van het begrip is de business case als instrument voor het verantwoorden van een besluit, meestal een investeringsbeslissing. De business case in instrumentele zin heeft doorgaans de verschijningsvorm van een kwantitatieve kosten/batenanalyse, neergeslagen in een rapport. Als instrument wordt de business case door financiële professionals al van oudsher toegepast bij investeringsbeslissingen. De business case in instrumentele zin vergelijkt typisch twee scenario's met elkaar: het nul-scenario waarin geen verandering wordt doorgevoerd en het scenario van de overwogen verandering of investering. Met de professionalisering van projectmatig werken en de introductie van systeemdenken in projectmanagement heeft ook de business case als besturingsinstrument in projectmanagementmethodieken zijn intrede gedaan.
Kader 2: Jongleren met financiële begrippen Het is populair om projecten te verantwoorden met begrippen als terugverdientijd en Return On Investment. Dat door gebrek aan kennis van deze begrippen ook veel fouten worden gemaakt spreekt voor zich. Zo worden begrippen als Internal Rate of Return en Return on Investment vaak door elkaar gebruikt terwijl het totaal verschillende begrippen zijn die doorgaans factoren van elkaar afwijken. Ook worden niet zelden uitgaven en kosten of inkomsten en besparingen bij elkaar geteld als ware zij grootheden van hetzelfde soort. In feite zijn er twee goede basissystematieken voor business-case-calculaties: de net present value methode (NPV) en de total cost of ownership methode (TCO). De eerste is gebaseerd op de totale netto cashflow over de project- en gebruiksperiode. De tweede is gebaseerd op het verschil tussen het kostenniveau tijdens de gehele levensduur van de project- en gebruiksperiode en het huidige kostenniveau. De TCO-methode heeft als voordeel dat hij aansluit op de manier waarop bugetbegrotingen worden gemaakt, zodat de calculatie gemaakt kan worden met de cijfers uit de huidige begroting en het effect direct in het budget kan worden bekeken. Het nadeel is dat de methode gevoelig is voor afschrijvingsregels en geen rekening houdt met de contante waarde van investeringen en besparingen (hoe vroeger de baten hoe hoger de waarde ervan). De NPV-methode heeft beide nadelen niet. Hoewel deze methode voor niet-financieelingewijden aanvankelijk moeilijker lijkt, nodigt hij minder uit tot het maken van calculatiefouten. De NPV-methode berekent de som van de contante waarden van de uitgaven en inkomsten (ongeacht de methode van boekhouden) tegen een gekozen rekenrente. De aanverwante Internal Rate of Return-methode geeft aan tegen welke rente het investeringsbedrag zou moeten worden weggezet om aan het einde van de beoordeelde looptijd een gelijk eindbedrag op te leveren als het betreffende project. Het voordeel van de NPV-methode is echter dat een portfolio van projecten beoordeeld kan worden door simpelweg de NPV's bij elkaar op te tellen. Ook kan in een NPV-calculatie met variërende rekenrentes worden gewerkt, in tegenstelling tot de IRR-methode.
Kader 3: Een praktijkcasus Een gefuseerde zakelijk dienstverlener, goed voor ruim een derde van de Nederlandse markt in haar branche, voortkomend uit meerdere geografisch verspreide gelijksoortige organisaties heeft als visie dat één gezicht naar de klant moet worden geboden. Deze visie is de basis achter de fusie. In deze visie moet de klant in alle regio's met één contract dezelfde dienstverlening tegen dezelfde condities kunnen afnemen en alle dienstverlening op één verzamelfactuur gefactureerd kunnen krijgen. Voorheen moest de klant tot soms wel zeven regionale contracten afsluiten en zelf zorgen dat de inhoud en condities van die contracten zoveel mogelijk overeenkwamen. De visie was de start voor een programma voor de implementatie van een centraal ERP-pakket ter waarde van ca. 11 miljoen euro, als vervanging van de tientallen verschillende bestaande regionale pakketten. De business case voor het programma bestond eruit dat de churn-ratio van klanten drastisch omlaag zou gaan, door de betere klantbediening. Tot dan vertrokken veel grote klanten vanwege de versnipperde dienstverlening. Daarnaast zou de nieuwe organisatie veel beter bestuurbaar worden, doordat alle administraties in één systeem bijeen zouden komen. Men zou op basis van KPI's voortaan best-practices over de diverse regio's heen vaststellen en die vervolgens in alle regio's invoeren. Door de uniformiteit die uit de éénheid in klantbediening en best practices zou voorkomen zou ook de interne efficiëntie aanzienlijk verbeteren.Tot slot zou het bijeen brengen van klantinformatie uit het dienstverleningsproces de mogelijkheid scheppen voor het signaleren van trends en verschijnselen op het vakgebied van deze dienstverlener, waardoor nieuwe producten en diensten konden worden ontwikkeld. De omvang van deze baten zou jaarlijks ca. 10 miljoen euro bedragen. Daarmee gold het programma als zeer rendabel. Daarnaast verwachtte men binnen enkele jaren ingrijpende nieuwe overheidsregelgeving op binnen de branche. Daardoor zou enorme verdringing in de markt ontstaan en zouden klantbehoud, interne efficiëntie en vernieuwing essentiële factoren in de overleving worden. Met de fusie ontstond echter ook een machtsstrijd tussen de directie van de nieuwe holding en de directies van de voormalig zelfstandige deelorganisaties. Het nieuwe systeem werd daardoor gezien als bedreigend voor de autonomie van de deelorganisaties. Omdat de deelorganisaties de sponsoren van het programma waren hadden zij veel macht. Toen vervolgens de leverancier van het ERP-pakket achterstand in de oplevering veroorzaakte was dat voldoende voor de deelorganisaties om het contract met de leverancier te verbreken. De schade bedroeg ca. 3 miljoen euro. Er werd vervolgens gekozen voor een pakket dat niet in staat was om het administratieve volume van de nieuwe organisatie te herbergen en daarom noodgedwongen als losse deelsystemen op het niveau van de deelorganisaties moest worden geïmplementeerd. Na afloop van het project was men zeer tevreden, omdat het project uiteindelijk toch geslaagd was in de ogen van de deelorganisaties. Voor een groot deel van het holding-management was het echter duidelijk dat geen van de oorspronkelijk beoogde baten met dit pakket gerealiseerd konden worden omdat er van eenheid naar de klant nog steeds geen sprake was. Inmiddels, na het vertrek van een groot deel van het holdingmanagement worstelt de organisatie in sterk veranderde marktomstandigheden en onder de nieuwe overheidsregelgeving met het behoud van klanten en de interne efficiëntie. De fout die men heeft gemaakt is dat men bij de start van het programma een goede business case heeft gemaakt, maar daarna het programma uitsluitend is gaan beschouwen als een traject om een ERP-pakket te implementeren in plaats van een traject om de beoogde baten centraal te realiseren. Had men de business case in de besluitvorming centraal gesteld, dan was nooit het
besluit genomen om in plaats van één gemeenschappelijk systeem een meerdere systemen op het niveau van de deelorganisaties te implementeren, omdat daarmee per definitie de beoogde baten niet te realiseren zijn.
Mark van Rosmalen Mark is zelfstandig project- en programmamanager en gecertificeerd Prince2 practitioner en gecertificeerd MSP practitioner hij werkt vanuit Mark-One b.v.
[email protected]
www.markone.nl
