Template voor een business case in het Nederlands

Een business case maakt concreet of een project een positieve bijdrage levert aan de bedrijfsdoelstellingen tegen een acceptabel risico. En na de start van een project wordt de business case gebruikt om te monitoren hoe een project zich ontwikkelt en of het zinvol is om met het project door te gaan.

Een business case template

Management samenvatting

• Wat is de aanleiding?
• Wat zijn de alternatieven? Geef een vergelijking van alternatieven op hoofdlijnen.
• Welk alternatief wordt aanbevolen? Omschrijf de belangrijkste voor- en nadelen en risico’s.
• Wat zijn de conclusies en aanbevelingen?
• Wat zijn de consequenties voor de organisatie? 

Hoofdstuk 1. Achtergrond, vraagstelling, rolverdeling, afhankelijkheid

• Wat is de achtergrond en context bij dit voorstel?
• Waarom dit project? Welk probleem gaan we oplossen of wat is de gewenste situatie die we willen bereiken?
• Wie heeft welke rol bij een evt. uitvoering van dit project?
• Wat is de relatie en afhankelijkheid tussen dit project en eventueel andere ontwikkelingen in de organisatie? 

Hoofdstuk 2. Onderwerp

• Wat is het onderwerp? Geef een functionele beschrijving van de gewenste situatie en omschrijf de knelpunten uit de huidige situatie die hiermee worden opgelost.
• Om wat voor type investering gaat het? Is het een strategische investering? Leidt de investering tot verbetering in de procesuitvoering?
• Helpt de investering om onze innovatiekracht te verhogen of is het een investering gericht op het op orde houden krijgen van de bestaande omgeving? 

Hoofdstuk 3. Veronderstellingen en aannames

• Welke veronderstellingen en aannames zijn gedaan over de toekomstige situatie?
• Wat is het analyse kader?

Hoofdstuk 4. Scenario’s

• Welke scenario’s zijn denkbaar (maximaal 5)?
• Wat is het nulscenario (waarbij wordt voortgebouwd op de huidige manier van werken)?
• Welke scenario’s zijn niet meegenomen? §Welk scenario wordt verder uitgewerkt?

Hoofdstuk 5. Projectkader

5.1 Resultaat, uitgangspunten en randvoorwaarden

• Wat is het beoogde projectresultaat?
• Wat zijn de uitgangspunten (zaken die door het project als vertrekpunt moeten worden meegenomen)?
• Wat zijn de randvoorwaarden en zijdelingse beperkingen voor het project? 

5.2 Reikwijdte en scope

• Wat hoort wel en wat hoort niet bij het project?
• Welke periode, welke producten en diensten, welke processen en organisatieonderdelen vallen binnen de scope?

Hoofdstuk 6. Risico’s en impact voor de organisatie

6.1 Risico’s

• Wat zijn de risico’s voor de organisatie bij uitvoering van het project?
• Welke risico’s loopt de organisatie als het projectvoorstel niet (tijdig) de verwachte baten oplevert?
• Is bij het mislukken van dit project de continuïteit van de bedrijfsvoering gewaarborgd?
• Wat is de samenloop met andere projecten (kosten, capaciteit, inhoud/architectuur)?
• Is het project afhankelijk van andere organisaties of specifieke expertises? 

6.2 Impact

• Hoe groot is het verschil tussen de huidige situatie en de situatie nadat het projectresultaat zou zijn geïmplementeerd?
• Wat is de impact voor de gebruikersorganisatie (sociale impact)?
• Wat is de impact voor de (ICT-)beheer organisatie (technische impact)? 

Hoofdstuk 7. Baten en kosten afweging

7.1 Baten

• Wat zijn de gekwalificeerde en gekwantificeerde baten (per scenario) in de tijd uitgezet?
• Wat is de (gekwantificeerde) bijdrage aan de doelstellingen van de organisatie en wat zijn overige baten?
• Wat is de relatie tussen de baten en de projectresultaten? 

7.2 Kostensoorten en investering

• Welke kosten -zoals personeel, software, onderhoud, opleiding, desinvesteringen- zijn gemoeid met het project?
• Wat zijn eenmalige en wat zijn terugkerende kosten?
• Wat is de geschatte omvang van de investering en wanneer vinden investeringen plaats? 

7.3 Kasstromen

• Wanneer worden uitgaven en ontvangsten gerealiseerd? §Wat is de omvang van noodzakelijke reserveringen / leningen in de tijd?

7.4 Gevoeligheidsanalyse

• Wat is de gevoeligheid van de berekeningen voor de waarden en veronderstellingen die bij de berekeningen zijn gehanteerd?
• Wat is financieel gezien de worst-case en best-case situatie?

7.5 Confrontatie

• Confrontatie van de kosten, baten en risico’s; uitgewerkt per scenario. 

Hoofdstuk 8. Onderbouwing conclusie

• Welk scenario heeft de voorkeur?
• Wat zijn de argumenten om voor dit scenario te kiezen?
• Op welk moment gaan we het voorkeursscenario projectmatig realiseren? 

Niet iedere business case vraagt om zo’n uitgebreide uitwerking. Meer volwassen organisaties die gewend zijn om te werken met business cases, kiezen er vaak voor om de veronderstellingen, aannames en het analysekader niet apart in de business case op te nemen. Deze worden dan bijvoorbeeld in de portfolioboard één keer per jaar vastgesteld. Iedere ingebrachte business case wordt dan langs min of meer hetzelfde analysekader beoordeeld.. 

Business case best practices

Waar moet een goede business case aan voldoen? Een goede business case geeft een heldere en eenduidig omschrijving van het voorgenomen project: de huidige situatie, de gewenste situatie en de resultaten van het voorgenomen project. Let op: de gewenste situatie is iets anders dan de resultaten van het project. Een goed projectresultaat leidt niet persé tot de gewenste situatie. Het project kan precies opleveren wat ervan wordt verwacht, de gewenste situatie bereiken is een verantwoordelijkheid van opdrachtgever, management en medewerkers. 

Een goede business case omschrijft duidelijk de rollen. Onduidelijke rollen of niet ingevulde rollen zijn de grootste veroorzaker van falende projecten. Daarom is het noodzakelijk dat er ‘klip en klaar’ wordt vastgelegd wie eindverantwoordelijk is voor het project en hoe hij of zij die verantwoordelijkheid invult. Ook de andere verantwoordelijken, voor het projectresultaat, voor het realiseren van de baten, moeten in de business case duidelijk zijn beschreven.

Een goede business case geeft een helder beeld van kosten en baten. De kosten zijn niet alleen de ‘kosten van het project’, maar ook de onderhouds- en beheerkosten nadat het projectresultaat is opgeleverd, dus gedurende de hele looptijd van de investering. Ook de baten moeten in financieel meetbare termen worden uitgewerkt. Financieel maken van de baten of zelfs maar het kwantificeren van de baten is een lastig proces. De meeste business cases blijven steken in een vage kwalitatieve batenbeschrijving. Als je niet de moeite neemt of in staat bent om de baten kwantitatief te beschrijven, weet je één ding zeker: je zult de baten nooit realiseren. Alleen bij goede gekwantificeerde, liefst financieel gemaakte kosten en baten is een échte kosten-baten afweging mogelijk. 

Een goede business case maakt duidelijk wat het project bijdraagt aan de organisatiedoelen: het is natuurlijk prachtig als het project leidt tot een aanzienlijke verbetering in de kwaliteit van de dienstverlening van de organisatie, maar als dit niet terugkomt in de doelstellingen van de organisatie, moet dit project niet worden gestart. Er starten al teveel projecten, zorg dus dat er alleen projecten worden gestart die baten hebben die maximaal bijdragen aan de strategie van de organisatie. En als de organisatie bijvoorbeeld ‘kostenreductie’ als strategisch speerpunt heeft, dan moeten daar alle projectinspanning op zijn gericht. 

Een goede business case geeft een inschatting van de haalbaarheid en de risico’s van een voorgenomen project en schetst eventueel alternatieve scenario’s: in de business case gaat het niet om de projectrisico’s, die worden wel in het projectplan beschreven. Nee, in de business case worden de risico’s behandeld waar het project niet op kan sturen, zoals ‘kan onze organisatie dit project naast alle andere projecten wel aan?’, of ‘zijn wij als organisatie wel in staat om effectief sturing te geven aan dit project?’. Of: ‘Wat gebeurt er met ons bedrijf als het project onverhoopt niet het gewenste resultaat oplevert?’ 

Bij een goede business case mag het nulscenario eigenlijk nooit ontbreken. Het nulscenario schetst wat de situatie over pakweg 5 jaar is als de investering niet zou worden gepleegd. Een goed nulscenario geeft de mogelijkheid om een goede vergelijking te maken tussen de verschillende scenario’s.

Een goede business case geeft aan op welke manier kosten, baten en vooral risico’s worden ‘beheerst’: opnieuw een onderbelicht onderdeel in de meeste business cases. Vaak wordt de beheersing van de projectkosten nog wel beschreven. Hierover rapporteert de projectleider periodiek aan zijn stuurgroep of program board. De baten zijn vaak slechter uitgewerkt en de meeste baten worden pas gerealiseerd nadat het project is afgerond en de stuurgroep is ontbonden. Wie voelt zich dan nog verantwoordelijk voor het sturen op de ‘batenrealisatie’? 

Een goede business case draagt bij aan een breder draagvlak voor het voorgenomen project: het opstellen van de business case mag eigenlijk nooit in een één-tweetje tussen opsteller en opdrachtgever plaatsvinden. Nee, het opstellen van een business case is bij uitstek het moment dat alle betrokkenen inclusief de belangrijkste criticasters, met elkaar in gesprek gaan en eruit proberen te komen. Dit maakt de rol van de opsteller zwaarder, maar vooral de opdrachtgever wordt gedwongen om voor de troepen te staan en commitment te tonen. De business case is een gezamenlijke verantwoordelijkheid.