Zarządzanie ryzykiem w projekcie IT – co to jest ryzyko i jak nim zarządzać?

Co to jest ryzyko?

Ryzyko z samej swojej natury może się nigdy nie zrealizować, co gorsza – często nie wiadomo, czy to dlatego, że zrobiliśmy coś, aby temu zapobiec, czy nie.

Zacznijmy od podstaw – czym jest ryzyko i po co nim zarządzać?

Ryzyko wg definicji PMBOK , to niepewne zdarzenie lub stan, który w razie zaistnienia wywoła pozytywne lub negatywne skutki względem jednego lub wielu celów projektu. Pierwsze, co rzuca się w oczy, to fakt, że jest to zdarzenie niepewne. W przeciwieństwie do zdarzeń pewnych, jak np. termin (a także śmierć i podatki).

Mniej oczywiste jest natomiast to, że istnieją ryzyka pozytywne – zwyczajowo nazywamy je szansami. Np. jest szansa, że dołożenie jeszcze 10 funkcjonalności do aplikacji nie spowoduje, że będzie ona wolniej działać, albo że uda nam się dostarczyć coś jeszcze w tym miesiącu, jeżeli nie przeszkodzą nam w tym spotkania itp.

Ryzyka pozytywne to nie tylko semantyka i kolejny sztuczny, pseudonaukowy podział, to przede wszystkim przypomnienie zespołom, aby skupiając się na zwalczaniu zagrożeń, nie zapominały o niepozostawianiu szans szczęściu czy przypadkowi.

Po co zarządzać czymś, co nie istnieje i przeważnie najlepiej, aby nigdy nie zaistniało?

Nie ma sensu zagłębiać się zbytnio w sam sens zarządzania ryzykiem. Oczywiste jest, że planując jakiekolwiek przedsięwzięcie, choćby tylko wyjście na spacer, warto zastanowić się, czy wziąć ze sobą parasol. Podobnie jest w projekcie: liczenie na wieczne szczęście czasem się opłaca, jednak długofalowo doprowadzi do poważnych konsekwencji.

Jednak ze względu na fakt, że przewidywanie ryzyk i zapobieganie ich występowaniu bywa  czasochłonne i drogie (i z reguły takie jest), wielokrotnie ulegamy pokusie, aby odsunąć  negatywne myślenie i skupić się na tym, co uznajemy za realną wartość produktu.

Komu zatem zależy na zarządzaniu ryzykiem, a komu powinno zależeć?

Powinno zależeć każdemu, a komu realnie zależy to osobny temat. Czasami nie zależy nikomu. Ten paradoks ma niestety głębokie uzasadnienie w krótkofalowych interesach poszczególnych osób zaangażowanych w dane przedsięwzięcie.

W klasycznym projekcie IT zespół deweloperski ma ”dostarczyć produkt przed czasem, poniżej budżetu, o wystarczającej jakości”. Podstawowym interesem wykonawcy jest realizacja całości prac, bez przesadnego przemęczania się.  Nie można mieć też za złe pracownikom, że robią to, o co się ich prosi, zazwyczaj najlepiej, jak potrafią. Często naświetlanie potencjalnych problemów uchodzi za marudzenie lub niepotrzebne negatywne podejście. W obecnej kulturze pracy, szczególnie korporacyjnej, łatka szukającego problemów jest ciężkim brzemieniem i potrafi skutecznie zahamować rozwój kariery.

W związku z powyższym, teoretycznie to szeroko pojęty management powinien myśleć o ryzykach. Ostatecznie to jego przedstawiciele ponoszą negatywne konsekwencje ewentualnych zdarzeń. W rzeczywistości , zazwyczaj nikt o tym nie myśli: zabezpieczenie przed wystąpieniem ryzyka to czas, praca i pieniądze, które trzeba jakoś uzasadnić, czego pozytywnym rezultatem będzie to, że NIC się nie stanie.

Mierni managerowie skupiają się na komunikacji sukcesów, grzebaniu zagrożeń i szukaniu winnych w razie porażek, natomiast klient często nie zdaje sobie sprawy z ich rozmiarów i liczby lub – nie posiadając konkretnej wiedzy – ma tendencję do spłycania problemu.

Biznes to ryzyko: zabezpieczenie się przed wszystkim spowoduje, że projekt będzie ciągnął się w nieskończoność i stanie się nieopłacalny, a produkt – przestarzały, nim trafi na rynek. O tym, jak łatwo ponieść porażkę wdrażając projekt IT pisaliśmy w Jak ponieść porażkę, wdrażając w firmie nowy projekt IT? Dlatego właśnie ryzykiem się zarządza, a nie tylko mu zapobiega. Dość często dobrym rozwiązaniem jest zaakceptowanie ryzyka, jednak jeżeli nie mamy odpowiedniej wiedzy i procedur z tym związanych, nasze postępowanie nie jest decyzją biznesową, a zwykłym hazardem.

Podsumowanie

Dobry manager powinien umieć już na początku projektu zidentyfikować podstawowe ryzyka, wytłumaczyć klientowi/właścicielowi projektu konieczność cyklicznej obserwacji i inwestycji w proces zarządzania nimi, a także stworzyć rezerwę w budżecie, którą posłuży się w razie wypadku.

W następnych artykułach z tej serii opowiem więcej o rodzajach ryzyk, technikach identyfikacji i o wycenie ryzyka w budżecie projektu.