Streszczenie
Autorzy przedstawili zagadnienie zarzdzania ryzkiem projektów informatycz-nych w ujciu formalnym jak i praktycznym. Formalne aspekty zwizane s z zaleceniami i wymaganiami stosowanych na całym wiecie metodologii PMI i PMBook. Zalecenia praktyczne zostały opracowane na podstawie dowiadcze auto-rów, zdobytych w cigu ostatniej dekady w projektach informatycznych krajowych i midzynarodowych.
Słowa kluczowe: zarządzanie projektami, zarządzanie ryzykiem w projektach, inĪynieria oprogramowania
1. Wstp
Kluczowym czynnikiem projektów informatycznych jest zapewnienie deklarowanego czasu dostarczenia produktu na rynek. KaĪdy projekt jest ograniczony poprzez czas, koszty i zakres, a zmiana któregokolwiek z tych czynników wpływa na pozostałe.
Prowadzenie projektów informatycznych przy minimalizowaniu czasu i kosztów prowadzi do pojawiania siĊ nowych, dodatkowych czynników ryzyka, niezaleĪących tylko od złoĪonoĞci projektu. Wybór technologii, dostĊpnoĞü odpowiednich zasobów – np. specjalistów, ekspertów, urządzeĔ – tylko w okreĞlonych oknach czasowych powoduje, Īe wzrasta ryzyko niedostarczenia poszczególnych produktów w czasie. Prowadziü to moĪe do zaniechania lub kosztownych zmian w projektach (patrz Tabela 1).
Zarządzanie ryzykiem jest zagadnieniem, któremu poĞwiĊcono liczne ksiąĪki i publikacje1234 . Zarządzanie ryzykiem pozwala zapanowaü nad problemami z tym związanymi. Dynamiczny rozwój metod zarządzania projektami i zarządzania ryzykiem rozwija siĊ w dwóch wspierających siĊ wzajemnie obszarach – w teorii i w praktyce. Wnioski z praktyki (ang. lessons learned) zarzą-dzania projektami informatycznymi zostały przedstawione miĊdzy innymi w pracach Kwak i in. i Robertsa56.
1 Buttrick R., The Project Workout: 4th edition, Financial Times/ Prentice Hall, 2009, s. 560. 2
Heldman K., Project Manager's Spotlight on Risk Management, Jossey-Bass, 2005, s. 224.
3 Hillson D., Practical Project Risk Management: The Atom Methodolog, Management Concepts, 2007, s. 224.
4 Kendrick T, Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project, AMA-COM/American Management Association, 2003, s. 358.
5 Roberts B.B., Lessons-learned: round 2, INCOSE Proceedings of a Symposium on Risk Management, 2001 (http://www.futron.com/pdf/ROBERTSFinal.pdf).
Technova-Roberts wskazuje na nastĊpujące zagadnienia7 :
• najpowaĪniejsze czynniki ryzyka zostają bardzo czĊsto przeoczone przez zarządzających projektami,
• menadĪerowie nieodpowiednio kategoryzują czynniki ryzyka i poĞwiĊcają nim nieod-powiednie zasoby,
• urzeczywistnienie ryzyka uderza w wiele parametrów projektu – czas, harmonogram, aspekty techniczne realizacji – łączne oddziaływanie nie jest poprawnie oszacowane na etapie planowania obsługi materializacji ryzyka,
• identyfikacja ryzyka jest krytycznym etapem w procesie zarządzania ryzykiem jednak pomimo tego jest czĊsto traktowana po macoszemu,
• podejĞcie typu „szybciej, lepiej, taniej” zwiĊksza ryzyko w projekcie,
• kierownik projektu musi zajmowaü mocną pozycjĊ, aby trzymaü w ryzach proces zarządzania ryzykiem.
Kwak i Stoddard uzupełniają te wnioski o inne istotne kwestie8 :
• kierownicy projektów nie zawsze mają czas na wdraĪanie formalnego procesu zarządza-nia ryzykiem,
• zarządzanie ryzykiem jest wartoĞcią dodaną do projektu w ramach produktów zarządczych, pomimo tej powszechnej wiedzy tylko zbiurokratyzowane instytucje (w Stanach Zjednoczonych) pozwalają sobie na korzystanie z usług konsultantów zajmu-jących siĊ tą tematyką,
• projekty wymagają, aby uczestniczący w nich ludzie rozwijali swoje umiejĊtnoĞci i byli zmotywowani takĪe do zmian swoich zachowaĔ,
• rzeczywista pozytywna zmiana w zarządzaniu ryzykiem musi zaistnieü nie tylko na pozi-omie zarządzających przedsiĊbiorstwem i projektami, ale takĪe na pozipozi-omie pracowników – niestety zmiany czĊsto są deklarowane wyłącznie na papierze, co powoduje, Īe wszyscy, których zmiana powinna dotyczyü zachowują dobre samopoczuc-ie.
Celem niniejszej pracy jest przedstawienie wybranych formalnych reguł zarządzania ryzyki-em proponowanych przez metodologie PRINCE29 i PMI/PMBook10 oraz praktycznych zasad zarządzania ryzykiem w projektach informatycznych. Analiza, komentarze i propozycje prak-tycznych zasad zostały poparte ponad dziesiĊcioletnim doĞwiadczeniem autorów z uczestnictwa w realizacji projektów informatycznych w zespołach krajowych i miĊdzynarodowych.
tion, Elsevier, Nov., 2003, s. 915–920.
7
Roberts B.B., Lessons-learned: round 2, INCOSE Proceedings of a Symposium on Risk Management, 2001 (http://www.futron.com/pdf/ROBERTSFinal.pdf).
88 Kwak Y.H., Stoddard J., Project risk management: lessons learned from software development environment, Technova-tion, Elsevier, Nov., 2003, s. 915–920.
9 PRINCE2, Managing Successful Projects with PRINCE2, Her Majesty’s Stationery Of-fice, 2005, s. 484.
10
Tabela 1. Przykłady nieudanych projektów informatycznych w pierwszej dekadzie XXI wieku
PrzedsiĊbiorstwo Strata
[mln USD]
Opis system informatycznego, którego rozwój lub wdroĪenie nie powiodło siĊ
Hudson Bay (Stany Zjedno-czone)
33,3 Problemy z systemem magazynowym
Avis Europe PLC (Wielka Brytania)
54,5 Nieudane wdroĪenie (zaniechano prac wdroĪeniowych)
systemu ERP Ford Motor Co. (Stany
Zjednoczone)
400,0 Nieudane wdroĪenie systemu do zarządzania zakupami
J Sainsbury PLC (Wielka Brytania)
527,0 Porzucenie systemu zarządzania łaĔcuchem dostaw
Hewlett-Packard Co. (Stany Zjednoczone)
160,0 Problemy z systemem ERP
AT&T Wireless (Stany Zjednoczone)
100,0 Problemy z przejĞciem do nowej wersji systemu CRM
McDonald’s Corp. (Stany Zjednoczone)
170,0 Zaprzestanie rozwoju prac nad innowacyjnym systemem
informacyjnym do obsługi zakupów Nike Inc. (Stany
Zjednoczo-ne)
100,0 Problemy z systemem zarządzania łaĔcuchem dostaw
Kmart Corp. (Stany Zjedno-czone)
130,0 Nieudane wdroĪenie (zaniechane) systemu zarządzania
łaĔcuchem dostaw
ħródło: Opracowanie własne.
2. Czynniki ryzyka w projektach informatycznych
Ryzyko projektu to skumulowany efekt prawdopodobieĔstwa wystąpienia niepewnych zda-rzeĔ, które mogą korzystnie lub niekorzystnie wpływaü na realizacjĊ projektu i osiąganie jego celów11.
Zarządzanie ryzykiem wg strukturalnej metodyki zarządzania projektem PRINCE212 to „[..] radzenie sobie z sytuacją naraĪenia projektu na ryzyko (tzn. prawdopodobieĔstwo wystąpienia okreĞlonych zagroĪeĔ oraz gdy siĊ one urzeczywistnią, ich potencjalnych skutków). Celem jest planowanie nad stopniem tego naraĪenia poprzez podejmowanie działaĔ utrzymujących ryzyko na akceptowalnym poziomie w sposób efektywny kosztowo”.
W praktyce w organizacjach czĊsto marginalizuje siĊ zarządzanie ryzykiem mając nadziejĊ, Īe bĊdą one w stanie poradziü sobie z problemami, które siĊ pojawią.
Jones sprowadził czynniki ryzyka w projekcie informatycznym do trzech grup13: • ryzyka związanego z niewłaĞciwym szacowaniem czasu realizacji projektu, • ryzyka wynikającego z błĊdnych lub optymistycznych raportów okresowych,
• ryzyka związanego z naciskami wywieranymi na projekt, kierownika i zespół projektowy. Boehm wskazał ryzyka związane z realizacją projektów przez firmy informatyczne14, tj.:
11
PRINCE2, Managing Successful Projects with PRINCE2, Her Majesty’s Stationery Of-fice, 2005, s. 484.
12
Tame.
13
• brak odpowiedniego zespołu (problemy kadrowe) – problemy z doborem członków zespołu, z moĪliwoĞciami pozyskania specjalistów na rynku pracy, ubytki w czasie real-izacji projektu,
• nierealny budĪet i harmonogram – sytuacja oczekiwany czas i koszt realizacji projektu nie pozwala na realizacjĊ projektu a projekt mimo to jest rozpoczynany; sytuacja taka ma miejsce, gdy mamy do czynienia z naciskami na podjĊcie projektu (np. wewnątrz firmy, aby podjąü ryzyko i spróbowaü zdobyü nowy rynek lub klienta) lub błĊdnie oszacowano koszt i czas realizacji projektu,
• implementacja funkcjonalnoĞci niezgodnych z wymaganiami (strata czasu i innych zasobów) na skutek błĊdnej komunikacji, niezrozumienia lub niejasnoĞci czy niejednoz-nacznoĞci wymagaĔ,
• implementacja złych i niefunkcjonalnych interfejsów uĪytkownika wynikająca np. z braku komunikacji z klientem lub przyszłym uĪytkownikiem,
• zbytnie „dąĪenie do doskonałoĞci” powodujące implementacjĊ nadmiarowych i nieocze-kiwanych przez nikogo funkcjonalnoĞci – mamy z tym do czynienia, gdy programiĞci chcą oddaü najlepszy produkt poĞwiĊcając zasoby na jego wykaĔczanie, podczas gdy wymagane jest oddanie produktu spełniającego podstawowe wymagania,
• nieskoĔczone – ciągłe zmiany w wymaganiach (ang. CR, change request), które mogą doprowadziü kaĪdy projekt do poraĪki, związane z problemami z komunikacją lub jed-noznacznym okreĞleniem wymagaĔ, braku determinacji w ograniczaniu liczby zmian w szczególnoĞci w koĔcówce projektu (zamraĪanie zmian),
• problemy ze komponentami pozyskiwanymi poza zespołem (zakup, zlecanie wykonania komponentów) – dostarczanymi po terminie, z ich jakoĞcią, itp.,
• problemy z zewnĊtrznymi zadaniami zlecanymi, z ich jakoĞcią, terminami – zadania i produkty zlecane do wykonania na zewnątrz naleĪy rozpatrywaü jako projekty obar-czone swoimi ryzykami wpływającymi na ryzyka realizacji projektu głównego,
• problemy z rzeczywistą wydajnoĞcią w projekcie – bywa ona róĪna i zaleĪy od wielu czynników, np. zmĊczenia pracowników (którzy nie powinni pracowaü w nadgodzinach) czy realnym czasie pracy (dzieĔ pracy jest równowaĪnikiem 8 godzin, jednakĪe w prak-tyce przyjmuje siĊ go za równowaĪnik 5–6 godzin).
Wiele z wyĪej wymienionych czynników ryzyka zaleĪy bezpoĞrednio od ludzi biorących bezpoĞrednio lub poĞrednio udział w realizowanym projekcie informatycznym.
3. Ryzyko w projekcie a czynnik ludzki
W celu rozpoczĊcia pracy nad analizowaniem ryzyka w projekcie informatycznym naleĪy po-stawiü sobie kilka podstawowych pytaĔ: jakie jest ryzyko niepowodzenia poszczególnych zadaĔ?
• jaki jest wpływ tego ryzyka na projekt? • co moĪna zrobiü?
• co powinniĞmy zrobiü?
• czy koszt działaĔ związanych z zarządzaniem ryzykiem nie jest zbyt duĪy? • czy czas działaĔ związanych z zarządzaniem ryzykiem nie jest zbyt długi?
Odpowiedzi na powyĪsze pytania zaleĪą od wiedzy, doĞwiadczenia i odpowiedzialnoĞci uczestniczących w realizacji projektu. PodejĞcie do ryzyka przez osoby odpowiedzialne i zarzą-dzające projektem wpływa istotnie na proces zarządzania ryzykiem. Powszechnie znana jest klasyfikacja osób ze wzglĊdu na róĪne podejĞcie do ryzyka: (i) ludzie unikający ryzyka to osoby charakteryzujące siĊ postawą zachowawczą, (ii) ludzie skłonni do podejmowania ryzyka – w ten sposób moĪna scharakteryzowaü aktywnych inwestorów, (iii) ludzie Ğwiadomi ryzyka traktujący je jako normalny element codziennego Īycia oraz (iv) ludzie lekcewaĪący ryzyko, czĊsto nieĞwia-domi tego ryzyka. Nie tylko sponsor czy kierownik projektu są osobami, dla których sposób postrzegania ryzyka jest waĪny – znaczenie ma takĪe charakter innych osób, które róĪnie klasyfi-kują oraz oceniają postrzegane ryzyka i eskalują je bądĨ nie do swoich przełoĪonych.
Niezmiernie istotnym czynnikiem w realizacji projektu jest komunikacja pomiĊdzy uczestni-kami projektu. Istotne jest jednoznaczne okreĞlenie zasad komunikacji (zakres, czĊstotliwoĞü, odpowiedzialnoĞü) przed rozpoczĊciem lub na samym początku projektu.
Jasne i jednoznaczne zasady komunikacji i odpowiedzialnoĞci ułatwiają pracĊ i pozwalają na odpowiednie reagowanie w sytuacjach zagroĪenia projektu lub jego poszczególnych zadaĔ.
Przykładem informacji niezmiernie waĪnej dla zarządzania ryzykiem jest informacja o do-puszczalnych tolerancjach lub teĪ inaczej mówiąc dopuszczalnym poziomem akceptacji ryzyka. NaleĪy pamiĊtaü, Īe osoby zarządzające ryzykiem muszą za kaĪdym razem rozwaĪyü i oszacowaü akceptowalny poziom ryzyka, który bĊdzie siĊ zmieniaü w zaleĪnoĞci od osobniczego podejĞcia do ryzyka a przede wszystkim do wag przypisywanych poszczególnym zagroĪeniom.
Podobnie kaĪdy z członków zespołu bĊdzie analizował poszczególne ryzyka. TakĪe i zespół projektowy bĊdzie akceptował duĪe ryzyko w pewnych dziedzinach, podczas gdy w innych nie (np. tam gdzie bĊdzie chodziü o zagroĪenie dla zdrowia i Īycia, kwestie prawne, itp.).
Niezmiernie waĪne są cechy osobowe poszczególnych członków zespołu projektowego, które mogą byü zaląĪkiem problemów natury społecznej w grupie. Ponadto przed kierownikiem zespołu stoją wyzwania związane z zatrudnianiem bądĨ wymienianiem członków zespołu co ma wpływ (negatywny lub pozytywny) na efektywnoĞü pracy i moĪliwoĞci dotrzymania terminów.
4. Formalne zasady zarzdzanie ryzykiem w projekcie informatycznym
Zarządzanie ryzykiem projektu to wszelkie działania podejmowane w zarządzaniu projektem w celu15:
• identyfikacji ryzyka (zdarzenia w projekcie),
• sklasyfikowania lub pomiaru poszczególnych rodzajów ryzyka (prawdopodobieĔstwa wystąpienia oraz ocena wpływu materializacji ryzyka),
• neutralizacja lub zapobiegania ryzyka (ograniczenie dotkliwoĞci materializacji ryzyka). Identyfikacja ryzyka polega na wytypowaniu i opisaniu zdarzeĔ, które mogą mieü potencjal-nie negatywny wpływ na realizowany projekt. CzĊstym problemem jest zapominanie o ryzyku które istnieje juĪ na etapie eksploatacji produktów projektu. Pod koniec realizacji projektu zdarza siĊ identyfikowaü zagroĪenia, które mogą wpływaü na produkt projektu w okresie jego eksploata-cji – informacje te powinny byü jawne dla uĪytkowników produktu.
W celu identyfikacji ryzyka stosuje siĊ m.in.: przegląd specyfikacji/dokumentacji, techniki gromadzenia informacji formalnej i nieformalnej, listy kontrolne, techniki diagramowe (szacowa-nie i monitorowa(szacowa-nie czasu realizacji zadaĔ oraz dostĊpnych zasobów), analizĊ SWOT, itp.
Oprócz zastosowania w/w metod istotne znaczenie ma własne doĞwiadczenie, które pozwala na urealnienie oceny sytuacji. Ponadto czĊsto stosuje siĊ wspólne – z zespołem, ekspertami ze-wnĊtrznymi – identyfikowanie i szacowanie ryzyk, np. z zastosowaniem metody delfickiej. W takim przypadku moĪna zaprosiü do współpracy ekspertów zewnĊtrznych spoza firmy, w szczególnoĞci gdy w grĊ wchodzą nowe obszary merytoryczne w projekcie lub technologie niestosowane dotychczas w firmie.
Tabela 1. Analiza jakociowa z zastosowaniem wag dla szacunków prawdopodobie stwa i skutków materializacji ryzyka (szarym kolorem zaznaczono tolerowane ryzyka)
Prawdopodobiestwo materializacji ryzyka
Niskie [1] ĝrednie [2] Wysokie [3]
Skutki materializacji ryzyka Łagodne [1] 1 (1 x 1) 2 (1 x 2) 3 (1 x 3)
Umiarkowane [3] 3 (3 x 1) 6 (3 x 2) 9 (3 x 3)
Dotkliwe [6] 6 (6 x 1) 12 (6 x 2) 18 (6 x 3)
ħródło: Na podstawie [10].
W przypadku organizacji lub osób istotne znaczenie ma prowadzenie bazy wiedzy na temat wczeĞniej realizowanych projektów, zarówno tych udanych jak i nieudanych. Rejestr taki moĪe zawieraü informacje na temat zaistniałych, rozpoznanych lub niezidentyfikowanych w porĊ ryzyk, ich zapobieganiu oraz obsłudze w wypadku zmaterializowania. Wiedza ta jest znacząco pomocna w procesie identyfikacji ryzyka w bieĪącym projekcie informatycznym.
Do identyfikacji i dalszej klasyfikacji ryzyka stosuje siĊ takĪe symulowanie przyszłych zda-rzeĔ przy uwzglĊdnieniu róĪnych scenariuszy rozwoju przyszłej sytuacji.
15
Klasyfikacja ryzyka polega na dokonaniu oceny ryzyka z zastosowaniem metod opisowych – nienumerycznych. Analiza jakoĞciowa moĪe korzysta z metod szacunkowych z wykorzystaniem okreĞlonych wag aby łatwiej klasyfikowaü ryzyka. Przykładowe zestawienia wag przedstawiono w tabelach (Tabela 1).
Analiza jakoĞciowa pozwala nie tylko na doprecyzowanie ryzyk oraz prawdopodobieĔstwa i skutków ich materializacji ale pozwala na wygenerowanie takich produktów zarządczych jak: rejestr ryzyka, ranking ryzyk projektu informatycznego, trendów w jakoĞciowej analizie ryzyk. Ponadto pozwala na sklasyfikowanie ryzyk na: (i) wymagające dalszej szczegółowej analizy, (ii) podlegające bieĪącej obserwacji (wysokie prawdopodobieĔstwo wystąpienia a w szczególnoĞci wysokie koszty w przypadku materializacji ryzyka), (iii) wymagające reakcji w najbliĪszym czasie.
Pomiar ryzyka jest realizowany poprzez ocenĊ prawdopodobieĔstwa oraz skutków najwaĪ-niejszych rodzajów ryzyka za pomocą wskaĨników liczbowych. Podczas tego etapu wykonuje siĊ analizĊ iloĞciową, która polega na przypisaniu wartoĞci liczbowych zarówno do ryzyka projektu jako całoĞci oraz do istotnych rodzajów ryzyka z zastosowaniem rachunku prawdopodobieĔstwa. Analizy iloĞciowej nie wykonuje siĊ dla ryzyk sklasyfikowanych w analizie jakoĞciowej jako nieistotnych z małym wpływem na realizacjĊ projektu informatycznego.
Do pomiaru ryzyka moĪna zastosowaü metodĊ Monte Carlo opracowaną przez polskiego nau-kowca, pracującego nad amerykaĔską bombą termojądrową, Stanisława Ulama. Na tym etapie stosuje siĊ takĪe drzewa decyzyjne do kwantyfikacji wyników projektu, oceny prawdopodobieĔ-stwa osiągniĊcia celu projektu czy teĪ identyfikacji najlepszych decyzji kierowania projektem informatycznym. Innymi stosowanymi metodami są analiza wraĪliwoĞci i oczekiwana wartoĞü pieniĊĪna. Jednym z rezultatów analizy iloĞciowej jest okreĞlenie prawdopodobieĔstwa osiągniĊcia celów kosztowych i terminowych projektu, co pozwala stwierdziü, Īe np. mamy X% szans na zakoĔczenie projektu w terminie Y oraz V% szans na zamkniĊcie siĊ w kosztach projektu Z PLN.
Planowanie sposobów reagowania na ryzyko sprowadza siĊ do tworzenia strategii neutrali-zowania lub zapobiegania ryzyku. Istotnym wynikiem planu sposobu reagowania na ryzyko jest okreĞlenie działaĔ, które pomogą rozwiązaü problemy związane z poszczególnymi rodzajami ryzyka rozpoznanymi w procesie identyfikacji ryzyka.
Reagowanie na ryzyko sprowadza siĊ do nastĊpujących metod: (i) unikania ryzyka, (ii) łago-dzenia ryzyka, (iii) przeniesienia ryzyka, (iv) akceptacji ryzyka, (v) tworzenie rezerw na obsługĊ urzeczywistnionego ryzyka.
Unikanie ryzyka w praktyce moĪe byü zastosowane poprzez wybranie innej – znanej techno-logii informatycznej, wyboru innego partnera lub podwykonawcy do realizacji projektu, czy teĪ na podjĊciu decyzji o nie przystĊpowaniu do realizacji projektu. Łagodzenie ryzyka polega na jego redukcji poprzez podejmowanie działaĔ w celu ograniczenia stopnia naraĪenia na nie. Przeniesie-nie ryzyka moĪe polegaü na np. zaproszeniu innych partnerów lub podwykonawców, ubezpieczenie siĊ od odpowiedzialnoĞci lub zapewnieniu odpowiednich zapisów w umowie, aby przenieĞü koszty materializacji ryzyka na inne strony umowy. Akceptacja ryzyka jest ostatnią z metod reagowania na ryzyko i wiąĪe siĊ z akceptacją poniesienia kosztów materializacji ryzyka. Firma informatyczna przygotowuje sie do akceptacji ryzyka wzmacniając własną pozycjĊ, aby znieĞü jego skutki. Zazwyczaj dzieje siĊ to w sposób aktywny (tworzenie rezerw na poniesienie ewentualnych kosztów) lub pasywny (przyjĊcie ryzyka).
Nadzorowania i kontrola ryzyka (monitorowanie) jest etapem, w którym nastĊpuje fak-tyczne wdroĪenie zarządzania ryzykiem w realizacji projektu miĊdzy innymi poprzez kroczącą aktualizacjĊ spisów, rejestrów ryzyk i planowanych sposobów reagowania na ryzyko. Sprowadza siĊ to do nieustannej, bieĪącej obserwacji poszczególnych rodzajów ryzyka oraz warunków przy zastosowaniu narzĊdzi zdefiniowanych na etapie planowania.
Na tym etapie niezwykle pomocne są działania zapobiegawcze mające na celu eliminacjĊ ry-zyka zanim ono wystąpi. W przypadku materializacji ryry-zyka istotną rolĊ pełni plan awaryjny oraz plan zapasowy, mający na celu zdefiniowanie akcji i działaĔ wystĊpujących, gdy plan awaryjny okazuje siĊ nieskuteczny.
NaleĪy pamiĊtaü, Īe zawsze realnym właĞcicielem i odpowiadającym za ryzyko jest osoba zlecająca projekt w firmie – moĪe to byü właĞciciel firmy, przewodniczący komitetu sterującego projektem16, itp. Dotyczy to takĪe sytuacji, gdy kierownikiem projektu nie jest Īadna z wymienio-nych osób – a tak niemal wygląda norma w praktyce, gdzie menadĪer projektu jest tylko wynajĊty do prowadzenia konkretnego projektu.
Planowanie zarzdzania ryzykiem sprowadza siĊ do zapewnienia infrastruktury oraz opra-cowania planu zarządzania ryzykiem w projekcie informatycznym. W praktyce projekt nie jest samodzielnym bytem, ale zaleĪy od wymogów sponsora projektu a co za tym idzie od szerszego Ğrodowiska organizacji. Zatem uwarunkowania zarządzania ryzykiem zaleĪą od strategii zarządza-nia ryzykiem w organizacji realizującej projekt oraz tolerancji grup interesu wobec ryzyka.
Praktyczne podejĞcie do zarządzania ryzykiem wymaga rejestrowania informacji o ryzyku w dokumentacji projektowej. Zakres informacji i czĊstotliwoĞü raportowania moĪe byü ĞciĞle okreĞlona lub tylko zalecana przez konkretną metodologiĊ. W praktyce powinno siĊ raportowaü informacje „w wystarczającej iloĞci i w odpowiednim czasie”.
Na kaĪdym etapie zarządzania ryzykiem powinna byü prowadzona dokumentacja, choüby w formie informacji cząstkowych – jeĞli nie moĪemy podaü bardziej szczegółowych danych.
Minimalne zestawienia informacyjne dotyczące procesu ryzyka są wymagane przez metodyki. Klasycznym przykładem takiego dokumentu jest rejestr ryzyka1718.
Rejestr ryzyka praktycznie powinien zawieraü nastĊpujące informacje na temat kaĪdego ze zi-dentyfikowanych ryzyk (oczywiĞcie nie wszystkie bĊdą od początku znane):
• nazwa ryzyka – definiowana jednoznacznie i unikalnie w celu komunikacji i odwołaĔ, • identyfikator ryzyka, przyjmujący stany: otwarty, zamkniĊty, w procesie analizie,
• właĞciciel ryzyka – którym jest osoba najlepiej mogąca monitorowaü zjawisko związane z ryzykiem – moĪe to byü menadĪer projektu lub inne osoby (członkowie zespołu, nad-zorujący projekt, inne osoby z organizacji realizującej lub w której realizowany jest projekt, itp.),
• wynik analizy: opis zdarzenia, prawdopodobieĔstwo wystąpienia P i jego wpływ W (na czas, jakoĞü, zakres, koszt), iloczyn P x W, symptomy materializacji ryzyka, sposób zarządzania ryzykiem w postaci planu awaryjnego i planu zapasowego,
• historia wpisu,
• ranking ryzyka (opcjonalny).
16
PRINCE2, Managing Successful Projects with PRINCE2, Her Majesty’s Stationery Of-fice, 2005, s. 484. 17
PRINCE2, Managing Successful Projects with PRINCE2, Her Majesty’s Stationery Of-fice, 2005, s. 484. 18 PMI, A Guid to the Project Management Body of Knowledge, Fourth Edition, p. 510, 2008, s. 510.
W procesie zarządzania ryzkiem pojawiü siĊ moĪe wiele błĊdów powodujących, Īe nie moĪna zdefiniowaü wszystkich istotnych ryzyk, które pojawiają siĊ, materializują bądĨ stają nieaktualne w cyklu Īycia projektu informatycznego.
5. Praktyczne zasady minimalizacji ryzyka podczas prowadzenia projektów informatycz-nych
Bart Jutte proponuje 10 zasad zarządzania ryzykiem w projekcie19 (patrz Rysunek ).
Zarządzanie ryzykiem jest czĊĞcią projektu i tak powinno byü traktowane, naleĪy przeznaczyü na nie odpowiednie zasoby (nakłady czasu, koszt). Nie uwzglĊdnienie kosztów i czasu pracy osób zaangaĪowanych w zarządzanie ryzykiem powoduje, Īe praca ta bĊdzie nieoszacowana i wykony-wana w nieformalnym nadliczbowym czasie, bądĨ pomijana co doprowadzi do załamania zarządzania ryzykiem w projekcie.
Rysunek 1. Zasady zarzdzania ryzykiem w projekcie wg Barta Jutte ħródło: Opracowanie własne na podstawie [7].
Ryzyko w projekcie powinno byü identyfikowane moĪliwie najszybciej, tak aby moĪliwe było unikniĊcie jego urzeczywistnienia lub moĪliwie najlepsze przygotowanie siĊ do zmierzenia siĊ z wynikiem jego materializacji. Dokumentacja projektowa, czĊsto bardzo obszerna i dostĊpna w pełni tylko w wersji elektronicznej, nie zawsze zawiera informacjĊ o moĪliwych ryzykach. Jednak uwaĪne jej czytanie (czĊsto wielokrotne i przez róĪne osoby) pozwala na znalezienie „miĊdzy wierszami” informacji o ryzykach, które mogą siĊ w projekcie pojawiü lub są juĪ obecne. Praca z klientem i zespołem projektowym, podwykonawcami, itd., czĊsto w formie spotkaĔ cyklicznych, jest doskonałym Ĩródłem informacji o ryzykach, które rozpoznawane są z czasem, 19
kiedy przechodzi siĊ na coraz niĪszy poziom szczegółów w projekcie (na poziom konkretnych zadaĔ projektowych).
Informacja o zidentyfikowanych ryzykach oraz planowanych metodach reagowania na nie, moĪe byü sekretem członka lub zespołu projektowego. Informacja ta powinna trafiü do zespołu – aby rozwaĪyü moĪliwe działania – oraz do sponsora projektu, który, jako jego właĞciciel, powi-nien mieü wiedzĊ o istniejących ryzykach. Od kierownika projektu zaleĪy, czy o konkretnym ryzyku powinien poinformowaü natychmiast (ryzyka o duĪym prawdopodobieĔstwie materializa-cji i wpływie na projekt) czy umieĞciü tĊ informacjĊ dopiero w okresowym raporcie nt. realizamaterializa-cji projektu, co dzieje siĊ w przypadku wiĊkszoĞci tego typu zdarzeĔ.
Bardzo czĊsto ryzyko kojarzone jest tylko z negatywnymi zjawiskami. Wynika to zazwyczaj z optymalizowania zasobów (czasu) i skupieniu siĊ na tym aby projekt zakoĔczył siĊ pozytywnie. Powoduje to, Īe identyfikuje siĊ zazwyczaj tylko te ryzyka, które generują negatywny wpływ na realizacjĊ projektu. JednakĪe identyfikując nowe ryzyko naleĪy rozpatrzyü nie tylko jego nega-tywny wpływ ale i moĪliwe pozytywne skutki. Ponadto ryzyka o wyłącznie pozytywnym wpływie naleĪy traktowaü analogicznie do tych, których materializacja przynosi skutki negatywne. Daje to szansĊ na wykorzystanie moĪliwoĞci, które mogą siĊ pojawiü w projekcie. Zatem wszystkie ryzyka naleĪy analizowaü pod kątem wpływów pozytywnych i negatywnych, gdyĪ materializacja ryzyka moĪe byü szansą zaistnienia sytuacji moĪliwych do wykorzystania w projekcie lub szeroko pojmowanej działalnoĞci firmy.
Sama identyfikacja i przyjĊcie planu działania dla obsługi ryzyka i jego materializacji nie wy-starcza. Konieczne jest ustalenie właĞciciela ryzyka. MoĪe nim byü sponsor, kierownik projektu lub członek zespołu projektowego. Prostym i skutecznym mechanizmem jest formalne przypisanie kaĪdego ryzyka właĞcicielowi, którego zadaniem bĊdzie monitorowanie i optymalizacja ryzyka (np. poprzez zapobieganie lub przygotowanie siĊ do jego materializacji).
Optymalne zarządzanie ryzykiem wymaga – jako warunku koniecznego choü niewystarczają-cego – ustalenia priorytetów dla zidentyfikowanych ryzyk. Pozwala to na zajĊcie siĊ ryzykami o najwyĪszych priorytetach, tych, których materializacja moĪe stanowiü najwiĊkszy problem.
Zidentyfikowane ryzyka wymagają dokładnej analizy, której celem jest zrozumienie ich natu-ry, co z kolei pozwala na przyjĊcie odpowiedniego sposobu reagowania. Bart Jutte rozwaĪa analizĊ ryzyka na nastĊpujących poziomach20:
• indywidualna analiza kaĪdego ryzyka – jako dobry sposób na przemyĞlenie wyników urzeczywistnienia ryzyka,
• analiza efektów materializacji ryzyka – pozwala opisaü efekty, które wystąpią w momen-cie urzeczywistnienia ryzyka oraz ich efekty pochodne,
• szczegółowa analiza wpływu materializacji ryzyka na parametry projektu, takie jak: koszt, czas dostarczenia produktów projektu, jakoĞü produktów,
• analiza zjawisk poprzedzających materializacjĊ ryzyka na potrzeby monitorowania ryzyka oraz lekcji na przyszłoĞü,
• ogólna analiza całego projektu w Ğwietle ryzyk juĪ zidentyfikowanych.
Planowanie i wdraĪanie planów reagowania na materializacjĊ ryzyka jest wartoĞcią dodaną projektu, która pozwala na zaĪegnanie zagroĪenia lub zminimalizowanie negatywnego wpływu urzeczywistnienia ryzyka. W przypadku, gdy mamy do czynienia z pozytywnym wpływem
wystą-20
pienia jakiegoĞ zjawiska (ryzyko „pozytywne”) to celem właĞciciela ryzyka jest dąĪenie do mate-rializacji ryzyka lub tez zaniechanie działania – jeĞli szanse na urzeczywistnienie lub ich wpływ pozytywny są małe.
Zarządzanie ryzykiem powinno byü dobrze udokumentowane. Dokumentacja w postaci reje-stru ryzyka pozwala nie tylko na Ğledzenie historii i stanu bieĪącego ryzyka w projekcie ale minimalizuje szanse zapomnienia o wczeĞniej zidentyfikowanym ryzyku. Rejestr taki jest Ğwiet-nym narzĊdziem do komunikacji (informowania) członków zespołu, komitetu sterującego, sponsora i innych osób, w zaleĪnoĞci od potrzeb. W przypadku niepowodzenia projektu pozwala takĪe broniü kierownika, który moĪliwie najlepiej zarządzał ryzykiem identyfikując je i planując optymalizacjĊ urzeczywistnienia ryzyka. Pomimo tego, w praktyce moĪna jednak spotkaü kierow-ników projektów, którzy nie chcą dokumentowaü zarządzania ryzykiem obawiając siĊ, Īe dokumentacja ta zostanie uĪyta przeciwko nim.
Istotnym elementem procesu zarządzania ryzykiem jest Ğledzenie ryzyka oraz realizacji zwią-zanych z nim zadaĔ projektowych. ĝledzenie ryzyka dotyczy obserwacji szans jego wystąpienia, zmiany wpływu i koniecznoĞci przyjmowania innych strategii wobec jego materializacji. ĝledze-nie zadaĔ powiązanych z ryzykami okreĞlonymi w rejestrze ryzyka sprowadza siĊ do monitorowania zadaĔ – przesuniĊü w harmonogramie, zmiany warunków koniecznych do rozpo-czĊcia, realizacji i zakoĔczenia zadania – oraz czynników z tym powiązanych.
Opisane powyĪej zasady prowadzenia projektu są, w opinii autorów, dobrymi wzorcami do zarządzania ryzykiem przez kierownika projektu. NaleĪy je uzupełniü o zarządzanie ryzykiem na poziomie zespołu projektowego.
Zarządzanie ryzykiem w projekcie powinno obejmowaü zespół projektowy a członkowie ze-społu powinni rozumieü istniejące ryzyko, braü aktywny udział w identyfikowaniu i zapobieganiu ryzyku. PomyĞlna realizacja projektu moĪe byü ułatwiona jeĞli zespół jest pro aktywny i realizuje zadania rozumiejąc ich celowoĞü.
Szereg zasad zarządzania ryzykiem w pracy zespołowej został zaproponowany przez Higuera i in. W niniejszym opracowaniu podzielono te zasady na trzy grupy21:
• zasady zapewniające zrozumienie celu projektu, • reguły związane z metodami realizacji projektu, • wartoĞci ułatwiające osiągniĊcie celu przez zespół.
KaĪdy członek zespołu powinien rozumieü cel projektu i zakres zadaĔ zespołu. Wymaga to wypracowania moĪliwie najwczeĞniej wizji produktu jednakowo rozumianej przez wszystkich członków zespołu. Naczelną zasadą powinno byü takĪe stałe pamiĊtanie i odnoszenie siĊ do finalnego celu projektu i produktów mających powstaü (lub inaczej wizji całego systemu).
21
Higuera R.P., Gluch D.P., i inni, An introduction to team risk management, Special Report, CMU/SI -94-SR-1, Software engineering Institute, 1994, s. 534.
Rysunek 2. Podstawowe zasady minimalizacji ryzyka w pracy zespołowej ħródło: Opracowanie własne na podstawie [4].
Drugą grupĊ stanowi dobór odpowiednich narzĊdzi w zakresie elastycznych technologii in-formatycznych i metodologii zarządzania projektem, zintegrowanie ciągłego zarządzania ryzykiem z projektem (jako czĊĞü projektu – ciągłe zadanie zarządcze) oraz jasna i czytelna komunikacja. To właĞnie komunikacja stanowi najwiĊkszy problem w realizowaniu projektów, gdyĪ percepcja i zrozumienie jĊzyka, zwrotów oraz domniemania mogą powodowaü całkowite niezrozumienie pod przykrywką jasnoĞci zakresu i celu zadaĔ. SytuacjĊ szczególnie utrudniają Īądania zmiany w projekcie na tle niesprecyzowanych dokładnie i mierzalnie wymogów dotyczących produktów finalnych. Stąd teĪ proces komunikacji i wyjaĞniania wszystkich niejasnoĞci powinien byü ciągły i dobrze zrozumiany przez wszystkich uczestników projektu.
Ostatnia grupa zasad powiązana jest z wartoĞciami, które powinien reprezentowaü zespół oraz cechami osobowymi poĪądanymi u jego członków, są to:
• otwarta komunikacja pomiĊdzy członkami zespołu,
• proaktywnoĞü – kaĪdy z członków zespołu powinien dąĪyü do inicjowania zmian i kontrolowania sytuacji, a nie jedynie reagowaü na nią,
• szacunek dla kaĪdego członka zespołu i liczenie siĊ z jego zdaniem – co pozwala na ak-tywny udział wszystkich w zgłaszaniu problemów, propozycji rozwiązaĔ, itp.
PowyĪsze reguły dla zarządzania ryzykiem mają charakter praktyczny zweryfikowany pozytywnie przez autorów podczas uczestnictwa w projektach (krajowych i miĊdzynarodowych) w ostatnich 10 latach. NaleĪy je uzupełniü o koniecznoĞü ciągłej weryfikacji i wzrostu efektywn-oĞci, chociaĪby z japoĔskim podejĞciem Kaizen, które kaĪe pamiĊtaü, Īe ulepszanie procesu zarządzania ryzykiem w projektach jest ciągłe i nie ma koĔca.
6. Podsumowanie
Zarządzanie ryzykiem powinno byü czĊĞcią zarządzania projektem informatycznym. Nie zaw-sze ma to jednak miejsce w praktyce. Wpływa to na zaniechanie lub zwiĊkzaw-szenie kosztów wielu projektów informatycznych z powodu złej komunikacji. Niezrozumienie pomiĊdzy klientem a producentem (zespołem projektowym) jest przyczyną 66% projektów informatycznych wg Forrester Research.
NaleĪy pamiĊtaü jednak, Īe dziedzina jaką jest zarządzanie projektami a w szczególnoĞci jego czĊĞü – zarządzanie ryzykiem – dynamicznie siĊ rozwija a praktyka wciąĪ zaskakuje studiami przypadków.
Autorzy przedstawili czynniki ryzyka w projekcie informatycznym ze szczególnym uwzgl Ċd-nieniem czynnika ludzkiego. Przedstawiono formalne, ogólne zasady zarządzania ryzykiem zebrane na podstawie metodologii zarządzania projektami PRINCE2 i PMI/PMBook. NastĊpnie zebrano praktyczne zasady zarządzania ryzykiem w projektach, które zostały opatrzone komenta-rzem. Komentarz ten powstał na bazie wieloletniego doĞwiadczenia w realizacji projektów w zespołach polskich i miĊdzynarodowych.
%LEOLRJUDILD
[1] Boehm, B.W., Software risk management principles and practicies, IEEE Software 8 (1), 1991, s. 32–41.
[2] Buttrick R., The Project Workout: 4th edition, Financial Times/ Prentice Hall, 2009, s. 560. [3] Heldman K., Project Manager's Spotlight on Risk Management, Jossey-Bass, 2005, s. 224. [4] Higuera R.P., Gluch D.P., i inni, An introduction to team risk management, Special Report,
CMU/SIĉ-94-SR-1, Software engineering Institute, 1994, s. 534.
[5] Hillson D., Practical Project Risk Management: The Atom Methodolog, Management Con-cepts, 2007, s. 224.
[6] Jones, C., Minimizing the risks of software development, Cutter IT Journal 11 (6), s. 13–21, 1998.
[7] Jutte B., 10 Golden Rules of Project Risk Management, http://www.projectfuture.net.
[8] Kendrick T, Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project, AMACOM/American Management Association, 2003, s. 358.
[9] Kwak Y.H., Stoddard J., Project risk management: lessons learned from software develop-ment environdevelop-ment, Technovation, Elsevier, Nov., 2003, s. 915–920.
[10] PMI, A Guid to the Project Management Body of Knowledge, Fourth Edition, p. 510, 2008, s. 510.
[11] PRINCE2, Managing Successful Projects with PRINCE2, Her Majesty’s Stationery Office, 2005, s. 484.
[12] Roberts B.B., Lessons-learned: round 2, INCOSE Proceedings of a Symposium on Risk Management, 2001 (http://www.futron.com/pdf/ROBERTSFinal.pdf).
ABOUT BOTH FORMAL AND INFORMAL RULES OF THE RISK MANAGEMENT IN IT PROJECTS
Summary
Authors presents both formal and informel aspects of risk management in IT projects. The formal ones are related to requirements of world-wide used methodol-ogies like American PMI or British PMBook. The authors’ 10 years of personal experience in software engineering gained in both national and international pro-jects stands behind presented practical rules.
Keywords: project management, risk management, software engineering Grzegorz HołowiĔski
Zakład Logistyki i Informatyki
Wydział InĪynieryjno-Ekonomiczny Transportu Akademia Morska w Szczecinie
ul. Henryka PoboĪnego 11
e-mail: g.holowinski@am.szczecin.pl Krzysztof Małecki
Zakład Systemów Komputerowych Instytut Techniczny
PaĔstwowa WyĪsza Szkoła Zawodowa w Gorzowie Wlkp. ul. MyĞliborska 34
