Het is verbazingwekkend hoeveel onbegrip er heerst over de betekenis van wat in het Nederlands ook wel een ‘bedrijfsplan’ of een ‘zakelijke rechtvaardiging’ wordt genoemd. Deel 2 van deze serie: de rechtvaardiging.
Het eerste gedeelte van een business case bevat de rechtvaardiging: waarom overwegen we dit project of programma überhaupt? Als je de reden, het principe en de relevantie achter het project niet kunt verantwoorden, hoort zo’n project direct te worden afgewezen.
De relevantie van het project moet vooral worden vastgesteld in termen van de bijdrage die het levert aan de bedrijfsstrategie. Bij een van mijn oudere klanten hadden ze hun projecten prioriteiten toegekend. Een verbeteringsproject voor hun callcenter kreeg prioriteit 2. Toen wij een simpel en objectief proces met ze doorliepen om de bijdrage aan de strategie te meten, verdween dat nummer twee project van de kaart. Het had geen enkele relevantie voor de strategische doelstellingen van de organisatie.
Helaas zijn er maar weinig organisaties in staat eenvoudig de bijdrage aan de bedrijfsstrategie te meten. Gewoonlijk lees je een paar vage regels waarin iets beweerd wordt over ‘strategic alignment’ die verder betekenisloos en onmeetbaar zijn, of die op geen enkele manier vergelijkbaar zijn met andere projecten: dat is onbruikbaar. Toch zou de vraag naar de exacte bijdrage aan de bedrijfsstrategie altijd de eerste moeten zijn die voor een project beantwoord moet worden.
Als je een effectief proces hebt om de strategische bijdrage te meten, stel je de projecteigenaren in staat zelf al hun goede maar irrelevante ideeën en initiatieven in een vroeg stadium bij te sturen of af te serveren.
De kosten en de risico’s van nietsdoen kunnen een andere belangrijke reden zijn voor een project. Als de kosten of risico’s van nietsdoen hoog zijn, is dat op zichzelf geen rechtvaardiging voor je zakelijke voorstel, maar het is zeker wel een rechtvaardiging om iets te ondernemen. De rest van je business case zal dan moeten aantonen dat jouw voorstel de beste benadering is om die kosten of risico’s terug te dringen.
Een project dat ‘verplicht’ is (in de zin dat het om compliancy-redenen, wegens wet- en regelgeving, onvermijdelijk is) krijgt daarmee niet automatisch groen licht; eerst zal moeten worden aangetoond dat de voorgestelde oplossing de goedkoopst denkbare oplossing is (waarom zou je geld uitgaven aan een of andere prachtige oplossing als dat niet per se hoeft?), of dat de verplicht gestelde vereisten zijn vertaald in een kans om waarde toe te voegen; een kans die op zichzelf zijn eigen relatieve waarde weer zal moeten rechtvaardigen.
In dit gedeelte voeg ik ook de analyse van de schaal, de grootte en de complexiteit van het project toe, zodat je kunt bepalen hoeveel beslag het project op de organisatie zal leggen. Hoe complexer het project, des te hoger de opleveringscapaciteit die het van de organisatie vraagt. Te veel organisaties beginnen aan projecten terwijl ze simpelweg niet de capaciteit hebben om ze succesvol af te ronden. Laten we dit helder in kaart brengen en vervolgens snijden indien nodig. Aan het einde van dit gedeelte van het plan moet het volgende duidelijk zijn:
1. Dat er een reden en een noodzaak is voor dit plan.
2. Dat het relevant is voor voldoende bijdraagt aan de bedrijfsstrategie.
3. Dat de organisatie in staat is het uit te voeren (anders kun je net zo goed niet beginnen).
4. Dat het alternatief, de kosten en/of risico’s van nietsdoen te hoog zijn.
5. En dat, als het om een verplicht project gaat, dit de goedkoopste oplossing is, óf de oplossing die op zijn beurt weer de meeste waarde oplevert.
Lees ook:
Hebt u zelf bijdragen aan of een mening over dit onderwerp,
-
-
Er zijn nog geen reacties.Reageer
Preview