Definiowanie projektu cz III: Analiza ryzyka

5/5 - (5 votes)

Zazwyczaj o tym nie pamiętamy, ale ryzyko występuje zawsze. Podczas wykonywania standardowych działań oswajamy je zazwyczaj i staje się ono nieodłącznym i niezauważanym fragmentem naszej egzystencji. Projekt wprowadza jednak w nasze ustabilizowane funkcjonowanie elementy nowej gry. Każe nam wykonywać inne czynności, albo nawet te same, ale w innej kolejności. Wówczas zaczynamy zauważać to co do tej pory umykało z naszej świadomości i co często uwzględnialiśmy podświadomie: ryzyko.

Możliwe źródła ryzyka

W życiu stosujemy dwa możliwe podejścia do ryzyka: wyprzedzające (nastawione na wczesną identyfikację zagrożeń i ich unikanie) oraz przeciwdziałające (nastawione na wykrywanie i naprawianie szkód). Podczas rozpoczynania projektu zazwyczaj dręczy nas myśl o jego niepowodzeniu. Rzadko jednak staramy się określić co tak naprawdę może się nie udać a przecież początek jest najlepszym momentem do zastanowienia się co może się stać.

Spróbujmy wspólnie zastanowić się na przykładzie projektu informatycznego co może nam grozić. Wyobraźmy sobie, że zamierzamy wdrożyć w firmie zintegrowany system zarządzania przedsiębiorstwem w celu zmniejszenia liczby zwrotów od odbiorców. Nasze przedsiębiorstwo niech będzie spółką kapitałową o profilu produkcyjno-handlowym. Firma zatrudnia ponad 200 osób. Do projektu zostali oddelegowani zastępcy kierowników poszczególnych działów (produkcji, handlowego, logistyki, finansowo-księgowego) oraz główny informatyk jako kierownik projektu. Sponsorem projektu jest sam prezes.

Jak widać ze sformułowania celu projektu tak naprawdę nie wiemy jasno co powoduje zwroty. Wdrażany system informatyczny ma nam pomóc jedynie w zbieraniu informacji na temat ich źródeł. Jasno więc z tego wynika, że pierwszym i największym naszym ryzykiem jest czy droga jaką obraliśmy (wdrożenie systemu) jest drogą właściwą. Załóżmy więc dalej, że zespół rozpoczynający projekt po głębokiej analizie zdecydował, że taka droga będzie drogą właściwą. W dalszych rozważaniach pominiemy więc ten aspekt.

W naszym przedsiębiorstwie po bliższym spojrzeniu na problem zwrotów okazało się, że sprawa ma dwa aspekty:

  • klienci nie do końca wiedzieli do czego miał służyć produkt, w związku z tym reklamowali go ponieważ nie spełniał ich oczekiwań aczkolwiek działał zgodnie z przeznaczeniem;
  • część reklamacji była uzasadniona (kontrola wewnętrzna wykazała około 10 % braków), które przechodziły praktycznie przez wszystkie etapy obróbki zanim zostały wychwycone.

Ujawniły się w ten sposób kolejne potencjalne źródła ryzyka dla osiągnięcia celu, to jest: relacje z klientami (jak zmienić wyobrażenie o produkcie nie zrażając obecnych klientów do siebie), wykształcenie działu handlowego (czy handlowcy wiedzą co sprzedają) oraz sposób obsługi klienta przez serwis (który nie powinien przyjmować jednak wszystkich zwrotów).

Przyglądając się w dalszym ciągu funkcjonowaniu przedsiębiorstwa widzimy, że kolejnym źródłem ryzyka w trakcie projektu może być załoga działu produkcji, której wynagrodzenie zależne jest akordowo od ilości wytworzonych produktów (a zupełnie niezależne od liczby braków). Czyli w pewnym sensie sam kształt systemu produkcji jest nastawiony na wytwarzanie ilości a nie jakości. Idąc dalej widzimy, że dział logistyki od pewnego czasu aktywnie poszukuje nowych tańszych dostawców. Rysuje się nam więc kolejne ryzyko, tańsi dostawcy nie muszą zapewniać odpowiedniej jakości materiałów w odpowiednim czasie.

Kolejnym ryzykiem dla realizacji projektu jakie zaczyna się ujawniać jest kwestia priorytetów zarządu: czy lepiej jednak mieć więcej braków czy mieć niższe koszty zaopatrzenia.

Idąc dalej widzimy, że kolejnym podstawowym źródłem ryzyka jest skład zespołu wdrożeniowego: kierownik działu informatyki nie ma dostatecznych kompetencji do wydawania poleceń kierownikom innych działów, a ze względu na młody wiek nie ma również dużego autorytetu; zastępcy kierowników nie mają kompetencji do podejmowania decyzji wewnątrz swoich działów. Prezes z kolei jest osobą bardzo zaangażowaną w bieżące zarządzanie firmą i w związku z tym od razu wiadomo, że będzie miał mało czasu na spotkania z zespołem wdrożeniowym. Rodzi to oczywiście kolejne zagrożenie dla powodzenia projektu ze względu na brak rzeczywistego wsparcia Zarządu.

Jak zawsze w przypadku informatyzacji bardzo ważnym źródłem potencjalnego niepowodzenia jest wykonawca wdrożenia a także właściwy dobór oprogramowania do potrzeb firmy. Pociąga to za sobą ryzyko niewłaściwego oszacowania platformy systemowej, ilości licencji, uprawnień użytkowników itd.

Jak widać nawet tak prosty przykład po bliższym przyjrzeniu się ujawnia nam szereg możliwych źródeł zagrożeń. Powyższa wstępna analiza nie wyczerpuje oczywiście wszystkich możliwości.
Jak więc zabrać się do ujawniania możliwych źródeł zagrożeń dla projektu ? Metod jest oczywiście kilka. Stosować je można w zależności od kultury organizacyjnej w firmie. Jedną z możliwych metod jest burza mózgów przeprowadzona w obrębie zespołu inicjatywnego lub zastosowanie innych technik umożliwiających uzyskanie jak największej ilości pomysłów. Inną drogą jest sesja z udziałem firmy zewnętrznej pomagającej firmie w ustaleniu możliwych zagrożeń.

Sposób opisu ryzyka

Każde zidentyfikowane ryzyko powinno zostać dokładnie opisane. Ważne tutaj jest określenie po pierwsze prawdopodobieństwo jego wystąpienia. W powyższym przykładzie można na przykład stwierdzić, że ryzyko pogorszenia się relacji z klientami jest średnie, zaś ryzyko wystąpienia konfliktu z pracownikami działu produkcji jest wysokie bo podczas projektu zamierzamy od nich wymagać jakości oni natomiast motywowani są przez wykonaną ilość.

Kolejnym krokiem jest określenie wpływu, jaki dane ryzyko będzie miało na projekt, czyli na przykład konflikt z działem produkcji będzie miał wysoki wpływ na projekt. Dla tak wstępnie opisanego ryzyka należy teraz oszacować koszty jakie trzeba będzie ponieść w przypadku jego wystąpienia (można to oczywiście robić w relacji do kosztów projektu, dla danego przykładu może to być nawet 100 % kosztów projektu – ryzyko jest tak istotne, że projekt może się po prostu nie udać).

Ostatnim i chyba najistotniejszym punktem w opisie ryzyka jest określenie działań zapobiegawczych wraz z ich szacowanym kosztem. Bez określenia takich zadań cała analiza nie będzie praktycznie służyła niczemu oprócz straszenia całej firmy. Po opisaniu możliwych działań zapobiegawczych możliwe staje się podjęcie decyzji o ich wykonaniu lub też nie.

Zarządzanie ryzykiem

Dla doświadczonych menadżerów jasne jest, że powyższy opis ryzyka jest w zasadzie początkiem całego procesu zarządzania ryzykiem. W procesie zarządzania ryzykiem podczas projektu konieczne podejmowanie wielu działań. Po pierwsze monitorowanie, czyli ciągłe i okresowe śledzenie wybranych parametrów oraz badanie wpływu składowych ryzyka. Po drugie podejmowanie działań w celu minimalizacji ryzyka, czyli właściwe planowanie, projektowanie uwzględniające ryzyko, ciągłe testowanie. Po trzecie zaś tam gdzie to możliwe eliminowanie ryzyka poprzez prowadzenie symulacji oraz wybór standardowych rozwiązań.

Najistotniejszą rolę w procesie ma oczywiście kierownik projektu, którego jednym z zadań jest zarządzanie ryzykiem czyli analizowanie oraz w ramach swoich uprawnień podejmowanie decyzji lub przedstawianie sugestii Komitetowi Sterującemu. Wskazane jest zarządzanie ryzykiem wpisać w cykl comiesięcznej sprawozdawczości z działań projektowych tak, aby cały zespół widział jak zmieniła się sytuacja, jakie nowe zagrożenia pojawiły się oraz dlaczego pewne działania zostały zainicjowane.

Agnieszka Baklarz

CDN