Na rozmowie kwalifikacyjnej dla firmy konsultingowej usłyszałem pytanie: „Proszę przeanalizować, czy firma produkująca napoje powinna wejść na rynek kawy”. Przez trzy sekundy myślałem gorączkowo, czy pytają mnie o business case w rozumieniu PRINCE2, czy o case interview w stylu McKinsey. To nie jest to samo, choć nazwa identyczna.
W PRINCE2 business case to dokument uzasadniający projekt. Siedemdziesiąt stron szablonów, analiz kosztów i korzyści, ocen ryzyka. Dokument, który Executive aktualizuje w kluczowych momentach projektu. Widziałem taką dokumentację w banku – 120 slajdów PDF uzasadniających wdrożenie nowego systemu CRM. Nikt tego nie czytał poza osobą, która to napisała.
W wywiadzie konsultingowym business case to coś zupełnie innego. To 25-minutowa rozmowa, w której analizujesz problem biznesowy na głos. Nie ma szablonów, nie ma formalnych sekcji. Jest pytanie, twoja struktura myślenia i rozmowa. Rekruter z BCG nie czeka na executive summary i analizę opcji – czeka, jak szybko zbudujesz framework i zaczniesz zadawać pytania o wielkość rynku.
Dokumentacja kontra scenka improwizowana
W 2019 roku startup, w którym pracowałem, przygotowywał business case pod inwestora. CEO napisał 40-stronicowy dokument. Rozbił problem na sekcje: executive summary, analiza rynku, rekomendacja, harmonogram wdrożenia, analiza ryzyka. Typowy PRINCE2, choć nikt nie mówił wprost, że to PRINCE2.
Trzy tygodnie później ten sam CEO poszedł na rozmowę do funduszu VC. Inwestor zapytał: „Macie 50 tysięcy użytkowników miesięcznie, chcecie monetyzować – jak byście to zrobili?” CEO otworzył laptop, żeby pokazać dokumentację. Inwestor powiedział: „Nie, proszę mi powiedzieć na głos, teraz”. To była scenka improwizowana w stylu case interview. Dokumentacja leżała nieużywana w folderze Dropbox.
Różnica jest fundamentalna, choć obie sytuacje nazywają się „business case”. Jedna to artefakt projektu, druga to test umiejętności myślenia. Jedna żyje w repozytorium dokumentów, druga trwa 20 minut i kończy się decyzją albo brakiem oferty.
Kiedy pytają o case, a ty nie wiesz, o co chodzi
Kolega poszedł na rekrutację do Rocket Studio. W ogłoszeniu było: „Praca w projektach IT, zarządzanie zmianą, praca z business case’ami”. Myślał, że będzie pisał dokumentację uzasadniającą projekty. Na rozmowie dostał zadanie: „Klient ma 200 sklepów, chce wdrożyć system POS. Jak byś to zaplanował?”
Zaczął mówić o sekcjach dokumentu. „Najpierw executive summary, potem analiza kosztów…” Rekruter przerwał: „Nie pytam o dokument. Pytam, jak podszedłbyś do problemu. Co byś pytał? Jak myślisz o strukturze?” Kolega się pogubił. Nie przeszedł.
To nie była jego wina. Nikt nie wyjaśnił, że „business case” w ogłoszeniu o pracę w konsultingu oznacza sposób myślenia, nie szablon dokumentu. Podobnie jak „framework” – w PRINCE2 to zestaw procesów i ról, w rozmowie rekrutacyjnej to struktura, którą budujesz na tablicy, żeby rozłożyć problem na części.
Fred Brooks wiedział, że estymacje to kłamstwo
W 1975 roku Fred Brooks napisał „The Mythical Man-Month”. Jedna z obserwacji: ludzie źle estymują projekty, bo zakładają, że miesięczne człowiekogodziny są wymienne. Dodanie drugiego programisty do projektu nie skróci czasu o połowę – zwiększy chaos komunikacyjny i opóźni dostawę.
Teraz wyobraź sobie, że budujesz business case (dokument PRINCE2) dla projektu IT. Sekcja: harmonogram wdrożenia. Piszesz: „6 miesięcy, 4 deweloperów”. To brzmi konkretnie. Zarząd to kupi. Problem w tym, że Brooks udowodnił 50 lat temu, że takie estymacje to fikcja. Ale dokument musi mieć liczby, więc je wpisujesz. A potem projekt trwa 11 miesięcy i wszyscy udają zaskoczenie.
W case interview nikt nie pyta o harmonogram na 6 miesięcy. Pyta: „Jak szybko da się to zrobić i dlaczego?” Odpowiadasz: „Zależy od architektury, od tego, czy mamy legacy, od zespołu”. To uczciwa odpowiedź. Nie ma szablonu, który zmusza cię do podania konkretnej daty, więc możesz powiedzieć prawdę: nie wiem, dopóki nie poznam szczegółów.
Szablon kontra myślenie
PRINCE2 ma szablon business case. PMBOK też – nazywa się tam „business case document” i jest częścią project charter. Oba mówią to samo: uzasadnij projekt, pokaż koszty, korzyści, ryzyko, alternatywy. Oba sugerują, że da się to zrobić przed startem projektu. W praktyce piszesz to, co zarząd chce usłyszeć, a prawdziwe liczby poznasz dopiero w trakcie.
Widziałem business case dla wdrożenia SAP w firmie produkcyjnej. Sekcja: „Oczekiwane korzyści – redukcja kosztów operacyjnych o 15% w ciągu 18 miesięcy”. Skąd ta liczba? Z raportu Gartnera i benchmarków branżowych. Czyli z nikąd. Ale dokument musiał mieć liczbę, więc ją wpisano. Projekt trwał 3 lata, koszty przekroczyły budżet o 40%, a oszczędności? Może 5%, może wcale, nikt nie zmierzył dokładnie.
W case interview nie ma miejsca na takie kłamstwa. Pytają: „Ile kosztuje wdrożenie?” Odpowiadasz: „Potrzebuję wiedzieć, ile modułów, ile integracji, jaki zespół”. Jeśli powiesz: „15% redukcji kosztów”, następne pytanie brzmi: „Dlaczego akurat 15?” I musisz to obronić. Nie ma szablonu, który cię uratuje.
Kiedy dokumentacja ma sens
Business case jako dokument ma sens, kiedy potrzebujesz śladu decyzyjnego. Zarząd chce wiedzieć, dlaczego wydał 2 miliony na projekt. Audytorzy chcą zobaczyć uzasadnienie. W dużych organizacjach to wymóg formalny. Ktoś pisze dokument, ktoś go czyta (czasem), ktoś podpisuje. Projekt dostaje zielone światło.
Problem w tym, że dokument rzadko odpowiada na pytanie: „Czy to dobry pomysł?” Odpowiada na pytanie: „Czy mamy formalną podstawę, żeby to zrobić?” To nie to samo. Widziałem projekty z perfekcyjną dokumentacją PRINCE2, które padły, bo nikt nie zadał prostego pytania: „A po co nam to?”
Case interview zadaje to pytanie od razu. „Klient chce kupić konkurenta za 500 milionów – czy powinien?” Nie ma dokumentu. Nie ma szablonu. Jest pytanie i 20 minut na myślenie. Jeśli twoja odpowiedź brzmi: „Zależy od synergii, od wyceny, od integracji”, idziesz dalej. Jeśli zaczynasz od executive summary, odpada.
Zdjęcie: Pavel Danilyuk / Pexels
