Hoe maak je een business case voor een IT-project?

Een business case voor een IT-project bestaat uit zes onderdelen: probleemstelling, voorgestelde oplossing, kosten en baten, risico’s, planning en een aanbeveling. Samen geven ze de beslisser antwoord op één vraag: waarom dit project, en waarom nu? Schrijf daarom vanuit het perspectief van die beslisser, niet vanuit de techniek.

De zes onderdelen hebben elk een eigen functie:

• Probleemstelling: wat werkt er niet, voor wie, en wat kost dat nu?
• Voorgestelde oplossing: wat ga je doen, en welke alternatieven heb je bekeken?
• Kosten en baten: wat kost het project, en wat levert het meetbaar op?
• Risico’s: wat kan er misgaan, en hoe beperk je dat?
• Planning en mijlpalen: wanneer lever je wat op?
• Aanbeveling: welke keuze stel je voor, en wat vraag je concreet aan de beslissers?

Het gaat vaak al mis in de eerste regel. Een IT-manager schrijft bijvoorbeeld “de server is end-of-life”, dus niet meer ondersteund, terwijl de directie wil weten wat dat betekent voor klanten en omzet. Een business case is bovendien geen eenmalig document. In PRINCE2 toets je hem bij elke fase opnieuw. In de training PRINCE2 Foundation leer je hoe je een business case opzet en tijdens het hele project bijhoudt.

Je berekent de kosten en baten van een IT-project door alle directe en indirecte kosten af te zetten tegen de meetbare voordelen. Meestal reken je over een periode van drie tot vijf jaar. Neem eenmalige én terugkerende posten mee.

De kosten van een IT-project vallen uiteen in drie lagen, en vooral de laatste wordt vaak vergeten.

1. Initiële kosten
   Dit zijn de kosten om het project op te starten: licenties, hardware, implementatie en eventuele externe consultancy. Ze zijn meestal goed in te schatten, omdat er offertes tegenover staan.
2. Operationele kosten
   Dit zijn de terugkerende kosten na de livegang, zoals onderhoud, abonnementen en beheer. Ze lopen jaren door en bepalen samen met de initiële kosten de totale kosten.
3. Verborgen kosten
   Denk aan productiviteitsverlies tijdens de overgang, training en de tijd die je eigen medewerkers in het project steken. Ze staan zelden in een offerte, maar wegen vaak zwaar.

Baten maak je meetbaar met een eenvoudige formule: tijdsbesparing per medewerker × aantal medewerkers × uurtarief. Een voorbeeld: een servicedesk met 40 medewerkers krijgt een nieuw ticketsysteem. Bespaart elke medewerker 10 minuten per dag, dan levert dat bij 200 werkdagen en € 50 per uur ongeveer € 66.700 per jaar op.

Andere baten zijn minder storingen en kortere doorlooptijden. Zorg dat je elke baat kunt herleiden tot een aanname die je kunt verdedigen.

ROI, TCO en payback period beantwoorden elk een andere vraag. ROI laat zien hoeveel een investering oplevert, TCO wat iets over de hele levensduur kost en de payback period (terugverdientijd) hoe snel je de investering terugverdient. Een sterke business case gebruikt ze naast elkaar.

Terug naar het ticketsysteem. Stel dat de implementatie en training € 80.000 kosten en de licenties € 30.000 per jaar. Over drie jaar is de TCO dan € 170.000, tegenover ongeveer € 200.000 aan baten. De ROI komt daarmee op zo’n 18%, en je verdient de investering in ruim twee jaar terug.

Dit is een rekenvoorbeeld met fictieve bedragen. Gebruik in je eigen business case de cijfers van je organisatie.

Je overtuigt stakeholders door per persoon te laten zien wat het project voor hem of haar oplevert. Een financieel directeur kijkt naar rendement en risico, een operationeel manager naar wat er in het dagelijks werk verandert en een IT-manager naar technische haalbaarheid. Eén verhaal voor iedereen werkt zelden.

Vijf dingen maken in de praktijk het verschil:

• Vertaal techniek naar resultaat. “Lagere latency” wordt “klantvragen sneller afgehandeld”.
• Benoem risico’s eerlijk. Geef bij elk risico ook de maatregel.
• Begin met een samenvatting. Een executive summary van één pagina leest elke beslisser wel.
• Betrek stakeholders vroeg. Wie meedenkt over de oplossing, verzet zich minder tegen het besluit.
• Koppel aan de strategie. Laat zien welk organisatiedoel het project dichterbij brengt.

De meest gemaakte fouten zijn kosten onderschatten, baten overschatten, een vage probleemstelling en geen alternatieven noemen. Daardoor oogt de business case sterker dan hij is.

Vijf fouten komen in de praktijk steeds terug.

1. Te optimistische aannames
   Een business case met alleen het beste scenario is kwetsbaar. Voeg daarom ook een basisscenario en een pessimistisch scenario toe.
2. Veranderkosten vergeten
   Training, weerstand en tijdelijk productiviteitsverlies kosten geld. Wie ze weglaat, krijgt halverwege het project een budgetprobleem.
3. Geen duidelijke eigenaar
   Als niemand verantwoordelijk is voor de business case, bewaakt ook niemand of de baten echt komen. Wijs vooraf één eigenaar aan.
4. Te veel jargon
   Een directie die de helft van de termen niet kent, zegt eerder nee. Leg elke vakterm uit of laat hem weg.
5. Alleen ja of nee
   Zonder alternatieven of fasering geef je de beslisser maar één keuze. Een kleinere eerste fase of pilot verlaagt de drempel.

Een vage probleemstelling begint vaak bij onduidelijke eisen van gebruikers. Met de training IREB Foundation leer je die eisen helder op papier te krijgen, nog voordat je gaat rekenen.

Een business case is sterk genoeg als beslissers drie vragen kunnen beantwoorden: wat levert het op, wat kost het, en wat gebeurt er als we niets doen? Vooral die laatste vraag wordt vaak overgeslagen, terwijl niets doen ook geld kost.

Loop voor je indient deze vijf punten na:

• Begrijpt een niet-technische beslisser de probleemstelling?
• Zijn de financiële aannames te herleiden en te verdedigen?
• Staat er een realistisch risicoprofiel in, met maatregelen?
• Sluit het project aan op de strategische prioriteiten?
• Doe je een concreet verzoek, zoals budget of een go voor fase 1?

Een business case garandeert geen goedkeuring. Wel maakt hij het makkelijker om ja te zeggen.

In PRINCE2 is de opdrachtgever eigenaar van de business case. Bij elke faseovergang toetst de stuurgroep of het project nog de moeite waard is. Is dat niet meer zo, dan stop je gecontroleerd in plaats van door te gaan op een verouderd plan.

Dat principe heet in PRINCE2 “voortdurende zakelijke rechtvaardiging”. Een migratie naar de cloud kan bijvoorbeeld halverwege duurder uitvallen door nieuwe licentievoorwaarden. Met een actuele business case zie je dat op tijd.

In ruim 25 jaar trainen zien we dat juist dit stuk in de praktijk vaak ontbreekt. In de training PRINCE2 Foundation leer je hoe je dit in elke fase van je project borgt. Wil je weten wat je van het examen kunt verwachten? Lees dan hoe je je voorbereidt op het PRINCE2 Foundation-examen.