Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00459 005569 13608632 na godz. na dobę w sumie
Zarządzanie ryzykiem w projektach informatycznych. Teoria i praktyka - książka
Zarządzanie ryzykiem w projektach informatycznych. Teoria i praktyka - książka
Autor: Liczba stron: 224
Wydawca: Helion Język publikacji: polski
ISBN: 83-246-1508-3 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> biznes it >> zarządzanie projektami it
Porównaj ceny (książka, ebook, audiobook).

Nie ryzykuj! Unikniesz przykrych niespodzianek!

Każdy projekt, program czy dowolne przedsięwzięcie z założenia obarczone są pewnym ryzykiem. Nie da się z góry przewidzieć wszystkich szczegółów i możliwych opóźnień, wymusić od zaangażowanych osób obietnicy dotrzymania terminu ani tak zakląć losu, by nie zrobił jakiegoś złośliwego psikusa. Można jednak ograniczyć ryzyko przez właściwe zaplanowanie całego procesu, wskazanie punktów projektu najbardziej narażonych na błędy i oszacowanie prawdopodobieństwa ich wystąpienia. Takie działanie pozwala wystarczająco szybko zareagować na pojawiające się problemy i wydatnie przyspieszyć tempo prac.

Książka 'Zarządzanie ryzykiem w projektach informatycznych. Teoria i praktyka' traktuje właśnie o wszelkich aspektach minimalizowania ryzyka związanego z wdrażaniem projektu informatycznego. Z tego podręcznika dowiesz się, co to jest cykl życia projektu, jak rozpisać jego poszczególne fazy, w jaki sposób oceniać ryzyko i koordynować pracę wielu osób w obszarach objętych kontrolą. Nauczysz się zauważać potencjalne zagrożenia i nie dopuszczać do powstawania wymiernych strat. Ponadto znajdziesz tu życiowe przykłady radzenia sobie w trudnych sytuacjach -- do wykorzystania w Twojej własnej praktyce.

Poznaj wszystkie aspekty zarządzania ryzykiem w projektach IT!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Zarz¹dzanie ryzykiem w projektach informatycznych. Teoria i praktyka Autor: Adam Korczowski ISBN: 978-83-246-1508-7 Format: 158×235, stron: 224 Nie ryzykuj! Unikniesz przykrych niespodzianek! (cid:129) Definicje ryzyka, jego parametry i obszary zagro¿eñ (cid:129) Identyfikacja czynników ryzyka, szacowanie skutków i szybka reakcja (cid:129) Praktyczne przyk³ady, metody analizy i b³êdy w zarz¹dzaniu ryzykiem Ka¿dy projekt, program czy dowolne przedsiêwziêcie z za³o¿enia obarczone s¹ pewnym ryzykiem. Nie da siê z góry przewidzieæ wszystkich szczegó³ów i mo¿liwych opóŸnieñ, wymusiæ od zaanga¿owanych osób obietnicy dotrzymania terminu ani tak zakl¹æ losu, by nie zrobi³ jakiegoœ z³oœliwego psikusa. Mo¿na jednak ograniczyæ ryzyko przez w³aœciwe zaplanowanie ca³ego procesu, wskazanie punktów projektu najbardziej nara¿onych na b³êdy i oszacowanie prawdopodobieñstwa ich wyst¹pienia. Takie dzia³anie pozwala wystarczaj¹co szybko zareagowaæ na pojawiaj¹ce siê problemy i wydatnie przyspieszyæ tempo prac. Ksi¹¿ka „Zarz¹dzanie ryzykiem w projektach informatycznych. Teoria i praktyka” traktuje w³aœnie o wszelkich aspektach minimalizowania ryzyka zwi¹zanego z wdra¿aniem projektu informatycznego. Z tego podrêcznika dowiesz siê, co to jest cykl ¿ycia projektu, jak rozpisaæ jego poszczególne fazy, w jaki sposób oceniaæ ryzyko i koordynowaæ pracê wielu osób w obszarach objêtych kontrol¹. Nauczysz siê zauwa¿aæ potencjalne zagro¿enia i nie dopuszczaæ do powstawania wymiernych strat. Ponadto znajdziesz tu ¿yciowe przyk³ady radzenia sobie w trudnych sytuacjach -- do wykorzystania w Twojej w³asnej praktyce. (cid:129) Cykl ¿ycia projektu i zarz¹dzania ryzykiem (cid:129) Metodyki zarz¹dzania ryzykiem (cid:129) Zarz¹dzanie ryzykiem na poziomie strategicznym (cid:129) Zarz¹dzanie ryzykiem w programach, projektach, operacyjnym (cid:129) Zarz¹dzanie bezpieczeñstwem i utrzymaniem ci¹g³oœci biznesu (cid:129) Definiowanie polityki zarz¹dzania ryzykiem (cid:129) Ocena ryzyka (cid:129) Planowanie reakcji na ryzyko (cid:129) Monitorowanie i sterowanie ryzykiem (cid:129) Strategia zarz¹dzania portfelem projektów (cid:129) Uzasadnienie biznesowe i analiza ekonomiczna wartoœci projektu (cid:129) Wybrane techniki analizy ryzyka (cid:129) B³êdy w zarz¹dzaniu ryzykiem (cid:129) Podstawy teorii informacji i rachunku prawdopodobieñstwa (cid:129) Szablony dokumentów wspieraj¹cych zarz¹dzanie ryzykiem Poznaj wszystkie aspekty zarz¹dzania ryzykiem w projektach IT! Spis treĈci Od autora ......................................................................................... 7 Rozdziaä 1. Wprowadzenie .................................................................................. 9 Podstawowe pojĊcia związane z niepewnoĞcią ................................................................ 9 Zmiana biznesowa w organizacji .................................................................................... 11 Cykl Īycia projektu ......................................................................................................... 14 Definicje i parametry ryzyka .......................................................................................... 16 Obszary zagroĪeĔ w dziaáalnoĞci projektowej ................................................................ 19 Metodyki zarządzania ryzykiem ..................................................................................... 32 Rozdziaä 2. Zasady zarzñdzania ryzykiem w organizacji ...................................... 37 Zarządzanie ryzykiem na poziomie strategicznym ......................................................... 37 Zarządzanie ryzykiem w programach ............................................................................. 40 Zarządzanie ryzykiem w projektach ............................................................................... 42 Zarządzanie ryzykiem operacyjnym ............................................................................... 44 Zarządzanie bezpieczeĔstwem i utrzymaniem ciągáoĞci biznesu .................................... 46 Rozdziaä 3. Proces zarzñdzania ryzykiem w projektach ...................................... 59 Opis cyklu zarządzania ryzykiem ................................................................................... 59 Definiowanie polityki zarządzania ryzykiem ................................................................. 60 Role i zakresy odpowiedzialnoĞci ............................................................................ 61 Opis procesu i modelu zarządzania ryzykiem .......................................................... 64 Poziom akceptacji ryzyka i procedury eskalacji ....................................................... 64 OdnoĞniki do innych poziomów polityki zarządzania ryzykiem .............................. 65 Identyfikacja czynników ryzyka ..................................................................................... 66 WejĞcia procesu identyfikacji ................................................................................... 68 WyjĞcia procesu identyfikacji .................................................................................. 69 Techniki stosowane do identyfikacji ryzyka ............................................................ 69 CzynnoĞci procesu identyfikacji ............................................................................... 70 Ocena ryzyka .................................................................................................................. 71 WejĞcia procesu oceny ryzyka ................................................................................. 71 WyjĞcia procesu oceny ryzyka ................................................................................. 72 Techniki stosowane do oceny ryzyka ....................................................................... 72 CzynnoĞci procesu oceny ryzyka ............................................................................. 73 OkreĞlenie i wybór reakcji na ryzyko ............................................................................. 74 WejĞcia procesu okreĞlenia i wyboru reakcji na ryzyko ............................................... 74 WyjĞcia procesu okreĞlenia i wyboru reakcji na ryzyko .............................................. 74 Techniki stosowane do okreĞlenia i wyboru reakcji na ryzyko ................................ 76 CzynnoĞci procesu okreĞlenia i wyboru reakcji na ryzyko ....................................... 76 4 Zarzñdzanie ryzykiem w projektach informatycznych. Teoria i praktyka Planowanie reakcji na ryzyko ......................................................................................... 77 WejĞcia procesu planowania reakcji na ryzyko ........................................................ 77 WyjĞcia procesu planowania reakcji na ryzyko ........................................................ 77 Techniki stosowane do planowania reakcji na ryzyko .............................................. 78 CzynnoĞci procesu planowania reakcji na ryzyko .................................................... 78 Monitorowanie i sterowanie ryzykiem ........................................................................... 78 WejĞcia procesu monitorowania i sterowania ryzykiem ............................................... 79 WyjĞcia procesu monitorowania i sterowania ryzykiem ............................................... 79 Techniki stosowane do monitorowania i sterowania ryzykiem ................................ 80 CzynnoĞci procesu monitorowania i sterowania ryzykiem ....................................... 80 Rozdziaä 4. Ryzyko uruchomienia projektu ........................................................ 83 Strategia zarządzania portfelem projektów ..................................................................... 83 Uzasadnienie biznesowe i analiza ekonomiczna wartoĞci projektu ..................................... 86 NiepewnoĞü uzasadnienia biznesowego w procesie decyzyjnym uruchamiania projektu ..... 91 Rozdziaä 5. Praktyka zarzñdzania ryzykiem ........................................................ 97 Czynniki krytyczne zarządzania ryzykiem ..................................................................... 97 Wybrane techniki analizy ryzyka ................................................................................. 102 Listy kontrolne ....................................................................................................... 103 Sesje analityczne, burze mózgów ........................................................................... 113 Profile ryzyka ......................................................................................................... 118 Metody eksperckie ................................................................................................. 123 Analiza zaáoĪeĔ ...................................................................................................... 127 Drzewa decyzyjne .................................................................................................. 129 Symulacja Monte Carlo .......................................................................................... 134 Analiza wraĪliwoĞci ............................................................................................... 139 Techniki sieciowe ................................................................................................... 142 Pozostaáe metody diagramowe ............................................................................... 148 Zarządzanie ryzykiem w przykáadowym projekcie ...................................................... 152 Opis scenariusza ..................................................................................................... 152 Uruchomienie projektu — wstĊpna analiza ryzyka ................................................ 154 Analiza ryzyka projektu informatycznego .............................................................. 161 IloĞciowa ocena ryzyka — dobór technik .............................................................. 168 Monitorowanie i sterowanie ryzykiem w trakcie realizacji projektu ...................... 172 Zamykanie projektu — przekazanie wyników do dziaáalnoĞci operacyjnej ........... 178 BáĊdy w zarządzaniu ryzykiem ..................................................................................... 179 BáĊdy przy ustalaniu i egzekwowaniu polityki zarządzania ryzykiem ................... 180 BáĊdy w procesie identyfikacji czynników ryzyka ................................................. 180 BáĊdy przy szacowaniu ryzyka ............................................................................... 183 BáĊdy przy identyfikacji i doborze akcji przeciwdziaáających ............................... 184 BáĊdy w trakcie monitorowania ryzyka .................................................................. 185 BáĊdy przy zamykaniu projektu .............................................................................. 186 Dodatek A Podstawy teorii informacji i rachunku prawdopodobieþstwa ............ 187 Dodatek B Przykäadowe szablony dokumentów wspierajñcych zarzñdzanie ryzykiem .............................................. 195 Uzasadnienie Biznesowe .............................................................................................. 195 Przyczyny uruchomienia projektu .......................................................................... 195 Spodziewana zmiana biznesowa, którą projekt ma wywoáaü ................................. 196 Oczekiwane rezultaty (wyniki) ............................................................................... 196 Warianty moĪliwych rozwiązaĔ ............................................................................. 196 Spodziewane korzyĞci ............................................................................................ 196 Spis treĈci 5 Podstawowe parametry projektu: budĪet i ramy czasowe ...................................... 196 Gáówne czynniki ryzyka biznesowego ................................................................... 196 Ogólna ocena wartoĞci projektu ............................................................................. 196 Rejestr Ryzyka ............................................................................................................. 197 Rejestr ZagadnieĔ ......................................................................................................... 198 Dokument Otwarcia ...................................................................................................... 199 Kontekst projektu ................................................................................................... 199 Definicja projektu ................................................................................................... 199 Formuáa realizacji ................................................................................................... 199 Gáówne parametry projektu .................................................................................... 199 Pierwotna wersja Uzasadnienia Biznesowego ........................................................ 199 Pierwotna wersja Planu Projektu ............................................................................ 199 Pierwotna wersja Rejestru Ryzyka ......................................................................... 200 Plan jakoĞci ............................................................................................................ 200 Struktura organizacyjna projektu ............................................................................ 200 Plan komunikacji .................................................................................................... 200 Raport Statusu Projektu ................................................................................................ 201 Data ........................................................................................................................ 201 Okres sprawozdawczy ............................................................................................ 201 Status budĪetu ........................................................................................................ 201 Status harmonogramu ............................................................................................. 201 Produkty ukoĔczone w okresie sprawozdawczym ................................................. 201 BieĪące lub potencjalne problemy i aktualizacja ryzyka ........................................ 201 Produkty, które mają zostaü ukoĔczone w nastĊpnym okresie ............................... 201 Status zagadnieĔ projektowych .............................................................................. 202 Wpáyw zmian na harmonogram i budĪet ................................................................ 202 Raport o Sytuacji Nadzwyczajnej ................................................................................. 203 Opis przyczyn odchyleĔ od planu .......................................................................... 203 Konsekwencje odchyleĔ ......................................................................................... 203 DostĊpne opcje ....................................................................................................... 203 Wpáyw poszczególnych opcji na: Uzasadnienie Biznesowe, ryzyka, tolerancje projektu i etapu .................................................................................... 203 Zalecenia kierownika projektu ............................................................................... 203 Rejestr DoĞwiadczeĔ .................................................................................................... 204 Zalecenia DziaáaĔ Poprojektowych .............................................................................. 205 Generalne zalecenia dotyczące wáaĞciwej eksploatacji produktów projektu ............. 205 Lista niewytworzonych w projekcie produktów ..................................................... 205 OdstĊpstwa od specyfikacji wymagaĔ dostarczonych produktów .......................... 205 ĩądania zmian niezaimplementowane w ramach projektu ..................................... 205 Zidentyfikowane ryzyka, które mogą mieü wpáyw na produkty w trakcie eksploatacji ........................................................................................... 205 Zidentyfikowane akcje dotyczące dodatkowych produktów .................................. 206 CzynnoĞci, które muszą byü podjĊte przed przekazaniem produktu do programu lub innych projektów ...................................................................... 206 Bibliografia .................................................................................. 207 Skorowidz .................................................................................... 211 Rozdziaä 5. Praktyka zarzñdzania ryzykiem Czynniki krytyczne zarzñdzania ryzykiem PodjĊcie projektu, który ma duĪe znaczenie dla organizacji, jest zazwyczaj poprzedzone analizą strategiczną. Celem takiej analizy jest przede wszystkim stwierdzenie, jaka zmiana biznesowa jest niezbĊdna i czy dany projekt jest w stanie ją wprowadziü. Wynikiem takiej analizy jest teĪ ustalenie priorytetów wzglĊdem innych projektów, a takĪe zdefiniowanie odpowiednich relacji do zadaĔ operacyjnych przedsiĊbiorstwa. WĞród wielu metod stoso- wanych do celu wyznaczenia strategii jedną z popularniejszych jest analiza pola siá autor- stwa Kurta Lewina, sáuĪąca do badania uwarunkowaĔ zmian organizacyjnych. Czynniki ksztaátujące zmianĊ pochodzą z zewnątrz lub wewnątrz organizacji i mogą jej sprzyjaü bądĨ nie. Uproszczoną wersją tej metody jest analiza SWOT (Strengths — Weaknesses — Opportunities — Threats), która polega na badaniu silnych i sáabych stron organizacji oraz szans i zagroĪeĔ w otoczeniu biznesowym. Porównanie potencjaáu organizacji ze Ğrodowiskiem pozwala na okreĞlenie jej pozycji strategicznej i jest podstawą do zde- finiowania nowej lub zmodyfikowania istniejącej strategii. Analiza powinna skupiaü siĊ na wyodrĊbnieniu czynników kluczowych, które mogą mieü decydujący wpáyw na przy- száoĞü organizacji. Są to uwarunkowania, fakty, zjawiska, które powinny byü w szczególny sposób wyodrĊbnione, a nastĊpnie kontrolowane w trakcie realizacji zmiany. Czynniki te, zwane krytycznymi czynnikami sukcesu, moĪemy odnosiü do caáej zmiany biznesowej, lecz równieĪ do pojedynczych projektów. Czynników tych nie naleĪy myliü z ryzykiem, gdyĪ nie są one charakteryzowane przez prawdopodobieĔstwo wystąpienia; z czynnikami krytycznymi sukcesu musimy siĊ z caáą pewnoĞcią zmierzyü i zapewniü, Īe nie wpáyną one negatywnie na przedsiĊwziĊcie. Jakkolwiek rozpatrując czynniki krytyczne, zazwyczaj ma siĊ na myĞli sukces zmiany biznesowej, projektu lub programu, to moĪna równieĪ zidentyfikowaü takie, które mają istotne znaczenie dla jednego z obszarów zarządzania — dla zarządzania ryzykiem. Z pewnoĞcią wiĊkszoĞü z tych czynników bĊdzie równieĪ istotna dla innych elementów 98 Zarzñdzanie ryzykiem w projektach informatycznych. Teoria i praktyka zarządzania: uzasadnienia biznesowego, sterowania jakoĞcią, zmianami. Przed zidentyfi- kowaniem krytycznych czynników zarządzania ryzykiem naleĪy wytworzyü sobie wizjĊ projektu z wyidealizowanym sposobem zarządzania, a nastĊpnie wyodrĊbniü takie uwa- runkowania i fakty, które w rzeczywistych projektach powodują najpowaĪniejsze odejĞcie od tego ideaáu. Jest to teĪ pewnego rodzaju „obraz sukcesu” w sferze zarządzania. PoniĪsza lista obszarów, w których wystĊpują czynniki krytyczne sukcesu zarządzania ryzykiem, dotyczy nie tylko projektów informatycznych, lecz takĪe uwzglĊdnia specyfikĊ projektów, w których zagadnienia teleinformatyczne mają zasadnicze znaczenie. 1. Powiązanie misji, strategii i celów strategicznych organizacji z celami projektu. Projekty, zwáaszcza o charakterze informatycznym, traktowane są czĊsto w oderwaniu od rzeczywistych celów strategicznych. UkoĔczenie projektu staje siĊ celem samym w sobie, nie uwzglĊdnia faktu, Īe projekt jest tylko drogą do wprowadzenia zmiany biznesowej. Szczególne znaczenie ma to dla portfela projektów, gdzie nie są w wyraĨny sposób ustanowione zasady przydzielania priorytetów, a kaĪdy projekt traktowany jest przez jego wáaĞcicieli jako jedyny, najwaĪniejszy. W tej sytuacji zarządzanie ryzykiem w projektach nie bierze pod uwagĊ zgodnoĞci celów ze strategią, a czynniki ryzyka związane z niewypeánieniem przez projekt misji nie są identyfikowane. 2. Jasny obraz sukcesu projektu. Zarówno przy rozpatrywaniu zjawisk dla projektu negatywnych, jak i pozytywnych istotne jest okreĞlenie, co bĊdzie prawdziwym sukcesem projektu. W przypadku projektów informatycznych czĊsto za sukces uwaĪa siĊ wytworzenie sprawnie dziaáającego oprogramowania lub udaną implementacjĊ systemu, czasem dodatkowo zweryfikowaną etapem pilotaĪowego wdroĪenia. Tymczasem rzeczywisty sukces projektów, nie tylko informatycznych, polega na uzyskaniu korzyĞci biznesowych, które mogą nastąpiü dopiero wiele miesiĊcy po zamkniĊciu projektu. Niemniej jednak zarządzanie ryzykiem naleĪy odnosiü do osiągniĊcia wszystkich celów poĞrednich, z których najwaĪniejsze są wáaĞnie te związane z uzyskaniem produktów o wymaganej jakoĞci. Pozostaáe parametry mogą mieü róĪną wagĊ: dla niektórych projektów dotrzymanie terminu zakoĔczenia jest absolutnie krytyczne, dla innych waĪniejsze jest oszczĊdne gospodarowanie budĪetem albo takie zarządzanie zasobami, które w Īaden sposób nie zakáóca dziaáalnoĞci operacyjnej organizacji. Celem poĞrednim, prowadzącym do sukcesu biznesowego, jest teĪ odpowiednie przygotowanie przyszáej eksploatacji produktów projektu, czyli zapewnienie obsáugi serwisowej, przeszkolenie uĪytkowników systemów, opracowanie dokumentacji. Obraz sukcesu projektu powinien zostaü tak zdefiniowany, a nastĊpnie rozpowszechniony wĞród uczestników projektu, aby nie byáo Īadnych wątpliwoĞci, jakie kryteria odnoszą siĊ do poszczególnych parametrów projektu i jakie są priorytety w osiągniĊciu celów poĞrednich. Dla zewnĊtrznego dostawcy cel biznesowy realizowany jest przez otrzymanie odpowiedniej wartoĞci pieniĊĪnej za wytworzone produkty lub dostarczone usáugi. Niemniej obraz sukcesu projektu ze strony dostawcy teĪ musi braü pod uwagĊ okres eksploatacji produktów, czyli czas po zamkniĊciu projektu. WiąĪe siĊ to nie tylko z ewentualnymi dodatkowymi kosztami obsáugi gwarancyjnej, lecz równieĪ, a moĪe przede wszystkim, z utrzymaniem prestiĪu, który przynosi dáugofalowe korzyĞci biznesowe. Rozdziaä 5. i Praktyka zarzñdzania ryzykiem 99 3. Struktury organizacyjne. Pierwszym warunkiem sukcesu projektu jest wáaĞciwy wybór struktury organizacyjnej projektu oraz mianowanie odpowiednich osób do sprawowania poszczególnych ról w tej strukturze. Szczególnie istotne jest zrozumienie, Īe struktura ta jest w pewnym sensie autonomiczna i nie podlega rutynowym zasadom dziaáania struktur liniowych (funkcjonalnych). Wprawdzie zagroĪenia dla projektów czĊsto zazĊbiają siĊ z problemami wystĊpującymi w dziaáalnoĞci operacyjnej, niemniej jednak zarządzanie ryzykiem w projektach podlega nieco innym prawom niĪ zarządzanie ryzykiem operacyjnym. Czáonkowie komitetów sterujących, zazwyczaj peániący na co dzieĔ funkcje w zarządzie organizacji, powinni zdawaü sobie sprawĊ, Īe role peánione w projektach wiąĪą siĊ z innymi zakresami obowiązków i odpowiedzialnoĞci. Istotne jest wiĊc przygotowanie, niekoniecznie w postaci bardzo sformalizowanych dokumentów, opisu poszczególnych ról w strukturze organizacyjnej projektu. 4. Polityka zarządzania ryzykiem. W wiĊkszych organizacjach polityka zarządzania ryzykiem stanowi element caáej polityki zarządzania i jest odpowiednio udokumentowana. Niemniej nawet wtedy naleĪy upewniü siĊ, czy nie obejmuje ona tylko zagadnieĔ operacyjnych, pomijając specyfikĊ prowadzenia projektów. Polityka zarządzania ryzykiem w projektach powinna obejmowaü przede wszystkim zagadnienia związane z zakresem odpowiedzialnoĞci za ryzyko, czyli odnosiü siĊ do projektowych struktur organizacyjnych, opisanych w punkcie 3. powyĪej. Ponadto powinna proponowaü jednorodne dla danego projektu podejĞcie do ryzyka, rozumiane jako przyjĊcie wybranego modelu jego oceny, przebieg procesu, zasady akceptowania ryzyka, sposób podejmowania decyzji. NajwáaĞciwsze jest przyjĊcie dla caáej organizacji wspólnej polityki zarządzania ryzykiem z opisem ewentualnych rozbieĪnoĞci dla projektów o okreĞlonej specyfice lub skali. 5. ZaangaĪowanie zarządu projektu w zarządzanie ryzykiem. Odpowiednio przygotowane opisy ról w projekcie powinny zasadniczo uregulowaü sprawy związane z odpowiedzialnoĞcią za ryzyko i zasadami podejmowania decyzji. Jednak istotne jest osobiste nastawienie zarządu projektu, zwáaszcza czáonków komitetu sterującego, do zagadnieĔ ryzyka. Peána ĞwiadomoĞü, jakie są korzyĞci z zarządzania ryzykiem, powinna owocowaü zaangaĪowaniem w ten obszar zarządzania, a takĪe przyjĊciem do wiadomoĞci implikacji z nim związanych. Zarządzanie ryzykiem kosztuje, ale zwykáo siĊ mawiaü, Īe brak zarządzania nim kosztuje jeszcze wiĊcej. Komitet sterujący powinien promowaü zarządzanie ryzykiem i wspieraü — zwáaszcza kierownika — we wszystkich dziaáaniach przeciwdziaáających moĪliwym zagroĪeniom. RównieĪ istotne jest przyjĊcie na siebie przez komitet sterujący odpowiedzialnoĞci za monitorowanie pewnych zjawisk, które mogą byü trudno dostĊpne dla innych uczestników projektu; dotyczy to zwáaszcza obszarów polityki, w tym polityki biznesowej, rynku, finansów organizacji i zagadnieĔ prawnych. 6. Metodyka zarządzania ryzykiem. Wybór formalnej metodyki prowadzenia projektu jest równoznaczny z wyborem sposobu zarządzania ryzykiem. Dla projektów prowadzonych mniej formalnie, w oparciu o wáasne procedury, istotne jest uzgodnienie zasad podejĞcia do ryzyka 100 Zarzñdzanie ryzykiem w projektach informatycznych. Teoria i praktyka i zdefiniowanie zasad jego obsáugi. Nie musi to byü szczegóáowo opisany proces zarządzania, lecz konieczne jest przede wszystkim okreĞlenie zakresu odpowiedzialnoĞci za poszczególne czynnoĞci objĊte cyklem obsáugi ryzyka, zwáaszcza w zakresie decyzji o stosowaniu Ğrodków zaradczych. 7. Wiedza o zarządzaniu ryzykiem wĞród udziaáowców projektu. W projektach informatycznych widaü ze szczególną ostroĞcią, jak istotna jest peána ĞwiadomoĞü wszystkich uczestników projektu o zagadnieniach związanych z ryzykiem. Wielkie znaczenia ma udziaá czáonków zespoáów realizacyjnych w sesjach identyfikowania i oceny ryzyka. CzĊsto jedyną osobą, która moĪe wáaĞciwie oszacowaü zagroĪenia wynikające z niepewnoĞci rezultatów niektórych prac, jest wáaĞnie ich wykonawca. JeĞli nawet te oceny obciąĪone są duĪą dozą subiektywizmu, to zastosowanie odpowiednich technik zwiĊksza ich wiarygodnoĞü i staje siĊ podstawą do stosowania optymalnych akcji przeciwdziaáających. 8. Przywództwo, osoba kierownika projektu. W duĪym skrócie odpowiedzialnoĞü kierownika polega na tym, aby projekt przez niego prowadzony w okreĞlonym czasie wytworzyá produkty, które bĊdą w stanie doprowadziü do osiągniĊcia korzyĞci biznesowych, i aby utrzymany zostaá przewidziany na to budĪet. Wszystko, co moĪe temu zagroziü, jest przedmiotem dziaáaĔ kierownika projektu, a z tego wynika odpowiedzialnoĞü za wáaĞciwe zarządzanie ryzykiem. Kierownik musi sobie zdawaü sprawĊ, Īe dotyczą go teĪ zjawiska niezaleĪne od niego, czĊsto trudne do przewidzenia, ale mające wpáyw na projekt. Kierownik powinien umotywowaü zespoáy projektowe do aktywnego uczestnictwa w procesach zarządzania, wyznaczyü odpowiednie role (np. wáaĞcicieli poszczególnych czynników ryzyka), a przede wszystkim wáączyü do planów wszystkie czynnoĞci związane z analizą ryzyka, a póĨniej jego monitorowaniem i wykonywaniem odpowiednich akcji. Jednym z podstawowych narzĊdzi, którymi kierownik powinien posáugiwaü siĊ w trakcie prowadzenia projektu, jest Rejestr Ryzyka. 9. Wspóápraca stron w zarządzaniu ryzykiem. Nawet jeĞli realizowany jest projekt wewnĊtrzny, gdzie wszystkie strony naleĪą do jednej organizacji, biorą w nim udziaá róĪne strony interesu. Naturalny podziaá na klientów i dostawców powinien byü uzupeániony o przyszáych uĪytkowników systemów, niekoniecznie naleĪących do organizacji klienta (przykáadowo: ministerstwo moĪe zleciü wykonanie systemu informatycznego dla jakiegoĞ urzĊdu, który bĊdzie wyáącznym jego uĪytkownikiem). KaĪda ze stron oczekuje od projektu nieco innych korzyĞci, w związku z czym inaczej rozumie zagadnienia ryzyka. Dla klienta istotne jest przede wszystkim ryzyko biznesowe, czyli zagroĪenia w osiągniĊciu planowanych korzyĞci. UĪytkownik ma na uwadze przede wszystkim jakoĞü produktów projektu, której niedotrzymanie utrudni lub uniemoĪliwi sensowne ich uĪytkowanie. Dostawca musi dbaü o swoje uzasadnienie biznesowe, które bĊdzie moĪliwe do wypeánienia, jeĞli produkty o wymaganej jakoĞci nie tylko uda siĊ wytworzyü, ale gdy proces wytworzenia nie bĊdzie zbyt kosztowny. Wszystkie moĪliwe problemy techniczne oraz związane z pozyskaniem odpowiednich zasobów mogą stworzyü takie zagroĪenie dla dostawcy. Istotne jest, aby wszystkie strony w projekcie zdaáy sobie sprawĊ, Rozdziaä 5. i Praktyka zarzñdzania ryzykiem 101 Īe zarządzanie ryzykiem powinno byü sprawą wspólną, do czego pierwszym krokiem jest wáaĞciwa wymiana informacji. Przy przyjmowaniu zleceĔ dostawcy powinni zgáaszaü swoje wątpliwoĞci co do terminowego wykonania prac i uzyskania wymaganej jakoĞci. Nie jest to áatwe, zwáaszcza Īe wątpliwoĞci te mogą rzutowaü na treĞü kontraktów. Zalecenie wspólnych dziaáaĔ przy identyfikowaniu i ocenie czynników ryzyka, wystĊpujących na styku dostawcy z klientem, powinno zaowocowaü sprawniejszym prowadzeniem projektu i áatwiej doprowadziü do jego sukcesu. 10. Wspóápraca udziaáowców projektu z dziaáami zajmującymi siĊ bezpieczeĔstwem informatycznym. WdroĪenie nowego systemu lub modyfikacja starego wiąĪe siĊ w organizacji w szczególny sposób z zagadnieniami bezpieczeĔstwa informacyjnego. Przede wszystkim produkty, powstaáe w wyniku projektu, powinny byü bezpieczne w eksploatacji, równieĪ w sensie bezpieczeĔstwa danych, na których bĊdą operowaü. PoniewaĪ we wspóáczesnych organizacjach wiĊkszoĞü dziaáalnoĞci operacyjnej polega na sprawnym i bezpiecznym dziaáaniu systemów informatycznych, Ĩle wykonany lub niewáaĞciwie wdroĪony system moĪe zagroziü ciągáym procesom gospodarczym, skáadającym siĊ na operacje biznesowe. Ocena zaimplementowanego systemu przez odpowiednie departamenty prowadzi do zakwalifikowania go jako nadający siĊ do eksploatacji i warunkuje zakoĔczenie procesu zamykania projektu. W związku z tym nadzwyczaj istotna staje siĊ wspóápraca tych departamentów z uczestnikami projektu, zwáaszcza ze stroną dostawców. 11. Praktyka zarządzania ryzykiem w projektach. Nawet w przypadkach, gdy wĞród udziaáowców projektu istnieje peána ĞwiadomoĞü koniecznoĞci zarządzania ryzykiem oraz zostaáa przyjĊta formalna metoda, brak doĞwiadczenia utrudnia wykorzystanie wiedzy teoretycznej. Rygorystyczne przestrzeganie wszystkich elementów metodyki prowadzi do biurokracji, a w efekcie do wzrostu kosztów zarządzania i trudnoĞci w dotrzymaniu terminów prac. W rezultacie prowadzi to do zniechĊcenia i utraty zaufania do formalnych metod zarządzania. Utrzymanie formalnych ram zarządzania ryzykiem w rozsądnych granicach, bez przesadnej biurokracji, jest waĪnym elementem wpáywającym na sprawne i bezpieczne prowadzenie projektu. W przypadkach gdy zarząd projektu i uczestnicy nie mają wystarczającego doĞwiadczenia, porady ekspertów stanowią nieocenioną wartoĞü. 12. Procesy identyfikacji i oceny ryzyka. Podstawą wáaĞciwego zarządzania ryzykiem są pierwsze procesy cyklu: identyfikacja i ocena. Bagatelizowanie zagroĪeĔ, zwáaszcza we wstĊpnej fazie uruchamiania projektu, prowadzi do podejmowania nieopáacalnych przedsiĊwziĊü, a w trakcie realizacji prac powoduje szereg dodatkowych komplikacji. Wnikliwie przeprowadzona analiza ryzyka umoĪliwia proaktywne zarządzanie projektem i unikniĊcie wielu problemów, które mają miejsce, gdy dany czynnik ryzyka siĊ materializuje. 102 Zarzñdzanie ryzykiem w projektach informatycznych. Teoria i praktyka 13. Identyfikacja i dobór akcji przeciwdziaáających. W wyniku analizy ryzyka powstaje lista dodatkowych czynnoĞci, związanych z zapobieganiem bądĨ redukcją ryzyka. Generowane są nowe koszty, zwáaszcza w przypadkach koniecznoĞci tworzenia planów rezerwowych lub wykupienia ubezpieczeĔ. Podejmowanie decyzji o wyborze konkretnych przeciwdziaáaĔ powinno odbywaü siĊ w oparciu o bilans kosztów tych akcji i ich przewidywanej skutecznoĞci. Decyzje te mogą mieü duĪy wpáyw na budĪet caáego projektu, wiĊc przynajmniej niektóre z nich powinny byü podejmowane na wyĪszym poziomie — przez komitet sterujący. 14. Monitorowanie i analizowanie zagadnieĔ projektowych. BieĪąca obsáuga ryzyka równieĪ stanowi dodatkowy koszt dla projektu — są to czynnoĞci obserwacji zagadnieĔ projektowych i ich analiza pod kątem moĪliwoĞci pojawienia siĊ nowych czynników ryzyka lub zmiany oceny czynników wczeĞniej zidentyfikowanych. Metodyki narzucają pewne minima związane z pracocháonnoĞcią niezbĊdną dla sensownej bieĪącej obsáugi ryzyka, lecz iloĞü pracy poĞwiĊcana na monitorowanie zagadnieĔ bĊdzie róĪna dla kaĪdego projektu. Kluczem do sprawnego monitorowania ryzyka jest przede wszystkim sensowne przypisanie wáaĞcicieli do poszczególnych czynników, a takĪe doĞwiadczenie kierownika projektu. 15. Dokumentowanie doĞwiadczeĔ związanych z ryzykiem. Jednym z najwaĪniejszych elementów Raportu o DoĞwiadczeniach jest ocena procesów zarządczych, w tym procesu zarządzania ryzykiem, a takĪe ocena dokáadnoĞci szacunków prawdopodobieĔstwa i wpáywu poszczególnych czynników na projekt. W dokumencie tym, powstającym przy zamykaniu projektu, powinno siĊ teĪ zapisywaü wszystkie czynniki, których nie udaáo siĊ zidentyfikowaü podczas analizy wstĊpnej, a które zmaterializowaáy siĊ w trakcie realizacji projektu. Raporty o DoĞwiadczeniach są nieocenioną pomocą dla kierowników podobnych projektów, mogą siĊ przyczyniü do usprawnienia procesów zarządzania i przez to zwiĊkszyü szanse na sukces kolejnych przedsiĊwziĊü. Przy uruchamianiu projektu warto poĞwiĊciü czas na rozpatrzenie wymienionych powyĪej obszarów, w których istnieją zagroĪenia niewáaĞciwej obsáugi ryzyka. Dla kaĪdego pro- jektu czynniki krytyczne powinny byü zidentyfikowane w jak najwczeĞniejszej jego fazie, gdyĪ wáaĞciwe zarządzanie ryzykiem jest jednym z waĪniejszych warunków sprawnego prowadzenia projektu. Wybrane techniki analizy ryzyka Zaproponowane w niniejszym rozdziale techniki analizy ryzyka stanowią caákowicie ar- bitralny wybór z bardzo szerokiego spektrum metod i technik, stosowanych w zarządzaniu ryzykiem. Przy ich selekcji wziĊto pod uwagĊ nie tylko ich popularnoĞü i dostĊpnoĞü, lecz przede wszystkim áatwoĞü stosowania równieĪ w niewielkich projektach. Omawianie kaĪdej z technik rozpoczynają uwagi na temat obszaru zastosowaĔ i moĪliwoĞci implementacji w projektach informatycznych. Rozdziaä 5. i Praktyka zarzñdzania ryzykiem 103 Listy kontrolne Jedną z najpowszechniej stosowanych, áatwych w uĪyciu, a zarazem bardzo skutecznych technik, jest metoda list kontrolnych. Wspiera ona gáównie proces identyfikacji czynników ryzyka, choü moĪe teĪ byü pomocna w trakcie oceny czynników oraz przy identyfikacji i wyborze Ğrodków przeciwdziaáających. Jakkolwiek stosowana jest przede wszystkim w trakcie wstĊpnej analizy, powinna byü wykorzystywana równieĪ w nastĊpnych fazach projektu: przy zatwierdzaniu uruchomienia kolejnych etapów, w trakcie okresowych ocen, a nawet przy zamykaniu projektu. Ten ostatni przypadek ma na celu okreĞlenie zagroĪeĔ, które mogą nastąpiü w trakcie eksploatacji produktów projektu, a takĪe ma stanowiü waĪny element listy doĞwiadczeĔ nabytych w czasie caáego cyklu projektu. Technika zakáada, Īe istnieją gotowe do wykorzystania listy kontrolne, w których zgro- madzona jest wiedza o obszarach wystĊpowania ryzyka dla danego projektu, o moĪliwych zdarzeniach i zjawiskach, które mogą mieü wpáyw na projekt. Wprawdzie róĪne instytucje opracowują uniwersalne listy kontrolne lub listy ukierunkowane na dany typ projektu, lecz najwygodniej dla organizacji jest, gdy wypracowaáa ona sobie wáasne wykazy typo- wych czynników uwzglĊdniające nie tylko specyfikĊ prowadzonych w niej projektów, lecz równieĪ uwarunkowania związane ze sposobem dziaáalnoĞci przedsiĊbiorstwa czy instytucji. Wiele czynników ryzyka wynika z otoczenia, w którym funkcjonuje organizacja, a te czynniki z reguáy nie są ujmowane w publikowanych i ogólnie dostĊpnych listach. Istotne jest wiĊc, aby przy planowaniu strategicznym wziąü pod uwagĊ zbieranie i wymianĊ informacji o wystĊpujących w ramach caáej organizacji zagroĪeniach dla prowadzonych w niej projektów. Informacja ta staje siĊ podstawą do opracowania firmowych list kon- trolnych, które powinny podlegaü okresowym przeglądom w szerokim gronie realizato- rów projektów oraz ekspertów. JeĞli jednak organizacja nie dysponuje opracowanymi na wáasne potrzeby listami kontrolnymi lub nie prowadziáa dotąd projektów zarządzanych metodycznie, powinna posáuĪyü siĊ gotowymi listami, najlepiej związanymi z daną branĪą. W projektach informatycznych warto oprzeü siĊ na wiedzy zgromadzonej przez takie organizacje jak wspomniany juĪ Software Engineering Institute (SEI), w którym powstaáy modele dojrzaáoĞci organizacyjnej przedsiĊbiorstw CMM®, a przy wstĊpnym identyfiko- waniu czynników ryzyka wysokiego poziomu — na uniwersalnych listach publikowanych np. przez brytyjską agencjĊ Office of Government Commerce (OGC). Wskazane jest, aby przed rozpoczĊciem projektu uzupeániü listy kontrolne poprzez dopisanie dodatkowych elementów wynikających z dokumentów firmowych, zwáaszcza z Raportów o DoĞwiad- czeniach z poprzednich projektów. W poniĪszych tabelach przedstawione są przykáady list o róĪnej konstrukcji, które mogą byü pomocne w róĪnych fazach cyklu projektu. Lista umieszczona w tabeli 5.1 jest zbudowana z serii pytaĔ, które nie tylko pomagają zidentyfikowaü zagroĪenia, lecz rów- nieĪ, a nawet przede wszystkim, pozwalają na zgrubną ocenĊ poziomu ryzyka caáego projektu. Lista ta nadaje siĊ przede wszystkim do wstĊpnego porównania projektów przy analizie portfela — moĪe staü siĊ podstawą odrzucenia bądĨ przyjĊcia projektów do realizacji, a nastĊpnie do ustalenia ich priorytetów. Jest listą uniwersalną, nadającą siĊ do analizowania projektów róĪnego typu. 104 Zarzñdzanie ryzykiem w projektach informatycznych. Teoria i praktyka Ocena Tabela 5.1. Lista kontrolna wspomagająca wstĊpną ocenĊ ryzyka projektu Id. S.1 S.2 S.3 S.4 S.5 S.6 S.7 S.8 S.9 B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8 E.1 E.2 E.3 E.4 E.5 L.1 L.2 L.3 L.4 L.5 Obszar zagroĔenia, pytanie identyfikujñce Strategia, dojrzaáoĞü organizacji Czy organizacja posiada jasno sprecyzowaną strategiĊ? Czy planowana zmiana biznesowa jest zgodna z gáównymi celami strategicznymi? Czy istnieje powszechne przekonanie, Īe zmiana jest niezbĊdna? Czy okreĞlony jest poziom oddziaáywania zmiany biznesowej na dziaáalnoĞü operacyjną? Czy gáówne krytyczne procesy biznesowe pozostaną nienaruszone przez zmianĊ? Czy zdefiniowany jest zakres zmiany biznesowej, który ma byü zrealizowany przez projekt? Czy organizacja wprowadzaáa juĪ zmianĊ biznesową na podobnym poziomie? Czy procesy biznesowe organizacji są przystosowane do wprowadzenia zmiany? Czy osoby, które bĊdą zaangaĪowane w zarządzanie strategiczne projektu, braáy juĪ udziaá w podobnym przedsiĊwziĊciu? Otoczenie biznesowe i polityczne Czy sytuacja polityczna jest stabilna? Czy sytuacja gospodarcza jest stabilna? Czy Ğrodki finansowe są áatwe do pozyskania? Czy znany jest wpáyw otoczenia biznesowego na zmianĊ w organizacji? Czy proces wprowadzenia zmiany jest odporny na dziaáania konkurencji? Czy opinia publiczna i media są przychylne? Czy kondycja kluczowych kontrahentów i partnerów jest stabilna? Czy okreĞlony jest poziom oddziaáywania zmiany biznesowej na dziaáalnoĞü operacyjną? Sytuacja ekonomiczna/komercyjna organizacji Czy sytuacja rynkowa organizacji jest stabilna? Czy stosunki wáasnoĞciowe w organizacji są stabilne? Czy organizacja posiada zabezpieczony na okres prowadzenia projektu kapitaá obrotowy? Czy stosunki z partnerami są uregulowane? Czy organizacja moĪe w zakresie pozyskania Ğrodków inwestycyjnych polegaü w duĪym stopniu na wáasnych zasobach finansowych? Legislacja, przepisy Czy sytuacja legislacyjna jest stabilna? Czy dziaáalnoĞü organizacji jest niewraĪliwa na zmiany przepisów? Czy organizacja posiada prawa autorskie do tworzonych przez nią produktów? Czy kontrakty są zgodne z bieĪącymi warunkami prawnymi? Czy zawarte umowy są zgodne z prawem miĊdzynarodowym? 105 Ocena Rozdziaä 5. i Praktyka zarzñdzania ryzykiem Tabela 5.1. Lista kontrolna wspomagająca wstĊpną ocenĊ ryzyka projektu — ciąg dalszy Id. D.1 D.2 D.3 D.4 D.5 D.6 O.1 O.2 O.3 O.4 O.5 O.6 O.7 O.8 O.9 Obszar zagroĔenia, pytanie identyfikujñce Dostawcy Czy organizacja polega na sprawdzonych, wiarygodnych dostawcach? Czy podpisane są dáugoterminowe umowy z kluczowymi dostawcami? Czy projekt jest w maáym stopniu uzaleĪniony od pojedynczych dostawców? Czy kluczowi dostawcy posiadają odpowiednie certyfikaty zgodnoĞci z normami? Czy u dostawców funkcjonują systemy zarządzania jakoĞcią? Czy poziom partnerstwa z dostawcami pozwala na wáączenie ich w struktury zarządzania projektem? Organizacja Czy polityka korporacyjna uwzglĊdnia funkcjonowanie w jej ramach organizacyjnych struktur projektowych? Czy wdroĪona jest i stosowana jako obowiązująca metodyka zarządzania projektem? Czy udziaáowcy projektu znają jego cele i produkty? Czy zostaá mianowany przewodniczący komitetu sterującego (sponsor)? Czy przewodniczący komitetu sterującego jest aktywnie zaangaĪowany w doprowadzenie projektu do sukcesu? Czy do komitetu sterującego zostali wáączeni reprezentanci wszystkich stron (klienta, uĪytkowników, dostawców)? Czy czáonkowie komitetu sterującego znają swoje zadania i przyjmują odpowiedzialnoĞü za ich realizacjĊ? Czy proces decyzyjny jest jasno okreĞlony i znany udziaáowcom projektu? Czy zarząd projektu posiada wystarczające kompetencje do zabezpieczenia zasobów projektu? O.10 Czy jest zabezpieczone wsparcie operacyjne projektu? O.11 Czy uruchomione są mechanizmy komunikacji wewnątrz projektu oraz projektu z otoczeniem? O.12 Czy zarząd projektu dysponuje swoim czasem adekwatnie do skali i potrzeb projektu? O.13 Czy istnieje sprawdzony sposób rozwiązywania konfliktów? Czynnik ludzki Czy kierownik projektu ma profesjonalne przygotowanie do prowadzenia projektu? Czy kierownik projektu ma cechy charakterologiczne odpowiednie do zarządzania ludĨmi? Czy zespóá projektowy jest stabilny? Czy uczestnicy mają doĞwiadczenie w pracy w projektach? Czy w zespoáach projektowych istnieje ĞwiadomoĞü celów projektu i zgoda co do sposobu ich osiągniĊcia? Czy ewentualne konflikty wĞród czáonków zespoáów są zidentyfikowane i zaáagodzone? Czy czáonkowie zespoáów są emocjonalnie zaangaĪowani w osiągniĊcie sukcesu projektu? C.1 C.2 C.3 C.4 C.5 C.6 C.7 106 Zarzñdzanie ryzykiem w projektach informatycznych. Teoria i praktyka Ocena Tabela 5.1. Lista kontrolna wspomagająca wstĊpną ocenĊ ryzyka projektu — ciąg dalszy Id. Z.1 Z.2 Z.3 Z.4 Z.5 Z.6 Z.7 Z.8 P.1 P.2 P.3 P.4 P.5 P.6 P.7 P.8 W.1 W.2 W.3 W.4 W.5 W.6 W.7 T.1 T.2 T.3 T.4 Obszar zagroĔenia, pytanie identyfikujñce Zarządzanie projektem Czy do prowadzenia projektu jest stosowana formalna metodyka? Czy uczestnicy projektu zaznajomieni są z podstawowymi zasadami metodycznego zarządzania projektem? Czy poziom formalnych procedur zostaá dopasowany do skali i wagi projektu? Czy zostaá uzgodniony sposób postĊpowania w sytuacjach nadzwyczajnych? Czy projekt korzysta z ustandaryzowanych, korporacyjnych metod zarządzania jakoĞcią? Czy są wdroĪone i rozpowszechnione wĞród uczestników procedury zarządzania konfiguracją produktów i zmianami? Czy ustanowione są zasady obiegu podstawowych dokumentów projektowych? Czy cykl Īycia projektu jest jasno zdefiniowany, a zasady odbioru produktów uzgodnione miĊdzy stronami? Parametry i ograniczenia projektu Czy zakres, budĪet i termin zakoĔczenia projektu są zatwierdzone? Czy zatwierdzone parametry czasowe i kosztowe są realistyczne? Czy szacowanie parametrów projektu wsparte jest zastosowaniem sprawdzonych technik i bazuje na dokumentacjach z poprzednich projektów? Czy uzgodnione zostaáy tolerancje parametrów projektu? Czy zakres (produkty) projektu ma (mają) charakter stabilny? Czy zarząd projektu, a w szczególnoĞci jego kierownik, jest Ğwiadomy związków pomiĊdzy definicją parametrów projektu a jego uzasadnieniem biznesowym? Czy ograniczenia zewnĊtrzne są znane i kontrolowane? Czy ewentualne przekroczenie parametrów projektu ma maáy wpáyw na dziaáalnoĞü caáej organizacji? Wspóápraca dostawców z uĪytkownikami Czy specyfikacja produktów projektu zostaáa uzgodniona miĊdzy stronami? Czy istnieje mniej lub bardziej formalny sposób zarządzania wymaganiami? Czy zostaáy uzgodnione kryteria akceptacji produktów projektu? Czy zarządzanie zmianami jest formalnie uzgodnione miĊdzy stronami? Czy uĪytkownicy uczestniczą (mają uczestniczyü) w przeglądach jakoĞci produktów? Czy zasady przekazywania produktów do eksploatacji są uzgodnione? Czy zostaáy okreĞlone kamienie milowe związane z odbiorami gáównych poĞrednich produktów? Zagadnienia techniczne Czy projekt wykorzystuje znane i sprawdzone technologie? Czy liczba dostawców i poddostawców jest rozsądnie ograniczona i kontrolowana? Czy wykonawcy posiadają odpowiednie kompetencje? Czy istniejąca infrastruktura jest wystarczająca do obsáugi nowych produktów? 107 Ocena Rozdziaä 5. i Praktyka zarzñdzania ryzykiem Tabela 5.1. Lista kontrolna wspomagająca wstĊpną ocenĊ ryzyka projektu — ciąg dalszy Id. T.5 T.6 T.7 T.8 T.9 Obszar zagroĔenia, pytanie identyfikujñce Zagadnienia techniczne Czy dostĊpne techniki kontroli jakoĞci są odpowiednie do rodzaju i poziomu technicznego produktów? Czy záoĪonoĞü produktów jest na poziomie dostosowanym do moĪliwoĞci uĪytkowników? Czy narzĊdzia przewidziane do wytwarzania produktów są na odpowiednim poziomie technicznym i niezawodnoĞciowym? Czy sposób rozwiązywania problemów technicznych jest ustalony i rozpowszechniony wĞród zespoáów projektowych? Czy po zamkniĊciu projektu dostarczone produkty bĊdą mogáy byü eksploatowane bez udziaáu wykonawców? Oceny ryzyka projektu moĪna dokonaü na kilka sposobów; najprostszy polega na udziele- niu na poszczególne pytania odpowiedzi „TAK”/„NIE” i obliczeniu procentowego udziaáu odpowiedzi „NIE” w caáej liĞcie — wiĊkszy procent Ğwiadczy o wyĪszym poziomie ryzyka. Bardziej wiarygodną ocenĊ uzyskuje siĊ poprzez stopniowanie odpowiedzi i przypisanie im odpowiednich wartoĞci, np.: 1 Tak Raczej tak 2 Do pewnego stopnia 3 Raczej nie 4 5 Nie WiĊksza wartoĞü sumaryczna Ğwiadczy o wyĪszym poziomie ryzyka projektu. Liczby mogą byü sumowane wedáug poszczególnych obszarów, co staje siĊ podstawą do takich stwier- dzeĔ jak np.: „Projekt jest niezbyt ryzykowny, lecz w dwóch obszarach: wspóápracy z dostawcami oraz uwarunkowaĔ prawnych, poziom ryzyka jest ponadprzeciĊtny”. Nie oznacza to, Īe wysoka wartoĞü ryzyka w pewnym obszarze dyskwalifikuje projekt. Przy- káadem moĪe tu byü pytanie S.5: „Czy gáówne krytyczne procesy biznesowe pozostaną nienaruszone przez zmianĊ?”. CzĊsto projekt zostaje uruchomiony wáaĞnie w celu prze- prowadzenia rewolucyjnej zmiany biznesowej, polegającej na przeprojektowaniu wiĊk- szoĞci procesów biznesowych. Niemniej fakt, Īe jest on nadzwyczaj ryzykowny, powinien byü uĞwiadomiony wszystkim kluczowym udziaáowcom projektu. W takich sytuacjach do sumarycznej oceny ryzyka caáego projektu wskazane jest dodatkowe przyjĊcie wag dla poszczególnych czynników lub caáych obszarów. Niektóre pytania z listy mają charakter bardzo ogólny i wtedy wskazane jest uszczegóáo- wienie pewnych zagadnieĔ. Przykáadowo: pytania B.2 i B.3, czĊĞciowo ze sobą powiązane, mogą sprawiü káopot przy wyborze wáaĞciwej odpowiedzi. Niestabilna sytuacja gospodarcza (B.2) moĪe byü wáaĞnie jednym z impulsów uruchomienia zmiany biznesowej, która to zmiana ma uchroniü organizacjĊ przed wpáywem niestabilnoĞci sytuacji krajowej lub glo- balnej. Z drugiej strony moĪe to utrudniü pozyskanie Ğrodków na realizacjĊ projektu (B.3). 108 Zarzñdzanie ryzykiem w projektach informatycznych. Teoria i praktyka Ma to teĪ pewien związek z punktem E.5, stawiającym pytanie, w jakim stopniu organiza- cja moĪe w zakresie pozyskania Ğrodków inwestycyjnych polegaü na wáasnych zasobach finansowych. Przy identyfikowaniu czynników ryzyka naleĪy rozróĪniü cztery powiązane ze sobą pojĊcia:  obszar (kategoria),  Ĩródáa (przyczyny) ryzyka,  niepewne zdarzenia (zjawiska),  skutki (tych zdarzeĔ lub zjawisk). PojĊcia te czĊsto mylone są ze sobą, czĊsto Ĩródáa ryzyka uznawane są za jego czynniki. Tymczasem czynnikami ryzyka są tylko niepewne zdarzenia (zjawiska) i tylko one pod- legają zarządzaniu. OkreĞlenie obszaru ma pomóc w znalezieniu Ĩródeá ryzyka, które naleĪą do którejĞ z wymienionych w tabeli 5.1 kategorii lub innej, specyficznej dla danego pro- jektu. ħródáa, czyli przyczyny wystĊpowania ryzyka — to po prostu fakty lub okolicznoĞci, które istnieją w projekcie. Przyczyny nie są ryzykiem, poniewaĪ nie wiąĪe siĊ z nimi Īadna niepewnoĞü. Natomiast mogą one (choü nie muszą) spowodowaü wystąpienie ryzyka, które z kolei wywoáa odpowiednie skutki. Listy kontrolne mają róĪne formy: mogą specy- fikowaü tylko obszary, ale zazwyczaj podają równieĪ Ĩródáa ryzyka. Podczas procesu identyfikacji naleĪy stwierdziü, które przyczyny rzeczywiĞcie wystĊpują w projekcie, a nastĊpnie powiązaü je z moĪliwymi zdarzeniami, które bĊdą miaáy wpáyw na projekt, jeĞli istotnie zajdą. Na bardzo wysokim poziomie decyzyjnym stosowane są bardziej uproszczone listy kon- trolne, pomagające zorientowaü siĊ w skali zagroĪeĔ dla projektu, bĊdącego we wstĊpnej fazie definiowania celów, uzasadnienia biznesowego i gáównych produktów projektu. Takie podejĞcie zaleca agencja OGC dla rządowych projektów, które mają wprowadziü powaĪną zmianĊ biznesową poprzez zastosowanie systemów informatycznych. W listach kontrol- nych zamiast obszarów wystĊpowania ryzyka podane są kryteria, którym podlega przyszáy projekt, a które — odpowiednio ocenione — dają wynik liczbowy odzwierciedlający ogólne zagroĪenie, jakiemu bĊdzie on naraĪony. Takimi kryteriami są m.in.:  poziom oczekiwanych korzyĞci;  skala wydatków;  liczba uĪytkowników;  wpáyw na procesy, struktury organizacyjne oraz legislacjĊ (poziom przewidywanych zmian w tych obszarach);  wpáyw na inne projekty;  poziom innowacji;  liczba specjalistów z branĪy IT zaangaĪowanych w projekt zarówno po stronie dostawców, jak i klienta. Analiza na podstawie takiej listy pomaga w podjĊciu decyzji, czy w obecnej sytuacji warto takie przedsiĊwziĊcie podejmowaü czy odáoĪyü je na póĨniej lub zrewidowaü jego definicjĊ. Rozdziaä 5. i Praktyka zarzñdzania ryzykiem 109 Na potrzeby projektów systemów informatycznych zostaá opracowany szereg list kontrol- nych bardziej szczegóáowych, z których na uwagĊ zasáuguje wprawdzie doĞü „wiekowa”, ale wciąĪ aktualna lista autorstwa Instytutu SEI. Jest ona próbą ujĊcia wszystkich obszarów ryzyka wystĊpujących w peánym cyklu tworzenia oprogramowania i stanowi tzw. takso- nomiĊ ryzyka. Zgodnie z teorią taksonomii moĪna zbudowaü hierarchiĊ klasyfikującą ob- szary w sposób, który nadaje siĊ do identyfikowania czynników na róĪnych poziomach szczegóáowoĞci. Te poziomy to klasy, elementy i atrybuty. Klasami są: inĪynieria pro- duktu, Ğrodowisko deweloperskie, ograniczenia programowe. Do kaĪdej z klas moĪna przypisaü odpowiednie elementy, np. do klasy inĪynierii produktu — wymagania, testy jednostkowe, testy integracyjne itd. Z kolei kaĪdy element posiada swoje atrybuty i przy- káadowo dla elementu „wymagania” są to m.in. stabilnoĞü, kompletnoĞü, elastycznoĞü. Peána taksonomia ryzyka opublikowana jest w dokumencie CMU/SEI-93-TR-6, dostĊp- nym na stronach internetowych Instytutu SEI. WaĪną cechą listy kontrolnej jest áatwoĞü jej stosowania. Obszary powinny byü zdefinio- wane w sposób, który jest czytelny równieĪ dla czáonków zespoáów wykonawczych, czyli w przypadku projektów informatycznych — dla analityków, projektantów, programistów, testerów, wdroĪeniowców oraz ich kierowników. PoniĪej zostaáa przedstawiona przykáa- dowa lista kontrolna ryzyka dla pewnego typu projektów informatycznych. Projekt polega na wdroĪeniu oprogramowania, z którego czĊĞü ma byü od podstaw opracowana i wytwo- rzona, a czĊĞü zakupiona i zintegrowana z nowo opracowanymi moduáami; przy wdroĪeniu konieczna jest wspóápraca z dostawcami kupowanego oprogramowania. Lista ta specyfi- kuje obszary wystĊpowania ryzyka i powinna byü pomocna przy identyfikowaniu czynni- ków ryzyka zarówno przez twórców oprogramowania, jak i wdroĪeniowców. 1. Obszar organizacyjno-zarządczy: a) korporacyjny poziom zarządzania:  kultura organizacyjna;  stabilnoĞü struktur organizacyjnych i wáasnoĞciowych;  stabilnoĞü finansowa i rynkowa;  procesy zarządcze: — DojrzaáoĞü procesów biznesowych. — Komunikacja wewnĊtrzna i zewnĊtrzna. — Planowanie i prognozowanie rozwoju. b) organizacja wspóápracy z partnerami i dostawcami:  zakres i poziom dáugoterminowych umów partnerskich;  kontraktowanie i wsparcie prawne;  dostĊpnoĞü zasobów dostawców;  polityka zarządzania jakoĞcią i wymaganiami;  atmosfera wspóápracy z dostawcami; 110 Zarzñdzanie ryzykiem w projektach informatycznych. Teoria i praktyka c) zarządzanie projektami:  kultura zarządzania w powiązaniu z dziaáalnoĞcią operacyjną;  dojrzaáoĞü procesów zarządzania projektami;  doĞwiadczenie;  dostĊpnoĞü kadry zarządzającej; 2. Obszar zewnĊtrzny: a) gospodarka i polityka; b) Ğrodowisko, infrastruktura; c) legislacja; d) dojrzaáoĞü i kondycja klientów; e) dojrzaáoĞü i kondycja dostawców; f) rynek pracy; 3. Technika: a) wymagania:  metoda zarządzania wymaganiami;  kryteria akceptacji produktów;  záoĪonoĞü wymagaĔ;  klarownoĞü wymagaĔ, ich interpretacja przez uĪytkowników i dostawców;  relacja miĊdzy oczekiwaniami uĪytkowników a sformalizowanymi wymaganiami;  proces uzgadniania zmian w wymaganiach;  wymagania dotyczące uĪytkowników przyszáej eksploatacji systemów;  atmosfera uzgadniania wymagaĔ miĊdzy stronami; b) moduáy zamawiane:  dostĊpnoĞü;  liczba dostawców, moĪliwoĞü wyboru;  relacje z dostawcami, doĞwiadczenia we wspóápracy;  sposób uzgadniania specyfikacji;  kontrola jakoĞci produktów finalnych i poĞrednich;  kontrola realizacji (terminy, koszty);  zasady odbioru produktów; Rozdziaä 5. i Praktyka zarzñdzania ryzykiem 111 c) wytwórstwo oprogramowania:  proces wytwórstwa: — DojrzaáoĞü, poziom sformalizowania. — ZnajomoĞü procesu przez zespoáy projektowe. — Kontrola procesu. — Kontrola produktu, system zarządzania jakoĞcią.  zarządzanie: — Zarządzanie zespoáami, dojrzaáoĞü zespoáów. — Wymiarowanie systemów (szacowanie czasu i kosztów). — Zarządzanie jakoĞcią. — Zarządzanie konfiguracją produktów. — Zarządzanie zmianami. — Procesy decyzyjne.  przedmiot wytwórstwa: — Koncepcja — poziom nowatorstwa. — ZáoĪonoĞü. — WieloplatformowoĞü. — Wymagania krytyczne (niezawodnoĞü, bezpieczeĔstwo). — Wymagania prawne i Ğrodowiskowe. — Ograniczenia wynikające z infrastruktury. — DostĊpnoĞü komponentów. — Wymagania dotyczące kompetencji zespoáów. — „TestowalnoĞü” (moĪliwoĞü wiarygodnego okreĞlenia jakoĞci). — DostĊpnoĞü obsáugi.  inĪynieria oprogramowania: — Specyfikowanie systemów. — Projektowanie architektury. — Projektowanie systemów bazodanowych. — Projektowanie interfejsów uĪytkownika. — BezpieczeĔstwo systemów. — Zapewnienie niezawodnoĞci. — Zapewnienie serwisowalnoĞci. — Testowanie, odbiory. 112 Zarzñdzanie ryzykiem w projektach informatycznych. Teoria i praktyka  narzĊdzia: — DostĊpnoĞü, moĪliwoĞü wyboru. — NiezawodnoĞü. — ZáoĪonoĞü technologiczna, áatwoĞü uĪycia. — WydajnoĞü. d) integracja:  systemy odziedziczone, dokumentacja systemów;  iloĞü i róĪnorodnoĞü moduáów zewnĊtrznych;  poziom koniecznej modyfikacji systemów dziedziczonych i zakupionych;  jakoĞü danych;  testy integracyjne, narzĊdzia;  dostĊpnoĞü istniejących systemów w okresie wdroĪenia;  zaangaĪowanie uĪytkowników systemów w testy akceptacyjne; e) infrastruktura techniczna:  odziedziczona infrastruktura — poziom techniczny, dokumentacja;  specyfikacja wymagaĔ sprzĊtowych;  wymagane modyfikacje infrastruktury;  dostĊpnoĞü infrastruktury w trakcie projektu; 4. ĝrodowisko pracy: a) dostĊpnoĞü zasobów; b) wspóápraca miĊdzy zespoáami projektowymi a dziaáami operacyjnymi; c) atmosfera i morale pracowników; d) komunikacja nieformalna; e) konflikty, sposoby ich rozwiązywania; f) wspóápraca wykonawców z uĪytkownikami; g) nastawienie uĪytkowników do nowych systemów. PowyĪsza lista zawiera jedynie obszary, w których wystĊpują Ĩródáa ryzyka. W trakcie analizy naleĪy bliĪej okreĞliü te Ĩródáa i na ich podstawie zidentyfikowaü czynniki ryzyka. Przykáadowo: w obszarze 3.a.iv (klarownoĞü wymagaĔ, ich interpretacja przez uĪytkow- ników i dostawców) Ĩródáem ryzyka są niejasne sformuáowania wymagaĔ, które mogą byü róĪnie interpretowane. Rodzi to czynnik ryzyka: „uĪytkownicy mogą nie uznaü pewnej funkcjonalnoĞci systemu za zgodną z ich wymaganiami i nie podpisaü protokoáu odbioru”. Konsekwencją tego moĪe byü koniecznoĞü negocjacji, a byü moĪe dodatkowej pracy polegającej na modyfikacji systemu celem dopasowania go do nowych (?) wymagaĔ. To z kolei skutkuje wydáuĪeniem projektu, jak równieĪ wzrostem kosztów. Rozdziaä 5. i Praktyka zarzñdzania ryzykiem 113 Listy kontrolne są nadzwyczaj skuteczną techniką przy wstĊpnym analizowaniu ryzyka, nie wymagają wielkich nakáadów i są áatwe w stosowaniu. Nadają siĊ równieĪ do wyko- rzystania w trakcie realizacji projektu; zakáadając, Īe przynajmniej pod koniec kaĪdego etapu naleĪy przeprowadziü dodatkową analizĊ ryzyka, identyfikacja nowych czynników jest znacznie áatwiejsza, jeĞli mamy do dyspozycji listĊ, odnoszącą siĊ w szczególnoĞci do najbliĪszej fazy projektu. Zazwyczaj przy uruchamianiu projektu trudno jest skupiü siĊ na pozornie mniej waĪnych czynnikach związanych np. z fazą testowania systemu. Co naj- wyĪej czynniki związane z tą fazą zostają zidentyfikowane na wysokim poziomie abstrakcji (np. „mogą wystąpiü káopoty przy testowaniu”). Natomiast gdy projekt jest juĪ na etapie integracji systemów, moĪna zauwaĪyü, Īe np. dane z systemów dziedziczonych mają kiep- ską jakoĞü, co przy maáo wydajnych narzĊdziach moĪe sprawiü bardzo konkretne káopoty. JakoĞü techniki list kontrolnych w duĪym stopniu zaleĪy od tego, czy są one uaktualniane i dopasowywane do danego typu projektu. Dlatego nadzwyczaj istotne jest, aby wnioski z zamkniĊtych projektów, spisane w Raporcie o DoĞwiadczeniach, byáy wykorzystywane do uzupeániania list kontrolnych. Sesje analityczne, burze mózgów Pod ogólną nazwą sesji analitycznych rozumie siĊ szereg poáączonych technik, których uĪywa siĊ w celu pozyskania informacji o ryzyku. W odróĪnieniu od metod eksperckich zakáada siĊ, Īe sporo wiarygodnych danych na temat zagroĪeĔ, a takĪe dodatkowych szans w projekcie moĪna zgromadziü w trakcie spotkaĔ uczestników projektu, w gronie powiĊk- szonym o ludzi niezwiązanych z projektem (laików). OczywiĞcie nie chodzi tu o przypad- kową wymianĊ informacji, ale sterowane sesje, w których uczestnicy, przekazując swoje doĞwiadczenia, posáugują siĊ dodatkowo danymi, przede wszystkim pochodzącymi z po- przednich projektów. Wynikiem sesji analitycznych ma byü nie tylko lista zidentyfikowanych czynników ryzyka, lecz równieĪ ocena ich parametrów, a w dalszej kolejnoĞci dobór Ğrodków zaradczych. Wynika z tego, Īe istotnym elementem tej techniki jest prognozowanie. Powstaje pytanie, jaka moĪe byü wiarygodnoĞü prognozowania, jeĞli w gronie uczestników sesji nie ma prawdziwych, uznanych ekspertów. Michael J. Mauboussin stawia uzasadnioną badaniami tezĊ („Ile warci są eksperci”, Harvard Business Review Polska, luty 2008), Īe w przypadku zjawisk probabilistycznych — a z takimi mamy do czynienia przy rozpatrywaniu ryzyka — najbardziej skuteczni okazują siĊ „dobrze poinformowani laicy”. Dotyczy to zarówno okolicznoĞci, w których jest maáa swoboda wnioskowania, jak i tych, gdzie ta swoboda jest nieograniczona lub bardzo duĪa. W związku z tym moĪna uznaü, Īe spotkanie uczest- ników projektu (czĊĞü z nich moĪe mieü wiedzĊ na poziomie eksperckim) z osobami spo- za projektu, przy odpowiednim przygotowaniu sesji, moĪe przynieĞü bardzo dobre wyniki. Burza mózgów, która moĪe byü elementem sesji analitycznej, polega na niczym nieskrĊ- powanej wymianie informacji. Z zaáoĪenia wszystkie pomysáy i opinie nie podlegają krytyce, zatem w wyniku spotkania o takim charakterze pozyskuje siĊ bardzo wiele danych, z których duĪa czĊĞü jest albo przynajmniej wydaje siĊ nieprzydatna. Niemniej kaĪdy uczestnik, bez wzglĊdu na przygotowanie do udziaáu w projekcie, posiada pewien bagaĪ wáasnych doĞwiadczeĔ, który moĪe byü przetworzony na informacje istotne przy rozpa- trywaniu ryzyka. Odpowiednia atmosfera powinna sprawiü, Īe róĪne pomysáy, pojawiające 114 Zarzñdzanie ryzykiem w projektach informatycznych. Teoria i praktyka siĊ na spotkaniu, mogą zainspirowaü uczestników do przekazywania swoich ocen, co z kolei generuje wiele nieszablonowych koncepcji. PrzydatnoĞü tej formy wymiany informacji jest oczywista w kreowaniu koncepcji w pracach badawczych i rozwojowych, natomiast w przypadku analizy ryzyka wskazane jest pewne ukierunkowanie takich sesji, czyli organizowanie „moderowanych burzy mózgów”. Proponowana przez instytut SEI technika oceny ryzyka projektów polegających na tworzeniu oprogramowania (Software Risk Evaluation — SRE), ma podobny charakter, choü oparta jest na kwestionariuszach taksonomii, czyli listach kontrolnych. Przeprowadzenie peánej sesji analitycznej polega na wykonaniu kolejnych kroków: 1. Wybór uczestników sesji — liczba ich powinna oscylowaü wokóá 10. Powinni w niej uczestniczyü:  kierownik projektu;  lider sesji (moderator) — moĪe nim byü kierownik projektu lub przedstawiciel biura wsparcia projektu;  przedstawiciel biura wsparcia projektu, spisujący pozyskane informacje, notujący uwagi — funkcjĊ tĊ moĪe speániaü lider sesji;  czáonkowie zespoáów, których dotyczy rozpatrywana faza projektu; w przypadkach gdy projekt wchodzi w fazĊ implementacyjną, wskazany jest udziaá reprezentantów zespoáu testerów, kontroli j
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Zarządzanie ryzykiem w projektach informatycznych. Teoria i praktyka
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: