Gdzieś w połowie lat 90. pewien dyrektor IT dużego banku usłyszał na szkoleniu, że jego projekt ma dwadzieścia siedem czynników sukcesu. Zapisał je wszystkie, kazał je wydrukować i powiesić w sali konferencyjnej. Po kwartale projekt był opóźniony o cztery miesiące, a plakat wciąż wisiał. Nikt nie wiedział, które z tych dwudziestu siedmiu rzeczy rzeczywiście miały znaczenie.
CSF, czyli Critical Success Factors, dosłownie Krytyczne Czynniki Sukcesu, to pojęcie stworzone właśnie po to, żeby nie skończyć z plakatem. John F. Rockart z MIT Sloan School of Management opisał tę koncepcję w marcu 1979 roku w Harvard Business Review, w artykule zatytułowanym “Chief Executives Define Their Own Data Needs”. Jego definicja była celowo wąska: CSF to ograniczona liczba obszarów, w których wyniki, jeśli są zadowalające, zapewnią organizacji sukces. Nie kilkadziesiąt. Nie lista kontrolna na trzydzieści punktów. Kilka rzeczy, bez których wszystko inne traci sens.
Skąd pochodzi ta myśl
Rockart budował swoją koncepcję na wcześniejszej pracy D. Ronald Daniela, który w 1961 roku pisał w Harvard Business Review o tym, że systemy informacyjne w firmach dostarczają mnóstwo danych, ale rzadko tych właściwych. Daniel nazwał to problemem “information overload before the term existed” – choć tamten artykuł dotyczył głównie raportowania, Rockart dostrzegł w nim zalążek czegoś użyteczniejszego. Zamiast pytać, jakich danych potrzebuje zarząd, zaczął pytać, co musi się udać, żeby firma w ogóle osiągnęła swój cel.
Metodologia, którą zaproponował, była zaskakująco prosta: dwie, trzy sesje wywiadów z top managementem, podczas których próbowano wyodrębnić te obszary działalności, gdzie niepowodzenie oznacza katastrofę. Nie ogólne priorytety strategiczne, nie cele roczne, ale konkretne miejsca, gdzie projekt albo organizacja może się posypać w sposób nieodwracalny. Rockart wyróżnił cztery źródła takich czynników: specyfika branży (Industry), przyjęta strategia (Strategy), otoczenie zewnętrzne (Environment) oraz czynniki doraźne, charakterystyczne dla danego momentu (Temporal). Ta ostatnia kategoria jest często pomijana, a bywa decydująca, szczególnie przy transformacjach cyfrowych.
CSF w projekcie IT: czym różni się od KPI
Najczęstsze nieporozumienie polega na myleniu CSF z KPI. To dwa różne narzędzia, choć zazwyczaj wędrują razem przez prezentacje w PowerPoint. KPI, Key Performance Indicator, mówi, jak mierzyć postęp. CSF mówi, w czym w ogóle postęp jest możliwy. Wyobraźmy sobie wdrożenie systemu ERP w firmie produkcyjnej zatrudniającej 300 osób. KPI może brzmieć: “80% zamówień przetwarzanych automatycznie w ciągu 6 miesięcy”. CSF brzmi inaczej: “kluczowi użytkownicy muszą być zaangażowani od etapu analizy, bo bez ich akceptacji system zostanie zablokowany na poziomie operacyjnym”. Jedno jest miarą, drugie jest warunkiem brzegowym.
W praktyce zarządzania projektami IT, zwłaszcza według PMBOK Guide wydawanego przez PMI, CSF pojawia się najczęściej w fazie inicjacji projektu, przy definiowaniu zakresu i ryzyk. PRINCE2 używa podobnej logiki przez pojęcie Business Case: jeśli zniknie któryś z fundamentalnych powodów, dla których projekt istnieje, projekt powinien zostać zatrzymany. To w pewnym sensie Krytyczny Czynnik Sukcesu zawarty w strukturze metodyki, choć PRINCE2 nie operuje tym terminem wprost.
Dlaczego tak łatwo to zepsuć
Problem z CSF polega na tym, że im więcej osób uczestniczy w ich definiowaniu, tym dłuższa powstaje lista. Efekt Ringelmanna, opisany przez Maximiliana Ringelmanna już w 1913 roku na podstawie badań nad pracą grupową, działa tu trochę odwrotnie niż w fizycznym wysiłku: zamiast rozmywać wysiłek, rozmywa odpowiedzialność za priorytety. Każdy dział dorzuca swój czynnik, każdy kierownik chce mieć reprezentację na liście, i po trzecim warsztacie strategicznym mamy dwadzieścia siedem punktów z powrotem na ścianie.
Rockart proponował dosłownie kilka czynników – i ta liczba nie była przypadkowa. Chodziło o to, żeby każdy, kto zarządza projektem, był w stanie przytrzymać je w głowie podczas spotkania z zarządem i odpowiedzieć bez zaglądania do dokumentacji. Jeśli trzeba szukać CSF w Jirze, to raczej nie są to już czynniki krytyczne, tylko kolejna zakładka w systemie, którą nikt nie otwiera po kickoffie.
Pytanie, które zostaje po lekturze Rockarta, brzmi mniej więcej tak: czy w Twoim obecnym projekcie każdy z interesariuszy – od sponsora po developera – potrafiłby wymienić z pamięci trzy rzeczy, bez których ten projekt nie ma sensu? Jeśli odpowiedzi są różne, lista CSF jest prawdopodobnie za długa albo za abstrakcyjna. Albo jedno i drugie.
Źródła
- Rockart J.F., “Chief Executives Define Their Own Data Needs”, Harvard Business Review, marzec-kwiecień 1979.
- PMBOK Guide, Project Management Institute (PMI), kolejne wydania od 1996.
- PRINCE2 Manual, AXELOS, kolejne wydania od 1996.
Zdjęcie: Shubham Dhage / Unsplash
