Wsparcie narzędziowe zarządzania ryzykiem · 3) Jasne cele biznesowe 4) Optymalizacja zakresu 5)...

Podyplomowe Studia MenedżerskieZarządzanie projektami informatycznymi

Wsparcie narzędziowe zarządzania ryzykiem w projektach

Spotkanie 1

Zbigniew Misiak (BOC IT Consulting)‏

Wydział Zarządzania UW PSM ZPI

Czym się będziemy zajmować?Wsparcie narzędziowe:Ryzyko – jak z nim postępowaćRyzyko w projektach informatycznychCo radzą praktycy (PRINCE2 i PMBOK)‏

Pomocne narzędzia i oprogramowanie

Lekkie metodyki zarządzania procesami (APM, Scrum)‏

Specyfikacja wymagań

COBIT i ITIL

Podsumowanie technik wspierających zarządzanie ryzykiem w projekcie


Czym się będziemy zajmować?Zarządzanie projektami


Czym się będziemy zajmować?

Triada projektowa

Zakres

Jakość

KosztCzas


Ryzyko, a projekty IT


Czemu projekty się nie udają?


Ryzyko w projektach

Triada projektowa

Symptomy nieudanego projektu IT:LateOver budgetOvertimePoor quality

Zakres

Jakość

KosztCzas


Nieudane projekty

Gartner – 600 mld USD rocznie z powodu źle prowadzonych lub niezrealizowanych projektów IT


Nieudane projekty

Źródło: Standish Group 2006


Czemu projekty się nie udają?

Główne ryzyka dla projektów IT:1) Problemy z harmonogramem2) Inflacja wymagań3) Utrata pracowników4) Niepełne i niespójne specyfikacje5) Niska produktywność

Źródło: Tom DeMarco, Timothy Lister „Waltzing with Bears: Managing Risk on Software Projects”


Co wpływa na sukces?

Główne czynniki sukcesu:1) Zaangażowanie użytkowników2) Wsparcie kierownictwa3) Jasne cele biznesowe4) Optymalizacja zakresu5) Adaptacyjny proces6) Doświadczenie z zakresu zarządzania projektami7) Zarządzanie finansami8) Odpowiednie zasoby9) Metodologia10) Standardowe narzędzia i infrastrukturaŹródło: Standish Group 2006


Ryzyko - definicja

Niepewność co do wystąpienia zdarzenia lub warunku, które jeśli wystąpią, będą miały istotnie negatywny lub pozytywny wpływ na przebieg projektu[PMBOK]

Ryzykiem może być zarówno szansa, jak i zagrożenie.Mierzymy ryzyko z wykorzystaniem prawdopodobieństwa oraz wpływu.


Zarządzanie ryzykiem

Źródło: Project Risk Management Guidelines. Managing Risk in Large Projects and Complex Procurements, Cooper, D., Grey, S., Raymond, G., Walker, P., Wiley&Sons 2005


Kontekst


Co staramy się osiągnąć?W jakim otoczeniu działamy?Czego od nas oczekują?Jakie są kryteria sukcesu (chcemy mierzyć wpływ ryzyk)‏

Ustalenie elementów potrzebnych do analizy i oceny ryzyka

Rezultat:Ustalenie celów i czynników sukcesu


Identyfikacja ryzyk


Co może się stać?Co i w jaki sposób może zagrozić realizacji celów projektu?Jak rozpoznamy, że ryzyko się realizuje?

Rezultat:Pełna lista ryzyk z przypisanymi osobami odpowiedzialnymi


Analiza ryzyk

Co wiąże się z danym ryzykiem?Jak często występują i jakie mają efekty dane ryzyka?

Rezultat:Pełna lista ryzyk z przypisanymi prawdopodobieństwami i skutkami



Ocena ryzyk

Które ryzyka są najistotniejsze?Jak znaczące jest dla nas dane ryzyko?

Rezultat:Lista ryzyk uporządkowana według ich wpływu (prawdopodobieństwo * skutek) z uwzględnieniem ustalonych priorytetów



Postępowanie z ryzykiem

Co robimy ze znaczącymi ryzykami?Ustalanie istniejących opcji postępowaniaOcena ich korzyści i kosztówWybór optymalnego rozwiązaniaStworzenie i implementacja planów postępowania

Rezultat:Plan postępowania dla ryzyk uznanych za istotne



Co możemy zrobić z ryzykiem?

Sposoby postępowania z ryzykiem:1. Unikanie (eliminacja przyczyny)‏2. Redukcja (prawdopodobieństwa / wpływu)‏3. Akceptacja (aktywna/pasywna)‏

4. Transfer


Dobre praktyki

PMBOK (PMI)

PRINCE2 (OGC)


PMBOK a zarządzanie ryzykiemProject Management Body of Knowledge

Project Management Institute (http://www.pmi.org/)‏

Dobre praktyki, a nie metodyka


PMBOKJeden z 9 obszarów wiedzy

Zarządzanie:

1. Integracją

2. Zakresem

3. Czasem

4. Kosztami

5. Jakością

6. Zasobami ludzkimi

7. Komunikacją

8. Ryzykiem

9. Zaopatrzeniem


PMBOK a zarządzanie ryzykiemZarządzanie ryzykiem:

1. Planowanie

2. Identyfikacja

3. Analiza jakościowa

4. Analiza ilościowa

5. Planowanie reakcji

6. Monitoring i kontrola

Źródło: A Guide to the Project Management Body of Knowledge (Third Edition)‏


PMBOK a zarządzanie ryzykiem

Ryzyko:

Niepewność co do wystąpienia zdarzenia lub warunku,

które jeśli wystąpią, będą miały istotnie negatywny lub

pozytywny wpływ na przebieg projektu

[PMBOK]

Techniki wykorzystywane do minimalizacji negatywnego

wpływu zagrożeń można też wykorzystać dla szans

(analiza czy korzystamy z danej szansy, w jaki sposób

etc.)


Planowanie (1/3)

Ustalamy jak zarządzać ryzykiem w projekcie

Wejścia:

1. Czynniki środowiskowe (Enterprise Environmental

Factors) – np. tolerancja ryzyka

2. Zasoby (Organizational Process Assets) – np.

standardowe role lub templatki

3. Zakres projektu

4. Plan projektu



Planowanie (2/3)

Narzędzia i techniki:

1.Spotkania oraz analiza

Wyjścia:

1.Plan zarządzania ryzykiem

Plan zarządzania ryzykiem może i powinien opierać się

na doświadczeniach podobnych projektów z przeszłości

(np. odpowiednie kategorie ryzyk)



Planowanie (3/3)Plan zarządzania ryzykiem:

•Metodologia (jak)‏

•Role i odpowiedzialności (kto)‏

•Budżet (przypisanie potrzebnych zasobów)

•Układ w czasie (kiedy)‏

•Kategorie ryzyk (spójny i kompletny sposób identyfikacji ryzyk –

np. Risk Breakdown Structure)

•Definicja prawdopodobieństwa i wpływu ryzyk (jak będziemy

oceniać ryzyka)

•Macierz prawdopodobieństwa i wpływu – P/I Matrix (co jest dla

nas istotne)

•Tolerancja interesariuszy projektu (na co możemy sobie pozwolić)

•Formatki raportów (jakie będą dokumenty – np. rejestr ryzyk)

•Monitoring (co będziemy dokumentować, czy będą audyty)



PMBOKRBS



Identyfikacja (1/3)

Jakie są ryzyka dla naszego projektu i jakie mają

charakterystyki?

Wejścia:

1.Czynniki środowiskowe (Enterprise Environmental

Factors) – np. tolerancja ryzyka

2.Zasoby (Organizational Process Assets) – np.

standardowe role lub templatki

3.Zakres projektu


5.Plan projektu



Identyfikacja (2/3)



1.Przeglądy dokumentacji

2.Techniki zbierania informacji (brainstorming, metoda

delficka, wywiady, identyfikacja przyczyn – root cause

identification, analiza SWOT)

3.Listy kontrolne (warto jednak się upewnić, że nie

pomijamy czegoś istotnego korzystając z gotowej listy)

4.Analiza założeń

5.Techniki diagramowe (diagramy Ishikawy, diagramy

system opisujące powiązania między elementami

systemu, diagramy wpływu


Identyfikacja (3/3)


Wyjścia:

•Rejestr ryzyk

Rejestr ryzyk:

•Lista zidentyfikowanych ryzyk

•Lista potencjalnych odpowiedzi na ryzyka

•Przyczyny ryzyk

•Zaktualizowane kategorie ryzyk


Analiza jakościowa (1/3)

Które ze zidentyfikowanych ryzyk są priorytetowe

Wejścia:

1.Zasoby (Organizational Process Assets) – np. dane z

poprzednich projektów

2.Zakres projektu


4.Rejestr ryzyk






1.Ocena prawdopodobieństwa i wpływu (np. podczas

warsztatu z udziałem zespołu projektowego i ekspertów

zewnętrznych)

2.Macierz P/I

3.Ocena jakości danych (nie chcemy decydować w

oparciu o wątpliwe przesłanki…)

4.Kategoryzacja ryzyk (w oparciu o źródła ryzyka, WBS,

…)

5.Ocena pilności ryzyk (czy mamy „pożary”?)




Wyjścia:

•Rejestr ryzyk (aktualizacja)


Analiza ilościowa (1/3)

Dokładna analiza najistotniejszych ryzyk wybranych w

analizie jakościowej (jeśli jest to konieczne)

Wejścia:

1.Zasoby

2.Zakres projektu


4.Rejestr ryzyk

5.Plan projektu






1.Zbieranie i obrazowanie danych




Wyjścia:



Planowanie reakcji (1/3)

Ustalamy co robić, aby zredukować zagrożenia celów

projektu (i jak wykorzystać pojawiające się możliwości)

Wejścia:


2.Rejestr ryzyk






1.Strategie wobec zagrożeń (unikanie, transfer,

redukcja)

2.Strategie wobec możliwości (wykorzystanie, podział,

powiększanie)

3.Strategia wobec zagrożeń i możliwości – akceptacja

(aktywna lub pasywna)

4.Plany awaryjne (pamiętając o ustaleniu jakie zdarzenie

uruchamia plan)




Wyjścia:


•Plan projektu (aktualizacja)

•Umowy‏związane‏z‏zarządzaniem‏ryzykiem‏(np.‏polisy)


Monitoring i kontrola (1/3)

Dodawanie informacji o nowych ryzykach, badanie

znanych ryzyk, badanie zdarzeń wyzwalających plany

awaryjne

Wejścia:


2.Rejestr ryzyk

3.Zaaprobowane wnioski o zmianę

4.Informacje o wydajności pracy

5.Raporty o wydajności






1.Okresowa ponowna ocena ryzyka

2.Audyty ryzyka

3.Analiza wariancji i trendu

4.Pomiary‏wydajności

5.Analiza rezerw

6.Spotkania statusowe




Wyjścia:


•Wdrożone‏zmiany

•Rekomendowane‏działania‏naprawcze

•Rekomendowane‏działania‏zapobiegawcze

•Zasoby organizacyjne (aktualizacja)

•Plan‏zarządzania‏projektem‏(aktualizacja)


PRINCE2PRINCE2 - Projects in a Controlled EnvironmentWielka BrytaniaOGC (www.ogc.gov.uk/prince2/)‏

TolerancjaOdpowiedzialnośćWłasność

Źródło: Managing successful projects with Prince2 (2005)‏


PRINCE2Krótkie podsumowanie:UniwersalnaRamy do realizacji projektu oparte na dobrych praktykachNacisk na uzasadnienie biznesowe projektuPlanowanie produktowe, a nie działanioweWspiera zarządzanie ryzykiemSkupia w komitecie sterującym 3 strony: inwestora, użytkownika oraz wykonawcę, którzy odpowiadają za decycje strategiczne (zarządzanie przez wyjątki). Bieżącym zarządzaniem zajmuje się Kierownik Projektu.Zapewnia definicję ról i ich obowiązków


PRINCE2Korzyści:Sprawdzona metodologiaBrak opłat licencyjnychŁatwy dostęp do wiedzyZnaczna uniwersalnośćZapewnia wspólny język dla wszystkich stronMożna łączyć np. z PMBOK

Ale:Niewłaściwie stosowana prowadzi do znacznej biurokracjiJest nastawiona na raczej spokojne środowiska


PRINCE2 – jak to działa?Co jest potrzebne:Uzasadnienie biznesoweUstalony zestaw oczekiwanych produktówUstalony zestaw działań, które pozwolą wytworzyć produktyZasoby do realizacji działań (w określonym czasie trwania)Dopasowanie organizacyjne


PRINCE2 – technikiPlanowanie produktowe:Struktura produktowa – czego potrzebuje KlientNastępstwa produktówPlan działańHarmonogram

Sterowanie zmianami:Decyzje odnośnie zmian są podejmowane przez właściwe osoby i należycie dokumentowane, a ich wpływ na projekt jest analizowany

Przeglądy jakości:Czy produkt spełnia założenia z opisu produktu?


PRINCE2 – komponenty•Uzasadnienie biznesowe (po co jest projekt -> podstawa do decyzji o kontynuacji)•Struktura organizacyjne•Plany•Elementy sterowania•Zarządzanie ryzykiem•Jakość w środowisku projektowym•Zarządzanie konfiguracją•Sterowanie zmianami


PRINCE2 – strukturaRole:Komitet Sterujący (biznes, użytkownik, wykonawca)Kierownik Projektu (PM)Kierownicy Zespołów (wykonawczych)Wsparcie ProjektuNadzór Projektu


PRINCE2 – procesy•Przygotowanie założeń projektu•Inicjowanie Projektu•Sterowanie Etapem•Zarządzanie wytwarzaniem produktów•Zarządzanie zakresem etapu•Zamykanie projektu

Fazy życia projektu:

Pla

now

anie


PRINCE2 – dokumentacjaPRINCE2 zaleca stosowanie systemu dokumentacji projektu. Dokumentacja jest porządkowana w teczki: projektu (np. uzasadnienie biznesowe, rejestr ryzyk), etapu, jakości oraz teczkę merytoryczną (np. konfiguracja)

Analogicznie dokumentowane są wszystkie wymienione wcześniej elementy sterowania:Inicjowanie projektuRaporty o ważnych wydarzeniachRaporty o istotnych odchyleniachOcena odchyleńOcena końcowa etapuZamknięcie projektuTolerancja


PRINCE2 – dokumentacjaPRINCE2 zakłada, że członkowie Komitetu Sterującego nie muszą się angażować w codzienne życie projektu.Podejmują decyzję wyłączenie w wypadku znaczących odstępstw od planu.Obawa o status projektu jest minimalizowana dzięki zapewnieniu im informacji o zdarzeniach wymagających ich uwagi oraz regularnym informacjom (w ramach sterowania etapem)


PRINCE2 – ryzyko



PRINCE2 – ryzyko


Ocena zdrowia projektu – ryzyka:Czy istnieje rejestr ryzyk?Czy jest aktualizowany?Czy dla każdego planu identyfikuje się i analizuje ryzyka oraz odpowiednio działa?Czy jest używana formalna procedura zarządzania ryzykiem?Czy ocena ryzyka jest częścią każdego zakończenia etapu?Czy główne ryzyka były ujęte w uzasadnieniu biznesowym?Czy zostali zidentyfikowani właściciele ryzyk?Czy ryzyka są monitorowane wystarczająco regularnie?Czy ocena ryzyka następuje przy okazji analizowania każdego wniosku o znaczącą zmianę?Czy oceniono prawdopodobieństwo i skutki ryzyk?Czy podjęto odpowiednie działania w celu przeciwstawienia się ryzykom tam, gdzie to konieczne?Czy przygotowano plany awaryjne?Czy objęto wszystkie oczywiste ryzyka?Czy ryzyka i przeciwdziałanie im zostały omówione z Komitetem Sterującym?Czy podjęto odpowiednie działania, gdy było to konieczne?Czy przy zmianie planów dokonano ponownej analizy ryzyk?


PRINCE2Profil ryzyk



Różnica – podejście do zmian

Źródło: PMBOK (2004)


Różnice w podejściach do PMTradycyjne PM

Wiemy co i jak chcemy zrobić oraz jaki będzie czas i budżet. Działamy w oparciu o plan przygotowany na początku.

Adaptacyjne

Wiemy mniej więcej co mamy zrobić, ale metody nie muszą być jasne. Czas i budżet są znane. W miarę jak odkrywamy nowe elementy trzeba modyfikować plany

Ekstremalne

Brak pewności co do celu, metod oraz czasu i budżetu. Odkrywamy na bieżąco.Źródło: Tradycyjne zarządzanie projektami a podejście adaptacyjne i extremalne, Chomicz, Spica


Różnice w podejściach do PM

Tradycyjne PM

•Zdefiniowane wymagania

•Planowanie zadań

•Planowanie i kontrola pracy

•Postęp projektu mierzony w zadaniach wykonanych

•Produkt zgodny z planem

Źródło: Tradycyjne zarządzanie projektami a podejście adaptacyjne i extremalne, Chomicz, Spica

Agile

•Definiowanie wymagań w miarę jak się pojawiają

•Planowanie funkcjonalności

•Samokontrola

•Postęp projektu określa funkcjonalność

•Produkt zaspokajający potrzeby Klienta


Różnice w podejściach do PM

Tradycyjne metodyki skupiają się na zapewnieniu zgodności z pierwotnie stworzonym planem

„Armia zawsze przygotowuje się do poprzedniej wojny”

Metodyki z nurtu Agile zakładają, że wymagania się zmienią i dlatego też zapewniają środowisko w którym łatwo jest wprowadzać zmiany w odpowiedzi na zmieniające się priorytety Klienta


Agile

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the item on the right, we value the items on the left more.

Źródło: http://agilemanifesto.org/


AgileWarto zauważyć, że nie oznacza to całkowitego odrzucenia narzędzi i technik tradycyjnego zarządzania projektami.

Narzędzia te (np. metody zarządzania ryzykiem, system dokumentacji decyzji) mogą być wykorzystywane nadal, ale w innym środowisku projektowym i w oparciu o analizę potrzeb.

Kluczowe staje się budowanie zespołu projektowego.

Proces zarządzania projektem nie ma być powtarzalny, ale rzetelny.

Uwaga poboczna – de facto Klienta interesują rezultaty, a nie metodyka. Chce dostać rezultaty i czuć się bezpiecznie w procesie.


Zasady – na przykładzie APM

Wytwarzanie produktu:

Wytwarzanie iteracyjne oparte na elementach funkcjonalności

Doskonałość techniczna

Dostarczenie Klientowi wartości

Styl zarządzania przywódczo-współpracujący:

Budowa adaptacyjnych zespołów

Upraszczanie

Zachęcanie do eksploracji

Źródło: APM: Agile Project Management, Highsmith


Zasady – na przykładzie APM

Struktura procesu APM:

Źródło: APM: Agile Project Management, Highsmith


Scrum

Scrum:

1986 – Nonaka i Takeuchi „The New New Product Development Game” (HBR)

Początek lat 90-tych – Ken Schwaber, Jeff Sutherland


Scrum - roleRole:Właściciel produktu (zapewnia priorytety dla funkcjonalności zebranych w listę zaległości produktu)Scrum Master (coaching oraz zapewnianie, że zespół ma najlepsze możliwe warunki do pracy)Zespół (5-9 osób; ustalenie podziału pracy)

Grafiki: www.sxc.hu


ScrumJak to działa?

Źródło: Scrum Poster; www.softhouse.se


Scrum - procesLista zaległości – baza funkcjonalności uporządkowana wg. wagi dla KlientaZaległości sprintu – najważniejsze elementy z listy zaległości produktu wybrane do implementacji w sprincie

Codzienne spotkanie Scrum – usuwanie problemów zespołu: co zrobiłem wczoraj, co zrobię dziś, co mi przeszkadzaDemonstracja funkcjonalności wytworzonych w ramach sprintu


Podsumowanie

Ewaluacja i materiały do wykładu:http://ryzyko.wordpress.com/

Kontakt:[email protected]


Podsumowanie

Dziękuję

Wsparcie narzędziowe zarządzania ryzykiem · 3) Jasne cele biznesowe 4) Optymalizacja zakresu 5)...

Documents

Transcript of Wsparcie narzędziowe zarządzania ryzykiem · 3) Jasne cele biznesowe 4) Optymalizacja zakresu 5)...