W 2018 widziałem business case na 47 stron. Kolega z banku pokazał mi go przy kawie. Był tam ROI policzony do trzeciego miejsca po przecinku, analiza ryzyka na sześciu macierzach i harmonogram wdrożenia rozpisany co do tygodnia. Projekt padł po trzech miesiącach. Nikt tego dokumentu nie otworzył po dniu, w którym zarząd go zaakceptował.
Problem nie leżał w jakości analizy. Leżał w tym, że business case był traktowany jak bilet wstępu, nie jak mapa.
Czym właściwie jest business case
PMBOK Guide definiuje business case jako dokumentowane uzasadnienie ekonomiczne projektu. W PRINCE2 jest to jeden z kluczowych produktów zarządczych, aktualizowany przez cały cykl życia projektu. Obie definicje są poprawne i obie mówią w pewnym sensie to samo: business case odpowiada na pytanie, dlaczego warto wydać pieniądze.
Ale to właśnie „dlaczego warto” bywa różnie rozumiane. Dla CFO to ROI powyżej 15 procent w ciągu 18 miesięcy. Dla dyrektora IT to redukcja długu technicznego. Dla product ownera to features, które klienci kupią. Te trzy perspektywy rzadko się spotykają w jednym dokumencie.
W praktyce widziałem business case’y, które były albo za krótkie (slajd z trzema bulletami), albo za długie (wspomniany wcześniej 47-stronicowy moloch). Dobre przykłady leżą gdzieś pośrodku. Zawierają konkretne liczby, nazwane ryzyka i jasno określone kryteria sukcesu. Nie zawierają wishful thinking.
Jak to wygląda w terenie
Przykład z życia: firma produkcyjna w 2019 planowała wymianę systemu ERP. Business case liczył sobie 12 stron. Zaczynał się od opisu problemu: stary system kosztował 280 tysięcy rocznie w utrzymaniu, integracje łatały 14 osób, a czas zamknięcia miesiąca wynosił 11 dni roboczych.
Następnie szła analiza opcji: zostać przy starym (koszt utrzymania rośnie o 8 procent rocznie), wymienić na rozwiązanie chmurowe (capex niższy, opex wyższy), wymienić on-premise (odwrotnie). Każda opcja miała policzone NPV na trzy lata.
Kluczowy był rozdział o ryzykach. Tam padły konkretne liczby: 30-procentowe prawdopodobieństwo opóźnienia wdrożenia o kwartał, 15-procentowe ryzyko przekroczenia budżetu o 200 tysięcy, 40-procentowe ryzyko, że migracja danych zajmie dwa razy dłużej niż planowano.
Projekt się powiódł. Nie dlatego, że business case był idealny, ale dlatego że zarząd wiedział, na co się pisze. Gdy pojawił się csłip w migracji danych, nikt nie krzyczał „przecież w business case było inaczej”. Było dokładnie tak, jak w business case – z zaznaczonym ryzykiem.
ROI i inne liczby, które zawsze budzą wątpliwości
ROI to ulubiona metryka CFO i znienawidzona metryka project managerów. Wzór jest prosty: (zysk minus koszt) podzielone przez koszt, razy 100. Problem w tym, że zysk z projektu IT często jest niemierzalny przez pierwsze 6–12 miesięcy.
Widziałem business case, gdzie ROI wynosił 340 procent w ciągu dwóch lat. Brzmiało pięknie. Problem był taki, że połowa korzyści pochodziła z „oszczędności czasu pracowników”. Nikt nie policzył, czy ci pracownicy faktycznie wykorzystają zaoszczędzony czas produktywnie, czy po prostu wyjdą wcześniej do domu.
Peter Drucker w „Managing for Results” pisał, że biznes konwertuje zasoby w wartość ekonomiczną. Business case powinien pokazywać tę konwersję w liczbach. Jeśli liczby opierają się na założeniach typu „wszyscy będą korzystać z systemu optymalnie”, to nie jest business case, tylko science fiction.
Co zostawić, a czego nie wkładać
Dobry business case ma Executive Summary na pół strony, opis problemu na stronę, analizę opcji na dwie strony i finansową kalkulację na kolejne dwie. Reszta to załączniki dla tych, którzy chcą więcej szczegółów.
Złe business case’y mają 40 stron wprowadzenia o tym, jak ważna jest cyfrowa transformacja. Nikt tego nie czyta. Zarząd chce wiedzieć trzy rzeczy: ile to kosztuje, co dostaniemy i jakie jest ryzyko, że wszystko sypnie się.
PRINCE2 wymaga, żeby business case był żywym dokumentem. To znaczy, że aktualizujesz go na każdym etapie projektu. Jeśli w fazie inicjacji zakładałeś ROI 25 procent, a po discovery okazało się, że będzie 12 procent, to nie ukrywasz tego. Aktualizujesz dokument i idziesz do sponsora z pytaniem: kontynuujemy?
To podejście ratuje projekty przed tym, co Brooks w „The Mythical Man-Month” nazywał „catastrophic convergence” – momentem, gdy wszyscy nagle zdają sobie sprawę, że projekt nie ma sensu, ale jest już za późno, żeby go zatrzymać.
Źródła
- Project Management Institute, \“PMBOK Guide\”, PMI, wersje 6 i 7.
- AXELOS, \“Managing Successful Projects with PRINCE2\”, oficjalna dokumentacja metodyki PRINCE2.
- Brooks F.P., \“The Mythical Man-Month: Essays on Software Engineering\”, Addison-Wesley, 1975.
- Drucker P., \“Managing for Results\”, Harper & Row, 1964.
Zdjęcie: cottonbro studio / Pexels
