Wsparcie narzędziowe zarządzania ryzykiem w projektach. Spotkanie 1 Zbigniew Misiak (BOC IT ( Consulting



Podobne dokumenty
Wsparcie narzędziowe zarządzania ryzykiem w projektach

Wsparcie narzędziowe zarządzania ryzykiem w projektach

Wsparcie narzędziowe zarządzania ryzykiem w projektach. Spotkanie 2 Zbigniew Misiak (BOC IT Consulting)

Wsparcie narzędziowe zarządzania ryzykiem w projektach

Wsparcie narzędziowe zarządzania ryzykiem w projektach

Wsparcie narzędziowe zarządzania ryzykiem w projektach. Spotkanie 2 Zbigniew Misiak (BOC IT Consulting)

Wsparcie narzędziowe zarządzania ryzykiem w projektach. Spotkanie 3 Zbigniew Misiak (BOC IT Consulting)

Zarządzanie projektami a zarządzanie ryzykiem

AL 1302 ZARZĄDZANIE PROJEKTAMI W OPARCIU O METODYKĘ PRINCE2

Zarządzanie ryzykiem w projektach informatycznych. Marcin Krysiński marcin@krysinski.eu

Zarządzanie projektami. Porównanie podstawowych metodyk

Wsparcie narzędziowe zarządzania ryzykiem w projektach

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia

Zarządzanie ryzykiem teoria i praktyka. Ewa Szczepańska Centrum Projektów Informatycznych Warszawa, dnia 31 stycznia 2012 r.

Zarządzanie projektami. Wykład 2 Zarządzanie projektem

Projekt. Prince2 PRoject. IN Controlled Environments PROCESY KOMPONENTY TECHNIKI

Zarządzanie Projektami zgodnie z PRINCE2

PRINCE2. Metodyka zarządzania projektami. Na podstawie prezentacji R. Radzik, J. Binkiewicz, K. Kasprzak

Podejście zwinne do zarządzania projektami

Metodyki zarządzania projektami PRINCE2

ZARZĄDZANIE RYZYKIEM W PROJEKTACH

Rekomendacja D w obszarze zarządzania projektami na przykładzie rozwiązań w Banku Polskiej Spółdzielczości S.A.

Agile vs PRINCE /2015 I rok st. magisterskie Informatyka

Spis treści. Konwencja zapisu przyjęta w niniejszym podręczniku

Zarządzanie projektami. Zarządzanie ryzykiem projektu

Wstęp do zarządzania projektami

Szkolenie 1. Zarządzanie projektami

PRINCE2 czy PMI? Czyli o wyŝszości Świąt Wielkanocnych, nad Świętami BoŜego Narodzenia 11 maja Autor: Jolanta Łabędzka-Benisz.

Zarządzanie projektami. Wykład 2 Czym jest zarządzanie projektami?

Zarządzanie zmianą - rozwój zarządzania procesowego wg ISO 9001:2015

Zarządzanie projektami. Wykład 1 Projekt i zarządzanie projektem

Metodyki programowania. Tomasz Kaszuba 2015

Metodyki zwinne wytwarzania oprogramowania

Zarządzanie projektami w NGO

Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation

PODSTAWY ZARZĄDZANIA PROJEKTAMI

Poniższy program może być skrócony do 1 dnia lub kilkugodzinnej prezentacji.

Programowanie zwinne

Zarządzanie projektami. Wykład 1 Projekt i zarządzanie projektem

INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH

Wstęp do zarządzania projektami

Wprowadzenie dosystemów informacyjnych

Szczegółowy opis przedmiotu zamówienia założenia dla metodyki realizacji Projektu

Agile Project Management

Zarządzanie Projektami IT. - Nowoczesny Project Manager Nowość

Projekt: PROLOG wzrost potencjału przedsiębiorstw logistycznych województwa pomorskiego

PRINCE2 Foundation - szkolenie z egzaminem certyfikacyjnym

PROJEKT ZARZĄDZANIE PROJEKT. Przedsięwzięcie powtarzalne, kilkurazowe = PROCES

Poziomy zarządzania projektem w odniesieniu do ról i odpowiedzialności

Podejście tradycyjne. plan wykonanie sekwencyjna natura wykonywanych zadań

PRINCE2. Foundation. v 2017

Szczegółowy opis przedmiotu zamówienia- założenia do metodyki realizacji przedmiotu zamówienia

PRINCE Foundation

Szkolenie Podstawy Zarządzania Projektami Informator

Ryzyko i zarządzanie ryzykiem w projektach

Skuteczne zarządzanie projektami IT w otoczeniu uczelnianym. Piotr Ogonowski

"Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny".

ZARZĄDZANIE PROJEKTAMI. Tomasz Janka KFDZOM Kołobrzeg, 21 września 2017

SYSTEMY INFORMATYCZNE ćwiczenia praktyczne

Podstawy Zarządzania Projektami w Organizacjach

Standardy dotyczące zarządzania projektami (zwane metodyką) tworzone są często w sposób uniwersalny, niezależnie od dziedziny w której projekt jest

Wstęp do zarządzania projektami

MSF. Microsoft Solution Framework

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014

Szkolenie 2. Zarządzanie programami

Zarządzanie projektami - narzędzia, software, dokumentacja, metodyka PMBOK

PROBLEMY WIELOKRYTERIALNE W ZARZĄDZANIU PROGRAMAMI INFORMATYCZNYMI

Zarządzanie projektem prawnym w praktyce

Monitoring procesów z wykorzystaniem systemu ADONIS

Wprowadzenie do zarządzania projektami

Procesowa specyfikacja systemów IT

SYSTEM ZARZĄDZANIA RYZYKIEM W DZIAŁALNOŚCI POLITECHNIKI WARSZAWSKIEJ FILII w PŁOCKU

1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem.

Planowanie i realizacja zadań w zespole Scrum

Scrum w praktyce. Michał Piórek

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

Wprowadzenie do metodyki SCRUM. mgr inż. Remigiusz Samborski Instytut Informatyki Politechnika Wrocławska

Wydział: Zarządzanie i Finanse. Zarządzanie

Spis treści. 00 Red. Spis tresci. Wstep..indd :52:08

ISO 9001:2015 przegląd wymagań

BOC dla KJUF Podsumowanie warsztatów listopada 2011

PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK

Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Foundation

Zarządzanie projektami w otoczeniu uczelnianym. Piotr Ogonowski

Mapa ryzyk w realizacji e-projektu - metody zapobiegania i scenariusze działań w przypadku wystąpienia ryzyka

Akredytowane szkolenia PRINCE2 Foundation & Practitioner

Zarządzanie Projektami Plan kursu

Akademia PMP przygotowanie do egzaminów PMP /CAPM - edycja weekendowa

Koordynacja projektów IT w AGH

CTPARTNERS W LICZBACH ~100% 4,9 >500. kompleksowe obszary zarządzania IT w ofercie. osób przeszkolonych z zakresu IT

RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010

Zarządzanie projektem prawnym w praktyce

Zarządzanie projektami. Wykład 1 - Projekt

Zarządzanie projektami zadaniowymi w oparciu o metodykę PMI

Zarządzenie Nr 24/2012 Rektora Uniwersytetu Wrocławskiego z dnia 28 marca 2012 r. w sprawie Polityki zarządzania ryzykiem

Zarządzanie budowlanym projektem inwestycyjnym dla inwestycji publicznych i komercyjnych

ZARZĄDZANIE PROJEKTAMI

PRAKTYKA ZARZĄDZANIA PROJEKTAMI W OPARCIU O PMBOK GUIDE 5TH.ED.

kompetencji zawodowych Dobrze poprowadzone na bazie PMBOK Guide, 6th Edition Grzegorza Szałajko. zespół Indeed wzmocnić korzyści

OD JAKOŚCI DO TRWAŁOŚCI REZULTATÓW W PROJEKTACH ERASMUS+

Transkrypt:

Wsparcie narzędziowe zarządzania ryzykiem w projektach Spotkanie 1 Zbigniew Misiak (BOC IT ( Consulting

Czym się będziemy zajmować? Wsparcie narzędziowe: Ryzyko jak z nim postępować Ryzyko w projektach informatycznych ( PMBOK Co radzą praktycy (PRINCE2 i Pomocne narzędzia i oprogramowanie ( Scrum Lekkie metodyki zarządzania procesami (APM, Specyfikacja wymagań COBIT i ITIL Podsumowanie technik wspierających zarządzanie ryzykiem w projekcie

Ryzyko w projektach Triada projektowa Jakość Zakres Czas Koszt Symptomy nieudanego projektu IT: Late Over budget Overtime Poor quality

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

Nieudane projekty Źródło: Standish Group 2006

Nieudane projekty Źródło: Standish Group 2006

Czemu projekty się nie udają? Główne ryzyka dla projektów IT: 1) Problemy z harmonogramem 2) Inflacja wymagań 3) Utrata pracowników 4) Niepełne i niespójne specyfikacje 5) 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ów 2) Wsparcie kierownictwa 3) Jasne cele biznesowe 4) Optymalizacja zakresu 5) Adaptacyjny proces 6) Doświadczenie z zakresu zarządzania projektami 7) Zarządzanie finansami 8) Odpowiednie zasoby 9) Metodologia 10) 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ą? ( ryzyk Jakie są kryteria sukcesu (chcemy mierzyć wpływ Ustalenie elementów potrzebnych do analizy i oceny ryzyka Rezultat: Ustalenie celów i czynników sukcesu Ź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

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 Ź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

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 Ź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

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 Ź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

Postępowanie z ryzykiem Co robimy ze znaczącymi ryzykami? Ustalanie istniejących opcji postępowania Ocena ich korzyści i kosztów Wybór optymalnego rozwiązania Stworzenie i implementacja planów postępowania Rezultat: Plan postępowania dla ryzyk uznanych za istotne Ź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

? ryzykiemzzrobićmożemyco Sposoby postępowania z ryzykiem: 1. ( przyczyny Unikanie (eliminacja 2. ( wpływu Redukcja (prawdopodobieństwa / 3. ( aktywna/pasywna ) Akceptacja 4. Transfer

Dobre praktyki PMBOK (PMI) PRINCE2 (OGC)

PMBOK a zarządzanie ryzykiem Project Management Body of Knowledge (/ http://www.pmi.org ) Project Management Institute Dobre praktyki, a nie metodyka

PMBOK Jeden 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 ryzykiem Zarządzanie ryzykiem: 1. Planowanie 2. Identyfikacja 3. Analiza jakościowa 4. Analiza ilościowa 5. Planowanie reakcji 6. Monitoring i kontrola ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

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 ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

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) ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

Planowanie (3/3) Plan zarządzania ryzykiem: ( jak ) Metodologia ( kto ) Role i odpowiedzialności Budżet (przypisanie potrzebnych zasobów) ( kiedy ) Układ w czasie 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) ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

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

PMBOK Macierz P/I

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 4.Plan zarządzania ryzykiem 5.Plan projektu ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

Identyfikacja (2/3) Narzędzia i techniki: 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 ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

Identyfikacja (3/3) Wyjścia: Rejestr ryzyk Rejestr ryzyk: Lista zidentyfikowanych ryzyk Lista potencjalnych odpowiedzi na ryzyka Przyczyny ryzyk Zaktualizowane kategorie ryzyk ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

Identyfikacja Diagram Ishikawy

( 1/3 )jakościowaanaliza Które ze zidentyfikowanych ryzyk są priorytetowe Wejścia: 1.Zasoby (Organizational Process Assets) np. dane z poprzednich projektów 2.Zakres projektu 3.Plan zarządzania ryzykiem 4.Rejestr ryzyk ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

( 2/3 )jakościowaanaliza Narzędzia i techniki: 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?) ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

( 3/3 )jakościowaanaliza Wyjścia: Rejestr ryzyk (aktualizacja) ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

( 1/3 )ilościowaanaliza Dokładna analiza najistotniejszych ryzyk wybranych w analizie jakościowej (jeśli jest to konieczne) Wejścia: 1.Zasoby 2.Zakres projektu 3.Plan zarządzania ryzykiem 4.Rejestr ryzyk 5.Plan projektu ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

( 2/3 )ilościowaanaliza Narzędzia i techniki: 1.Zbieranie i obrazowanie danych ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

( 3/3 )ilościowaanaliza Wyjścia: Rejestr ryzyk (aktualizacja) ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

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: 1.Plan zarządzania ryzykiem 2.Rejestr ryzyk ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

Planowanie reakcji (2/3) Narzędzia i techniki: 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) ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

Planowanie reakcji (3/3) Wyjścia: Rejestr ryzyk (aktualizacja) Plan projektu (aktualizacja) Umowyzwiązanezzarządzaniemryzykiem(np.polisy) ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

Monitoring i kontrola (1/3) Dodawanie informacji o nowych ryzykach, badanie znanych ryzyk, badanie zdarzeń wyzwalających plany awaryjne Wejścia: 1.Plan zarządzania ryzykiem 2.Rejestr ryzyk 3.Zaaprobowane wnioski o zmianę 4.Informacje o wydajności pracy 5.Raporty o wydajności ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

Monitoring i kontrola (2/3) Narzędzia i techniki: 1.Okresowa ponowna ocena ryzyka 2.Audyty ryzyka 3.Analiza wariancji i trendu 4.Pomiarywydajności 5.Analiza rezerw 6.Spotkania statusowe ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

Monitoring i kontrola (3/3) Wyjścia: Rejestr ryzyk (aktualizacja) Wdrożonezmiany Rekomendowanedziałanianaprawcze Rekomendowanedziałaniazapobiegawcze Zasoby organizacyjne (aktualizacja) Planzarządzaniaprojektem(aktualizacja) ( Edition Źródło: A Guide to the Project Management Body of Knowledge (Third

PRINCE2 PRINCE2 - Projects in a Controlled Environment Wielka Brytania (/ www.ogc.gov.uk/prince2 ) OGC Tolerancja Odpowiedzialność Własność ( 2005 ) Źródło: Managing successful projects with Prince2

PRINCE2 Krótkie podsumowanie: Uniwersalna Ramy do realizacji projektu oparte na dobrych praktykach Nacisk na uzasadnienie biznesowe projektu Planowanie produktowe, a nie działaniowe Wspiera zarządzanie ryzykiem Skupia 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

PRINCE2 Korzyści: Sprawdzona metodologia Brak opłat licencyjnych Łatwy dostęp do wiedzy Znaczna uniwersalność Zapewnia wspólny język dla wszystkich stron Można łączyć np. z PMBOK Ale: Niewłaściwie stosowana prowadzi do znacznej biurokracji Jest nastawiona na raczej spokojne środowiska

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

PRINCE2 techniki Planowanie produktowe: Struktura produktowa czego potrzebuje Klient Następstwa produktów Plan 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 struktura Role: Komitet Sterujący (biznes, użytkownik, wykonawca) Kierownik Projektu (PM) Kierownicy Zespołów (wykonawczych) Wsparcie Projektu Nadzór Projektu

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

PRINCE2 dokumentacja PRINCE2 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 projektu Raporty o ważnych wydarzeniach Raporty o istotnych odchyleniach Ocena odchyleń Ocena końcowa etapu Zamknięcie projektu Tolerancja

PRINCE2 dokumentacja PRINCE2 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 ( 2005 ) Źródło: Managing successful projects with Prince2

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? ( 2005 ) Źródło: Managing successful projects with Prince2

PRINCE2 Profil ryzyk ( 2005 ) Źródło: Managing successful projects with Prince2

Różnica podejściedozmian Źródło: PMBOK (2004)

Różnice w podejściach do PM Tradycyjne 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 Agile Definiowanie wymagań w miarę jak się pojawiają Planowanie funkcjonalności Samokontrola Postęp projektu określa funkcjonalność Produkt zaspokajający potrzeby Klienta Źródło: Tradycyjne zarządzanie projektami a podejście adaptacyjne i extremalne, Chomicz, Spica

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/

Agile Warto 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 - role Role: 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

Scrum Jak to działa?

Scrum - proces Lista zaległości baza funkcjonalności uporządkowana wg. wagi dla Klienta Zaległ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 przeszkadza Demonstracja funkcjonalności wytworzonych w ramach sprintu

Podsumowanie Ewaluacja i materiały do wykładu: http://ryzyko.wordpress.com/ Kontakt: zbigniew.misiak@gmail.com

Podsumowanie Dziękuję