Zarządzanie ryzykiem w projekcie IT – jak priorytetyzować ryzyko?

Ocena dotkliwości

Najpopularniejszym sposobem oceny priorytetu dla ryzyka jest zestawienie prawdopodobieństwa jego wystąpienia ze skalą negatywnych skutków. W efekcie uzyskujemy dane o dotkliwości (severity) danego ryzyka. Im wyższa dotkliwość, tym dane ryzyko ma wyższy priorytet.

Poniższa tabela pomoże nam przełożyć wyniki na skalę dotkliwości.

Wzór do wyliczenia zagrożenia jest banalnie prosty (pozwalam sobie używać oryginalnych anglojęzycznych nazw w nawiasach, ponieważ moje autorskie tłumaczenie, może nie zawsze w pełni oddawać istotę rzeczy): prawdopodobieństwo (probability) * skutek (impact) = dotkliwość (severity).

*Prawdopodobieństwo

Tabela: Opracowano na podstawie materiałów dostępnych w PMBOK (Project Management Institute. A Guide to the Project Management Body of Knowledge)

Ocena stopnia prawdopodobieństwa oraz wartości skutków jest najczęściej arbitralną decyzją członków zespołu, czasem jednak możemy z łatwością wyliczyć koszt, jaki za sobą pociągnie. Jeżeli ryzyko dotyczy np. uszkodzenia sprzętu, bez problemu policzymy, ile kosztuje naprawa lub wymiana, nieco trudniejsze będzie jednak oszacowanie utraconych korzyści. Finansowej wycenie ryzyk poświęcę osobny materiał, w którym  postaram się pokazać, jak przygotować budżet projektu na poszczególne ryzyka.

Oceniając wartość skutków, można posłużyć się prostymi wskaźnikami z tabelki. Przykładowo: jeśli skutki są niewielkie, przypiszemy im wartość 0,1. Można także stworzyć własną tabelę i określić, jaka wartość przypisana jest danemu rozmiarowi szkody. Np. wartość 0,4 oznacza, że budżet lub czas projektu zostanie przekroczony o 30 %.

Określenie stopnia pilności ryzyka

Kolejnym ważnym czynnikiem, wpływającym na priorytety, jest pilność. Pilność, to nic innego jak termin, w którym ryzyko może się zrealizować. Jeżeli nawet niewielka szkoda może wystąpić za tydzień, okaże się, że ma wyższy priorytet niż znacznie większa, która być może wydarzy się w ciągu najbliższych miesięcy.

Apetyt na ryzyko i tolerancja

Termin “apetyt na ryzyko” kojarzy mi się z dobrym tytułem na reality show. W rzeczywistości projektowej jest to poziom ryzyka, które nasza organizacja, klient lub zespół jest w stanie zaakceptować.

Poszczególne branże różnią się apetytem na ryzyko, np. prędkość przesyłania danych w przypadku strony blogowej nie będzie aż tak istotna, jak dla instytucji finansowej. Bloger łatwiej pogodzi się z ryzykiem spowolnienia transferu danych.

Tolerancja ryzyka jest sprecyzowanym apetytem na ryzyko i przybiera najczęściej konkretną wartość, którą możemy tolerować. Rodzaje negatywnych ryzyk mogą mieć bardzo różnorodną naturę, jeśli chodzi o ich wpływ na organizację. Tolerując ryzyko, powinniśmy zdawać sobie sprawę, że jego wystąpienie może wiązać się np. z opóźnieniami w dostarczaniu danego komponentu. Czasem konsekwencje są nieco dalej idące i mniej oczywiste, jak np. problemy natury prawnej albo niekompatybilność z zewnętrznymi integracjami. Zdarza się, że konsekwencje sięgają poziomu organizacji np. zarządzania portfolio czy struktury pracowniczej.

Idąc za powyższym przykładem, prowadzący bloga może bez problemu tolerować fakt, że prędkość transferu danych na blogu spadnie o 30%, natomiast bank może pozwolić sobie jedynie na 1% spowolnienia. Jeśli zatem zagrożenie płynące z ryzyka jest niższe niż nasza tolerancja na ryzyko, możemy je spokojnie zaakceptować lub przypisać mu niski priorytet.

Polityka firmowa

Część managerów obraża się, jeśli wspomni się, że polityka firmowa ma realny wpływ na priorytety w zarządzaniu ryzykiem. Moim zdaniem, to zamykanie oczu na rzecz oczywistą. Jeżeli dla klienta lub wyższego kierownictwa w firmie, z dowolnych powodów, ważny jest dany aspekt projektu, dobry manager zadba, aby nie stało się to osią sporu, w której on i zespół stoją na przegranej pozycji.

Oczywiście, znaczenie ma powód sporu. Jeżeli doszło do niego, bo coś ma być zrobione tylko dlatego, żeby ktoś poczuł się lepiej, rolą managera jest tłumaczyć  i negocjować. Jednak tak jak przy akceptacji ryzyka – najpierw musi mieć wiedzę, a dopiero potem podejmować świadome decyzje.

Podsumowanie

Nadawanie priorytetów jest obecne we wszystkich aspektach zarządzania projektami, szczególnie w kwestii kolejności pracy nad wymaganiami projektowymi. Ryzyko nie jest niczym innym niż kolejnym wymaganiem projektowym, tyle że praca nad nim jest znacznie mniej przewidywalna i nieco bardziej frustrująca.

Przy ocenie ryzyk warto pamiętać o ich wieloaspektowości i nie skupiać się wyłącznie na jednym parametrze, np. potencjalnej szkodzie. Głębsza analiza może wykazać, że szkoda jest spora, ale mało prawdopodobna i jeśli się wydarzy, to za rok, a nawet jeśli, to biznes ją zaakceptuje.

Niezależnie od technik użytych w celu pracy nad ryzykiem, kluczem do sukcesu jest –  jak zawsze – regularność. Nawet mierne podejście do zarządzania ryzykiem jest znacznie lepsze niż wzorowy, ortodoksyjny proces, ale zaprezentowany raz i zapomniany dwa dni później.