Na każdym etapie projektu informatycznego jest mnóstwo kluczowych elementów, o których nic nie wiemy. Tymczasem głównym zagrożeniem dla projektu (nie tylko informatycznego) nie jest to co wiemy, ale to czego nie wiemy. Niewiedzy nie można wyeliminować, ale poprzez zarządzanie ryzykiem można ograniczyć jej skutki. Słowniki definiują ryzyko jako prawdopodobieństwo wystąpienia szkód lub strat. Potocznie można powiedzieć, że ryzyko jest potencjalnym problemem, który czeka żeby stać się faktem. Ryzyko w swej naturze nie jest ani dobre ani złe, nie należy się go bać ale też nie można go ignorować. Należy nim zarządzać.

Ryzyko niepowodzenia projektów informatycznych jest ich nieodłącznym atrybutem. To niepowodzenie może polegać na przekroczeniu budżetu projektu, przekroczeniu terminu wykonania lub niezrealizowaniu założonej funkcjonalności. Statystyki dowodzą, że przeciętnie czas realizacji projektów informatycznych jest przekroczony o ponad 200%, koszt jego realizacji o 189% a funkcjonalność zrealizowana w 61%. Wydaje się zatem, że jednym z istotniejszych determinantów powodzenia jest identyfikacja ryzyk i minimalizacja prawdopodobieństwa, że staną się one faktem. A jeśli już staną się faktem - minimalizacja ich skutków.

Źródłem ryzyk w projektach informatycznych mogą być między innymi: cele projektu, kadra zarządzająca organizacją dla której jest realizowany projekt, klient i użytkownik, charakterystyka projektu, technologie itd. Proaktywne zarządzanie ryzykiem polega na:

• świadomym oczekiwaniu możliwości wystąpienia problemu (zamiast kłopotania się faktem jego wystąpienia),
• adresowaniu źródeł i przyczyn (zamiast adresowania skutków),
• minimalizacji prawdopodobieństwa ryzyk i ich skutków (zamiast reagowania na konsekwencje),
• przygotowaniu planów awaryjnych (zamiast reagowania na kryzys).

Zarządzanie ryzykiem jest procesem ciągłym (iteracyjnym). Proces ten (przedstawiony na rysunku nr. 1) oparty jest o pięć etapów:

1. Identyfikacja ryzyk,
2. Analiza ryzyk,
3. Plany reakcji,
4. Śledzenie ryzyk,
5. Kontrola ryzyk,

Identyfikacja ryzyk jest kluczowym etapem w procesie zarządzania ryzykiem. Nie można ocenić i zarządzać ryzykiem dopóty, dopóki go nie zidentyfikujemy i nie opiszemy. Opis ryzyka powinien zawierać charakterystykę okoliczności wystąpienia samego zdarzenia, a także jego skutków dla projektu lub organizacji. Do technik identyfikacji zalicza się: ankiety eksperckie, metodyki porównawcze, techniki delfickie, burze mózgów, metodykę Crowforda, listy kontrolne itp. Rezultatem procesu identyfikacji powinna być lista dobrze udokumentowanych ryzyk oraz ich potencjalnych skutków. Dokument ten pozwala na uświadomienie członkom zespołu projektowego, ale także decydentom organizacji prowadzącej projekt, istniejących zagrożeń dla projektu.

Analiza ryzyk to etap, który daje możliwość konwersji danych o ryzyku na informację pozwalającą podejmować decyzję. Ryzyko istnieje w układzie wyznaczonym przez dwa skrajne stany: całkowite niepowodzenie oraz pełen sukces. Analiza jest sposobnością do uporządkowania ryzyk w zależności od oszacowanego prawdopodobieństwa że ryzyko stanie się faktem, oraz dotkliwości (ciężaru) skutków wyrażonej w ustalonej skali punktowej. Skale prawdopodobieństwa i dotkliwości powinny być w miarę możliwości proste. Praktyka dowodzi, że w przypadku prawdopodobieństwa wystarczy 3 stopniowa skala: wysokie (75%), średnie (50%) i niskie (25%).  W przypadku dotkliwości dobre praktyki wskazują na skalę 3 lub 5 stopniową, przy czym najwyższa ocena oznacza skasowanie projektu. Ustalenie skal numerycznych pozwala na wyliczenie (iloczyn prawdopodobieństwa i dotkliwości) tzw. wrażliwości (ang. exposure) projektu na dane ryzyko.  Efektem analizy jest zatem ranking najbardziej istotnych ryzyk. Koniecznym uzupełnieniem tej listy jest wskazanie właścicieli poszczególnych ryzyk. Właścicielem ryzyka powinien być ten członek zespołu, którego rola pozwala na najskuteczniejszą jego neutralizację.

Planowanie metod reagowania na ryzyko to kolejny kluczowy etap procesu zarządzania ryzykiem. Określa on za pomocą jakich działań mają być rozwiązywane ewentualne problemy wynikające z poszczególnych ryzyk. Te działania winny mieścić się w dwóch  płaszczyznach: działania profilaktyczne zmierzające do zapobiegania lub minimalizacji prawdopodobieństwa że ryzyko stanie się faktem oraz kreacja planów awaryjnych, czyli reakcji na skutki. Do typowych metod reagowania należą: unikanie ryzyka, transfer ryzyka, łagodzenie i akceptacja ryzyka. Unikanie ryzyka stosuje się najczęściej, kiedy istnieją alternatywne rozwiązania mniej ryzykowne, których zastosowanie nie obniży wartości merytorycznej lub technicznej projektu. Transfer ryzyka jest w istocie przeniesieniem odpowiedzialności i konsekwencji związanych z danym ryzykiem na osoby poza zespołem projektowym – zwykle na właściciela projektu. Łagodzeni ryzyka jest związane ze zmniejszeniem prawdopodobieństwa jego wystąpienia i/lub ciężaru skutków. Najczęściej metoda ta ma swoje konsekwencje zarówno po stronie harmonogramu jak i po stronie kosztorysu. Akceptacja ryzyka polega na przyjęciu wszelkich konsekwencji wynikających z ewentualnego wystąpienia ryzyka. Akceptacja pasywna polega na przyjęciu ryzyka bez podejmowania jakichkolwiek działań zmierzających do osłabienia jego skutków. Akceptacja aktywna polega na przygotowaniu planu działań awaryjnych, które realizuje się tylko wtedy kiedy ryzyko stanie się faktem. W tym przypadku potrzebne jest określenie wyzwalaczy, czyli zdarzeń które będą sygnałem do rozpoczęcia wdrażania planu awaryjnego. Wyrazem akceptacji ryzyka powinny być odpowiednie rezerwy czasowe i finansowe, lub też zgoda na ograniczenie funkcjonalności projektu.

Śledzenie ryzyk wymaga wdrożenia działań opracowanych w poprzednim etapie procesu zarządzania ryzykiem. Pozwala on na monitorowanie statusu poszczególnych ryzyk i rejestrowaniu efektów wszystkich akcji związanych z realizacją planów działań. Działania te powinny być skoordynowane z procesem realizacji projektu. Aby skutecznie śledzić otoczenie ryzyk należy skoncentrować działania na ryzykach o najwyższym priorytecie. Priorytet ten wynika z rankingu opracowanego w fazie analizy. W typowych projektach informatycznych może to być od kilku do kilkunastu ryzyk. W wyniku podjętych działań profilaktycznych następować konieczność rekalkulacji zarówno prawdopodobieństwa jak i ciężaru ryzyk, a zatem w kolejnych iteracjach procesu zarządzania ryzykiem ich ranking może się zmieniać. Na podstawie zmian prawdopodobieństwa i ciężaru ryzyk w czasie, można opracować profile poszczególnych ryzyk, które mogą być dodatkową pomocą w fazie planowania kolejnej iteracji procesu zarządzania ryzykiem.

Kontrola to etap polegający na  monitorowaniu zdarzeń, które zostały zdefiniowane jako wyzwalacze planów awaryjnych i ewentualne ich wdrażanie.  Bieżąca ocena ryzyk pozwala też na stwierdzenie eliminacji ryzyka z powodu usunięcia jego przyczyn i/lub źródeł. Audyt ryzyk wskazuje zatem na efektywność zespołu projektowego w zarządzaniu ryzykiem, w tym trafności ich identyfikacji, ocenie, dobrym planowaniu metod neutralizacji i ich skutecznym wdrażaniu. Doświadczenie z każdego cyklu omawianego procesu powinno skutkować poprawą metod i efektów kolejnej iteracji.

W szybko zmieniających się organizacjach równolegle realizuje się szereg projektów, które konkurują ze sobą o zasoby i uwagę kierownictwa, są technicznie lub organizacyjnie współzależne, a ponadto narażają organizację na nieskoordynowany strumień informacji i zmian. Taka sytuacja niesie za sobą nowe wyzwania, często leżące poza obszarem wpływu menadżera. Dlatego zarządzanie ryzykiem nie powinno być traktowane jako uboczny, statyczny epizod, ale jako istotny, dynamiczny element procesu zarządzania każdym projektem, aktywnym w całym cyklu jego realizacji. Niestety ze względu na negatywne konotacje samego słowa „ryzyko” oraz negatywny aspekt ich konsekwencji, często w praktyce omówiony proces jest pomijany w ogóle lub sprowadzany do jednorazowego aktu nie mającego żadnych konsekwencji w realizacji projektu.

opracowanie przygotowane na podstawie:
C.L Pritchard, „Zarządzanie ryzykiem w projektach”, WigPress, Warszawa 2002;
Szkolenia Principles of  Application Development, Microsoft Training and Certification;
Doświadczeń własnych.