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

1. Rejestr ryzyk

Bardzo użytecznym narzędziem, które łączy w całość informacje o ryzykach w projekcie, jest rejestr ryzyk. Jest to zbiór informacji o wszystkich ryzykach w danym projekcie, zawierający ich właściwości oraz plan reakcji na poszczególne z nich. Rejestr (o którym piszemy w tekście Podstawowe narzędzia pracy Product Ownera) przyjmuje często formę tabeli, gdzie kolejne wiersze odpowiadają poszczególnym ryzykom, a kolejne kolumny opisują ich cechy.

Internet roi się od szablonów powyższego narzędzia, podsumuję więc tylko, co moim zdaniem powinno znaleźć się w takim dokumencie.

• Typ ryzyka. Czy jest to ryzyko, awaria, a może szansa? Czy jest to ryzyko zewnętrzne czy wewnętrzne? Typów ryzyk jest wiele i każdy manager powinien przyjąć własną klasyfikację, pasującą do rodzaju projektu. (ITIL uwzględnia także różnice między Risk a Issue – ale rozważania o tym zostawimy sobie na inną okazję).
• Kto je wykrył oraz kto jest za nie odpowiedzialny? Czyli kto jest odpowiedzialny za wdrożenie rozwiązania i z kim możemy się skontaktować, aby dowiedzieć się więcej.
• Status. Np. otwarte, w trakcie, zamknięte.
• Opis (i ewentualnie opis przyczyn – root cause).
• Prawdopodobieństwo zdarzenia. Może być określone w procentach lub opisowo, np. niskie, średnie, wysokie lub bardzo wysokie.
• Poziom zagrożenia (impact). Podobnie jak z prawdopodobieństwem, możemy określić je procentowo lub opisowo. Dodatkowo, dobrze jest zaznaczyć, który aspekt projektu ucierpi: czy jest to zakres, czas, budżet, a może jakość?
• Co planujemy w związku z powyższym?

Poza tym, możemy pokusić się o uwzględnienie w rejestrze dodatkowych informacji (jednak ostrożnie z dodawaniem zbyt wielu, o czym więcej w punkcie trzecim).

• Kalkulacja dotkliwości ryzyka (severity). Na podstawie jego prawdopodobieństwa i zagrożenia. Daje nam to pełniejszy obraz sytuacji. Sama informacja, że zagrożenie jest duże, wskazuje, iż musimy się nim zająć priorytetowo. Natomiast zestawienie jej z dopiskiem, że zrealizowanie danego ryzyka jest mało prawdopodobne, sprawia, że zajęcie się nim możemy odłożyć na dalszy plan. Nie oznacza to, że ryzyka mniej prawdopodobne należy ignorować, chodzi jedynie o wyznaczenie kolejności i pilności danego ryzyka.
• Obliczenie kosztu ryzyka w walucie. O tym więcej w następnym artykule.
• Plan zapasowy. Opisuje, co w sytuacji, kiedy nasz główny plan zapobiegawczy nie wypali i ryzyko się ziści.
• Wynik. Jak sprawa się zakończyła.

2. Jak zbierać informacje

Wiemy już, gdzie przechowywać informacje o ryzykach. W jaki sposób dowiedzieć się, że one istnieją i je zidentyfikować?

• Burza mózgów. W trakcie spotkań zespołowych, przy okazji planowania projektu (np. w Scrumie) czy na specjalnie poświęconym temu posiedzeniu. To efektywna metoda, która pozwala szybko określić sporo ryzyk, od razu je omówić i ustalić, co z nimi dalej robimy.

Często managerowie poprzestają na tym jednym sposobie, który – mimo swojej użyteczności – jest także mocno niekompletny i wadliwy. Z mojej praktyki wynika, że wiele ryzyk identyfikują osoby spoza zespołu projektowego – dalsi interesariusze, specjaliści po stronie klienta czy członkowie innych zespołów. Dlatego klasyczną burzę mózgów uzupełniam o dwa istotne elementy.

• Wywiady. Warto zastanowić się, kto – poza wąskim zespołem – może dostarczyć nam istotnych informacji? Czasem jest to ekspert po stronie klienta, nie mający pojęcia o technologii, ale znający się doskonale na tym, do czego nasz produkt będzie używany. Czasem może być to ktoś z zespołu utrzymania infrastruktury, kto poinformuje nas, że w dniu planowanego wdrożenia oni zaplanowali przerwę utrzymaniową. Jak zawsze – nie warto z tym przesadzać, ale z pewnością należy mieć to na uwadze.
• Rejestr ryzyk dostępny w każdym momencie. Kojarzycie sytuację, w której ktoś Was prosi o opowiedzenie żartu i nagle nie pamiętacie żadnego, mimo że z reguły znacie ich tysiące? Podobnie jest z planowaniem identyfikacji ryzyk: ogromna większość z nich pojawia się spontanicznie, w trakcie codziennej pracy i to wtedy musi być notowana. Dlatego tak ważne jest, aby project manager przypominał o tym członkom zespołu, a sam rejestr był przyjazny i niezbyt obszerny, aby ludzie chcieli w nim cokolwiek notować.

3. Pułapka obsesyjnej analizy

Rejestr ryzyk jest tak dobry, jak jakość informacji w nim zawarta. Kolejne pola i dane można dodawać w nieskończoność, niestety, prawie nigdy nie jest to dobre wyjście.

W praktyce wielu managerów na początku projektu tworzy taki rejestr (kiedy jeszcze im się chce), identyfikuje się w nim kilka ryzyk i nigdy więcej tam nie zagląda. Ewentualnie robi to raz na jakiś czas.

Przyczyną tego stanu rzeczy, oprócz lenistwa, może być zbyt obszerna treść rejestru, czyli zbyt ambitne podejście do problemu. Każdy dokument, rejestr czy kolejny plik Excel sklecony na szybko dodaje nam pracy utrzymaniowej. Jest zatem szczególnie ważne, aby trzy razy zastanowić się, czy chcemy wprowadzać dany dokument do naszego projektu, ponieważ później musimy go aktualizować i ewentualnie rozwijać.

Taka sytuacja jest potrójnie szkodliwa: mamy nieaktualne informacje, które ktoś może pomylić z aktualnymi, tworzymy precedens, że można pewnych dokumentów nie uzupełniać oraz wywołujemy poczucie bałaganu w projekcie.

Rzeczywistość możemy opisywać w nieskończoność i początkowo każda informacja może wydawać się przydatna, jednak ich późniejsze utrzymanie, kosztuje nas sporo pracy.

Lepiej mieć o 30% czy nawet 50% informacji mniej, ale za to potrzebnych, łatwo dostępnych i aktualnych!

Podsumowanie

W sytuacji, gdy nasz projekt nie jest ogromnym przedsięwzięciem, strategia zarządzania ryzykiem może opierać się na jednym dokumencie, który stanowi główne źródło wiedzy o stanie zarządzania ryzykiem. Oczywiście w niniejszym materiale opisałem minimalne wymagania dla identyfikacji i zbierania informacji na ten temat. Jeżeli akurat budujecie drugie Burj Khalifa, zachęcam do znacznego poszerzenia wiedzy w zakresie zarządzania ryzykiem.

Natomiast jeśli akurat nie bijecie światowych rekordów w dziedzinie architektury, zachęcam, aby ilość dokumentacji była możliwie najmniejsza, natomiast świadomość i umiejętność identyfikacji ryzyk – jak najszersza.

Poniesienie porażki wdrażając projekt IT nie jest trudne, o czym pisaliśmy w artykule: Jak ponieść porażkę, wdrażając w firmie nowy projekt IT? (Anty)poradnik.