Wsparcie narz ędziowe zarz ądzania ryzykiemw projektach · Nacisk na uzasadnienie biznesowe...

Wydziałłłł Zarząąąądzania UW PSM ZPI

Wsparcie narzędziowe zarządzania ryzykiem wprojektach

Spotkanie 2

Zbigniew Misiak (BOC IT Consulting)�


Czym się będziemy zajmować?

Podsumowanie spotkania 1

PrzeŜyjmy to jeszcze raz – czyli jak tradycyjnie podchodzi się do ryzyk w projekcie

Agile – nowe sposoby radzenia sobie z wymagającymi projektami

„Czynnik ludzki”

Jak ustalić czego potrzebuje Klient


Podsumowanie spotkania 1Wishlist:-więcej na temat ryzyka w PRINCE2 oraz PMBOK -ryzyko, a testowanie-więcej na temat oprogramowania-praktyczne przykłady zarządzania ryzykami-najczęstsze ryzyka i sposoby postępowania z nimi-definiowanie ryzyk-ITIL -PRINCE2-lekkie metodyki i narzędzia wspomagające-jaśniejsze omówienie róŜnic w metodykach, przykłady-jak rozmawiać z klientem po analizie ryzyka-a gdzie ludzie-ryzyko a intuicja, przeczucie i nos-pamiętnik Tompkinsa


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”


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:

Planowanie

Strategiczne zarządzanie projektem


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

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


PRINCE2 – ryzyko

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

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?


Czemu projekty się nie udają?


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?


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


Czemu ludzie są istotni?„Dobierz sobie odpowiednich ludzi, a wtedy niezaleŜnie od tego jaki popełnisz błąd, ci ludzie cię uratują”

Wymienność ludzi?Tom DeMarco:1) Najlepszy programista10 razy lepszy od najgorszego2) Najlepszy programista2,5 raza lepszy niŜmediana3) Górna połowa2 razy lepsza oddolnej połowy


„Czynnik ludzki”„Najlepsi przywódcy to tacy, których istnienia ludzie nie dostrzegają. Stopień niŜej – to tacy, których ludzie cenią i szanują. Potem tacy, których się boją; wreszcie tacy, których nienawidzą. Kiedy najlepszy z przywódców skończy swą pracę ludzie mówią: 'zrobiliśmy to sami'.”Lao-tse

„Zadaniem menedŜera nie jest zmuszanie ludzi do pracy, a stwarzanie im warunków do pracy”Tom DeMarco


„Czynnik ludzki”Jak zrujnować zespół (Tom DeMarco):1. defensywne zarządzanie2. biurokracja3. fizyczne oddalenie4. rozdrabnianie obowiązków pracowników5. praca nad produktem z którego nie

moŜna być dumnym z powodu kiepskiej jakości

6. "lipny" - nierealny termin projektu („9 kobiet…”)7. przeciwdziałanie powstawaniu klik8. nachalne motywowanie9. praca w nadgodzinach


„Czynnik ludzki”Jak stworzyć warunki do ukształtowania się zespołu

(Tom DeMarco):

1. kult jakości2. zapewnić ludziom świadomość swoich dokonań3. atmosfera elitarności4. dopuszczać i promować róŜnorodność5. utrzymywać i chronić sprawdzone zespoły6. wyznaczać kierunki strategiczne, a nie taktyczne


SpecyfikacjaKlasyczne podejście:Przypadki uŜycia + use case diagrams

Ale moŜna teŜ inaczej: user stories + prototypy + testy

Przykład praktyczny


Podsumowanie

Ewaluacja

Materiały do wykładu:http://ryzyko.wordpress.com/


Podsumowanie

Dziękuję

Wsparcie narz ędziowe zarz ądzania ryzykiemw projektach · Nacisk na uzasadnienie biznesowe...

Documents

Transcript of Wsparcie narz ędziowe zarz ądzania ryzykiemw projektach · Nacisk na uzasadnienie biznesowe...