CSF, czyli kilka rzeczy, których zawalenie położy cały projekt

W marcu 1979 roku John F. Rockart opublikował w Harvard Business Review artykuł pod tytułem “Chief Executives Define Their Own Data Needs”. Brzmi jak nudny tekst o raportowaniu. W rzeczywistości był to moment, w którym zarządzanie projektami dostało narzędzie, które przez kolejne dekady będzie odwracać rozmowy z “co zrobiliśmy” na “co tak naprawdę musi się udać”. Rockart nazwał to Critical Success Factors, w skrócie CSF.

Definicja, którą zaproponował, jest zadziwiająco prosta i zadziwiająco rzadko stosowana w praktyce. CSF to ograniczona liczba obszarów, w których wyniki muszą być zadowalające, żeby organizacja lub projekt mogły odnieść sukces. Nie lista stu rzeczy do zrobienia, nie pełna dokumentacja wymagań, lecz kilka obszarów, których zawalenie położy całą resztę niezależnie od tego, jak sprawnie działają pozostałe elementy. Artykuł Rockarta był cytowany ponad 6500 razy, co jak na akademicki tekst o zarządzaniu informacją jest wynikiem niemal absurdalnym.

Skąd się bierze ta nazwa i dlaczego brzmi jak robot z Gwiezdnych Wojen

CSF, wymawiane litera po literze, rzeczywiście ma ten chłodny, technokratyczny oddech skrótu, który mógłby oznaczać zarówno system zarządzania flotą kosmiczną, jak i kolejny framework z rodziny ITIL. Tymczasem za akronimem kryje się jedna z bardziej zdroworozsądkowych koncepcji w historii project managementu. Rockart zaproponował, żeby zamiast zbierać wszystkie możliwe dane o projekcie, zacząć od pytania: które obszary są naprawdę krytyczne? Gdzie pojedyncze niepowodzenie uruchamia efekt domina?

W kontekście projektów IT CSF‑y pojawiają się najczęściej w czterech postaciach. Pierwsza to zaangażowanie sponsora, i nie chodzi o podpisanie dokumentu inicjującego projekt, lecz o realną obecność przez całe 12 czy 18 miesięcy wdrożenia. Druga to jasność zakresu w momencie startu, bo projekt, który rusza z rozmytymi wymaganiami, zwykle kończy się albo eskalacją do zarządu, albo dostarczeniem czegoś, czego nikt już nie potrzebuje. Trzecia to gotowość organizacji do zmiany, szczególnie bolesna przy wdrożeniach ERP, gdzie system jest gotowy, a procesy biznesowe po stronie klienta nie. Czwarta to kompetencje zespołu projektowego, i tu nie da się oszukać tabelką w Jirze.

Czym CSF różni się od KPI i dlaczego to nie jest tylko kwestia semantyki

Zestawienie CSF z KPI to jeden z tych tematów, przy których project managerowie zaczynają mówić jednocześnie. KPI, czyli Key Performance Indicators, mierzą, jak dobrze coś idzie. CSF określają, co musi iść dobrze, żeby w ogóle miało sens mierzenie czegokolwiek. To raczej relacja przyczynowo-skutkowa niż dwie nazwy tego samego. Wyobraźmy sobie wdrożenie platformy e‑commerce dla sieci handlowej. KPI może być czas odpowiedzi serwera poniżej 2 sekund albo współczynnik konwersji powyżej 3%. CSF w tym samym projekcie to prawdopodobnie integracja z systemem magazynowym działająca przed dniem startu produkcyjnego. Jeśli ta integracja nie zadziała, żaden KPI nie ma znaczenia, bo platforma i tak nie może sprzedawać.

PMBOK Guide od PMI oraz manuał PRINCE2 od AXELOS traktują CSF jako element planowania na poziomie strategicznym, bliżej Business Case niż planu projektu. W PRINCE2 komitet sterujący formalnie zatwierdza Business Case, który powinien zawierać właśnie te obszary krytyczne. W praktyce bywa tak, że Business Case liczy dwadzieścia stron, a sekcja o czynnikach krytycznych ma dwa zdania napisane przez kogoś, kto nie znał projektu. Tego rodzaju dokument jest trochę jak instrukcja bezpieczeństwa w samolocie, którą wszyscy mają przed oczami i nikt nie czyta.

Jak CSF wygląda w realnym projekcie IT

Wyobraźmy sobie hipotetyczny projekt migracji systemu ERP w firmie produkcyjnej zatrudniającej 400 osób. Projekt trwa 14 miesięcy. Na starcie zespół wdrożeniowy identyfikuje pięć CSF-ów, zapisuje je w dokumentacji i na tym kończy się ich życie operacyjne. Nikt nie weryfikuje ich statusu na co-tygodniowych spotkaniach statusowych. Dwa z tych pięciu obszarów zaczynają się sypać w ósmym miesiącu, bo kluczowy ekspert domenowy po stronie klienta odszedł z firmy, a jego wiedzy nikt nie zdążył utrwalić. Projekt kończy się po 20 miesiącach, z przekroczonym budżetem i zakresem okrojonym o funkcje, które były powodem całego wdrożenia. Standish Group w swoim cyklicznym CHAOS Report od lat wskazuje, że zaangażowanie użytkowników i wsparcie kierownictwa to stale powracające czynniki różnicujące projekty zakończone sukcesem od tych, które kończą się inaczej.

Różnica między projektem, który traktuje CSF jak żywy dokument, a projektem, który traktuje go jak formalność przy inicjacji, jest trudna do zmierzenia na początku i bolesnie oczywista przy retrospekcji po fakapie. Jeśli interesuje cię, jak to wygląda szerzej w kontekście zarządzania usługami IT, zajrzyj do tekstu o zarządzaniu usługami IT, który rozkłada podobne mechanizmy na czynniki pierwsze.

Ile CSF-ów to za dużo

Rockart pisał o ograniczonej liczbie obszarów. W praktyce badań nad CSF przyjmuje się, że optymalna lista to od trzech do pięciu pozycji. Lista dziesięciopunktowa to już w pewnym sensie nie CSF, lecz zwykły rejestr ryzyk przemianowany na bardziej marketingowe hasło. Kiedy wszystko jest krytyczne, nic nie jest krytyczne, i to jest jeden z tych paradoksów, który objawia się zwykle dopiero przy audycie powdrożeniowym.

Prawdziwe pytanie nie brzmi, czy twój projekt ma CSF‑y. Każdy projekt je ma, czy je nazwał, czy nie. Pytanie brzmi, czy zespół wie, które obszary są naprawdę krytyczne, i czy ktoś aktywnie pilnuje ich statusu między spotkaniami. Jeśli zastanawiasz się, jak wpisuje się to w szerszy kontekst doradztwa strategicznego dla działu IT, warto zobaczyć, kiedy organizacje sięgają po strategiczne wsparcie IT i dlaczego zazwyczaj dzieje się to o kilka miesięcy za późno.

Źródła

1. Rockart J.F., “Chief Executives Define Their Own Data Needs”, Harvard Business Review, marzec 1979.
2. Bullen C.V., Rockart J.F., “A Primer on Critical Success Factors”, MIT CISR Working Paper, 1981.
3. AXELOS, “Managing Successful Projects with PRINCE2” (PRINCE2 Manual), aktualne wydanie.
4. Project Management Institute, “A Guide to the Project Management Body of Knowledge” (PMBOK Guide), aktualne wydanie.
5. Standish Group, CHAOS Report, cykliczny raport o stanie projektów IT.

Zdjęcie: PIRO4D / Pixabay