Podstawy zarządzania projektami Część II II Dorota Kazanecka Pieńkosz Grupa Antares Warszawa, 30.11.2006 01.12.2006 Plan szkolenia 30.11.2006r. czwartek Omówiliśmy: 1. Wprowadzenie 2. Podstawy zarządzania projektami 3. Metodyka PRINCE2 opis ogólny 4. Podejście procesowe w zarządzaniu projektami Przygotowanie założeń projektu Inicjowanie projektu Strategiczne zarządzanie projektem Sterowanie etapem Zarządzanie wytwarzaniem produktów Zarządzanie zakresem etapu Zamykanie projektu Pytania? - 1
PRINCE2 - Podejście procesowe w zarządzaniu projektami Plan szkolenia 01.12.2006r. piątek 5. Planowanie 6. Organizacja 7. Elementy sterowania 8. Zarządzanie ryzykiem 9. Sterowanie zmianami 10. Zarządzanie jakością 11. Zarządzanie konfiguracją 12. Organizacja systemu gromadzenia akt i zarządzania dokumentacją 13. Podsumowanie - 2
PRINCE2 - komponenty Sterowanie Zmianami Uzasadnienie Biznesowe Zarządzanie Konfiguracją Zarządzanie Jakością Procesy Organizacja Plany Zarządzanie Ryzykiem Elementy Sterowania Plan dnia 09:00 Początek zajęć 1 10:00 Przerwa (15 min) 10:15 Zajęcia 2 11:15 Przerwa (15 min) 11:30 Zajęcia 3 12:30 Przerwa (1 godz.) 13:30 Zajęcia 4 15:30 Koniec zajęć - 3
Planowanie Jeden z 8 procesów metodyki PRINCE2 -wywoływany przez wszystkie pozostałe procesy, Określanie struktury i opracowywanie wszystkich planów Plany komponent PRINCE2 wykorzystywany we wszystkich procesach Planowanie oparte na produktach - podstawowa technika PRINCE2 Szacowanie, planowanie i uaktualnianie planów są nieustannymi i podstawowymi działaniami w zarządzaniu projektem Proces Planowania Zaprojektowanie planu Identyfikacja produktów Analiza produktów Określenie działań i zależności pomiędzy nimi Oszacowania i harmonogramowanie Analiza ryzyka Kompletacja planu Planowanie jest powtarzalnym procesem i odgrywa ogromną rolę w innych procesach - 4
Planowanie Wejścia: Polityka jakości Założenia projektu Produkty: Plan (projektu, etapu, pracy zespołu, naprawczy, jakości, przeglądu poprojektowego) Lista produktów (kontrolna) Uaktualniony rejestr ryzyka Podział projektu na etapy Rozbicie Projektu na Etapy w PRINCE2 jest obowiązkowe Etapy w/g metodyki PRINCE2 to Etapy Zarządcze Etapy to części Projektu z punktami decyzyjnymi Etap jest odrębnym zbiorem aktywności, mającym swój j początek i koniec. Etap zawiera produkty oraz czynności potrzebne na wytworzenie tego produktu Etapy nigdy się nie zazębiają - 5
Podział projektu na Etapy techniczne i zarządcze Etapy zarządcze PRINCE2 Inicjacja W fazie realizacji może być kilka etapów zarządczych Zamknięcie Co najmniej 2 Etapy techniczne metodyka wykonania Faza realizacji projektu Zależą od przyjętej metody wykonania projektu Etapów technicznych w fazie realizacji może być więcej niż zarządczych Etapy techniczne mogą być wykonywane równoległe, na zakładkę Etapy techniczne a zarządcze - 6
Wytyczne podziału na etapy zarządcze Kolejność wytwarzania produktów i półproduktów Grupowanie produktów w jednorodne zestawy Grupowanie produktów w zależności od związanych z nimi procesów Naturalne punkty decyzyjne, powiązane z przeglądami i przydzielaniem zasobów Ryzyko i biznesowa wrażliwość projektu Wielkość projektu Kończenie jednego lub kilku odrębnych procesów Podział na etapy techniczne Zależy od specyfiki projektu (IT, budownictwo,..) Zależy od przyjętej metodyki wykonania projektu Fazy i etapy zdefiniowane w metodyce wykonania Cykl wytwórczy produktu Różne metodyki i podejścia Działania potrzebne do wykonania i odpowiedniej jakości produktów Wielkość projektu Koordynacja z wynikami innych projektów (IT: wykonanie oprogramowania i dostawa sprzętu) Wymagania klienta - 7
Przykład IT podział projektu wykonania systemu IT na etapy techniczne Specyfikacja wymagań systemu Analiza Projektowanie Implementacja Integracja i testowanie oprogramowania Integracja i testowanie systemu Instalacja Wdrożenie Eksploatacja próbna Pielęgnacja (konserwacja) systemu i oprogramowania - przez określony czas PLANY Plan jest podstawą przy kierowaniu projektem PRINCE plan powinien zawierać: Produkty które będą wytwarzane Zadania - Czynności niezbędne do wytworzenia tych produktów Czynności potrzebne do zapewnienia jakości tym produktom Zasoby i czas potrzebny dla wykonania tych czynności Zależności pomiędzy tymi czynnościami Zewnętrzne zależności (informacje, produkty, serwis) Kiedy czynności mają się odbywać Punkty kontrolne w których odbędzie się kontrolowanie postępu prac - 8
Produkty Warunki wstępne Wymagania Jakości Założenia Czynności Zasoby Czas i Koszt Ryzyka Zrewidowane Czynności i Zasobów Punkty Kontrolne Struktura planów - 9
Rodzaje planów w PRINCE2 Plan projektu - ogólny Plan etapu - szczegółowy Plan pracy zespołu Plan naprawczy Plan jakości Plan przeglądu poprojektowego Każde działanie powinno być zaplanowane Poziomy planowania - 10
Opracowanie planów różnego poziomu Plan projektu tworzony jest na początku projektu Weryfikowany i aktualizowany przy końcu każdego etapu Plan pierwszego etapu tworzony jest na początku projektu wraz z planem projektu Plan etapu szczegółowy, dotyczy tylko tego etapu Plan następnego etapu tworzony jest pod koniec poprzedzającego go etapu Plan prac zespołu nieobowiązkowy w PRINCE2 ale bardzo przydatny Planowanie w PRINCE2 oparte na produktach Określenie produktów projektu Produkty właściwe (specjalistyczne, merytoryczne) np.. System IT Produkty Zarządcze (np( np.. DIP, plany, raporty,.) Podział produktów na produkty cząstkowe Opis każdego produktu z kryteriami jakościowymi Terminy dostawy (mogą wynikać z kontraktu) Działania potrzebne do wytworzenia Produkty główne, opisy na poziomie ogólnym na początku w planie projektu Uszczegóławiane w planie etapu, prac zespołu wykonawczego - 11
Identyfikacja i definicja produktów projektu Struktura produktów (workbreakdown workbreakdown structure) Podział na produkty cząstkowe Diagram Struktura produktów Diagram następstwa produktów Opis produktów (w PRINCE iteracyjne ogólny) (w PRINCE dość szczegółowy, metodyki Kryteria jakości dla każdego produktu Lista kontrola produktów (z terminami dostawy) bardzo użyteczna Zadania (Czynności do wykonania) Identyfikacja i opis zadań (czynności) potrzebnych do wytworzenia produktów Oszacowanie pracochłonności poszczególnych zadań Określenie czasu potrzebnego do wykonania zadań Określenie umiejętności niezbędnych do wykonania zadań Określenie ilości zasobów potrzebnych do wykonania zadań Określenie zależności pomiędzy zadaniami Ustawienie zadań w odpowiedniej kolejności Zadania główne, definicje na poziomie ogólnym na początku w planie projektu Uszczegóławiane w planie etapu, prac zespołu wykonawczego - 12
Co należy oszacować? Pracochłonność Harmonogram czas trwania zadań i całego projektu Zasoby ludzkie jak duży zespół Budżet Koszty wynagrodzeń Koszty sprzętu i oprogramowania Koszty materiałów Koszty usług obcych (podwykonawców) Koszty szkoleń, wyjazdów itp. Szacowanie pracochłonności Bardzo ważne, a niełatwe Najważniejsze jest doświadczenie Pomiary pracochłonności, metryki duże firmy wykonawcze Różne metody, specyficzne dla rodzaju projektów Problemy szczególnie w IT Presja terminów Dobre chęci to, co oszacowałeś x 2 Realistyczne szacowanie pracochłonności jest krytyczne dla powodzenia projektu - 13
Szacowanie pracochłonności czynniki do uwzględnienia Złożoność zadania Umiejętności i doświadczenie pracowników Znajomość i dostępność technologii Czas nieproduktywny (praca w innych projektach, administrowanie, wakacje, choroby, szkolenia) Czynności i czas związany z zarządzaniem (spotkania, przygotowywanie raportów, sprawozdań itp.) Czas niezbędny dla komunikacji w zespole Czas przeznaczony na kontrolę jakości (np Audyty, przeglądy, inspekcje) np. Trudności w szacowaniu (IT) Bardzo duże zróżnicowanie i złożoność projektów informatycznych Nieliniowy wzrost złożoności oprogramowania przy zwiększaniu zakresu projektu Zmienność wymagań, środowiska, organizacji przy każdym nowym projekcie Zmienność technologii praktycznie każdy nowy projekt w innej technologii Rosnący udział kosztu opracowania oprogramowania w ogólnych kosztach systemu Niematerialny charakter oprogramowania trudny z natury do oszacowania Brak doświadczenia zespołów projektowych Brak dojrzałych metryk oprogramowania dobrze skorelowanych z procesem tworzenia oprogramowania - 14
Metody szacowania pracochłonności Na zasadzie analogii z podobnymi przedsięwzięciami Szacowanie wstępujące (zadania) Szacowanie zstępujące określenie stopnia pracochłonności zadania względem większej całości (np.. Na zasadzie reguły 40-20 20-40) Standard task method podział zadań względem wielkości i złożoności Ocena ekspertów Metoda delficka Szacowanie algorytmiczne Na podstawie linii kodu Na podstawie struktury programu (np( np.. Metoda punktów funkcyjnych) Użycie i porównanie kilku metod Zalecenia przy szacowaniu Aktualizacja oszacowań Im później szacujemy, tym dokładniej bo mamy więcej informacji (w praktyce zalecenie to sprowadza się do weryfikacji oszacowań) Dekompozycja Możliwość precyzyjniejszego oszacowania mniejszego zadania, modułu itp. Opieranie się na charakterystyce produktywności zespołu konieczność mierzenia produktywności, gromadzenia danych i uaktualniania charakterystyki Stosowanie różnorodnych oszacowań Określanie i dążenie do minimalizacji rozrzutu szacunków - 15
Ustawienie zadań w czasie Czasy rozpoczęcia i zakończenia (terminy, okresy, czas trwania realizacji) Równoległe ścieżki Ścieżka krytyczna (zbiór operacji decydujących o długości projektu, jeśli zadanie krytyczne się opóźni, się cały projekt) Zależy od przyjętej metodyki realizacji produktu Zależności między zadaniami - poprzedniki, następniki Kamienie milowe Techniki (analiza sieciowa) Identyfikacja zasobów ludzkie techniczne Zasoby potrzebne do wykonania zadań i wytworzenia produktów Przydział zasobów ludzkich (nie tylko) do zadań Potrzebne umiejętności Ilość Wyrównywanie obciążenia zasobów Wraz z liczbą pracowników rośnie nakład czasu na komunikację! PRINCE2 nie określa planu dotyczącego zasobów, ale Komitet Sterujący potrzebuje takich informacji Zasoby główne, określenie na poziomie ogólnym na początku w planie projektu Uszczegóławiane w planie etapu, prac zespołu wykonawczego - 16
Harmonogram Określenie ustawienia zadań w czasie Terminy początku, końca, okres trwania Daty (na początku określone jako okresy od rozpoczęcia projektu) Tabela Wykres Gantta najbardziej popularny oprogramowanie (MS Project) Raport wykorzystania zasobów Cel: dostarczenie kompletnego obrazu zasobów i obrazu finansowego przedsięwzięcia (budżet plan i wykorzystanie) Powinien określać: rodzaj, ilość koszt zasobów potrzebnych zużytych do projektu, w rozbiciu na etapy zarządcze projektu Powinien określać także wyposażenie, budynki i inne koszty stałe związane z projektem Tabela Arkusze kalkulacyjne (Ms( Excel) PRINCE2: uzyskany na podstawie komputerowo przygotowanego Planu projektu - 17
Raport wykorzystania zasobów Planowanie i Tolerancje Tolerancje - dopuszczalne odchylenia dla: czasu kosztów jakości, zakresu, korzyści ryzyka w ramach których Kierownik projektu może działać bez odwoływania się do Komitetu sterującego Tolerancję można stosować do dowolnego aspektu projektu, który jest mierzalny - 18
Tolerancje Tolerancje ustala Komitet sterujący dla: Planu Projektu Planów etapów zarządczych Ustalana w celu odzwierciedlenie odpowiedniego ryzyka biznesowego Nie jest zapasem czasu i pieniędzy do beztroskiego wykorzystania! Elastyczność zarządzania i planowania Adaptacja Usprawnienie zarządzania Kierownik projektu bez angażowania komitetu sterującego Tolerancja jest zmienna Zasada praktyczna: tolerancja dla czasu około plus/minus jednego tygodnia dla kosztów plus/minus 10% jest bliska właściwej Planowanie i Tolerancje - 19
Planowanie istotne czynniki sukcesu Realistyczne planowanie! Rygorystyczna kontrola i przestrzeganie zakresu etapu (funkcjonalnego) Tylko uzgodnione wymagania, nie można ulec pokusie (i naciskom!) realizacji dodatkowych wymagań Problemy bo często wymagania są określone na poziomie ogólnym Właściwy dobór odpowiednich zasobów Lekkie planowanie na początku przy planie projektu, bardziej szczegółowe przy planach etapu Plan szkolenia Podstawy zarządzania projektami 5. Planowanie 6. Organizacja 7. Elementy sterowania 8. Zarządzanie ryzykiem 9. Sterowanie zmianami 10. Zarządzanie jakością 11. Zarządzanie konfiguracją 12. Organizacja systemu gromadzenia akt i zarządzania dokumentacją 13. Podsumowanie - 20
Komponent - ORGANIZACJA Dobra struktura organizacyjna projektu jest niezbędna do sukcesu całego przedsięwzięcia Organizacja w PRINCE2 Struktura organizacyjna i opisy ról Przydział osób do konkretnych ról Podstawowe ustalenia w procesie Przygotowanie założeń projektu, w ramach którego wyznaczany jest Przewodniczący Komitetu sterującego Kierownik projektu, proponowany i mianowany zespól zarządzania projektem Skład zespołu zarządzania projektem jest weryfikowany na końcu każdego etapu zarządczego w procesie Zarządzania zakresem etapu - 21
Schemat organizacyjny projektu PRINC2 Komitet sterujący Wszystkie 3 role: Przewodniczący reprezentuje Biznes Ostateczna władza w projekcie Główny Użytkownik (może być kilku) Główny Dostawca musza być zawsze obecne (reprezentuje interes dostawcy, dobrze wybrać jednego) Zarządzanie ogólne i Strategiczne projektu Decydenci Przydzielają zasoby Dbają o interesy projektu w organizacjach, które reprezentują Musza mieć czas! Mają obowiązki wobec projektu i muszą je znać! - 22
Bieżące zarządzanie projektem Najważniejsza osoba w projekcie Kierownik Projektu Otrzymuje wytyczne od Komitetu Sterującego i podlega jego członkom om Dostarcza potrzebnych informacji i wypracowuje rekomendacje do decyzji KS Raportuje do Komitetu Sterującego (postępy projektu, sytuacje wyjątkowe, ) Przekazuje instrukcje wykonawcom, kierownikom zespołów Bieżące planowanie i kontrolowanie prac Zleca rozpoczęcie wykonania zadań Dostarcza wykonane produkty Przywódca Motywuje zespół Powinien znać się na dziedzinie projektu (nie jest to wymaganie PRINCE) Doskonale musi się orientować w realiach projektu, problemach, stanie s aktualnym Czynnik ludzki Bardzo ważny Motywacja i inspirowanie zespołu Marsz ku klęsce, Missin impossible Współpraca z klientem PRINCE2 nie zajmuje się tym aspektem zarządzania projektami Inne metodyki np.. PMI, metodyki extreme poświęcają więcej uwagi Rekomendacja: dodatkowe specjalizowane techniki - 23
Kierownik zespołu W dużych lub złożonych projektach można wyznaczyć jednego lub kilku kierowników zespołów Odpowiedzialność za zapewnienie, aby produkty jednego lub kilku określonych etapów prac technicznych lub wykonanie specjalistycznych grup zadań zostały zaplanowane, kontrolowane i wytworzone zgodnie z harmonogramem oraz z określonymi i uzgodnionymi standardami jakości, w ramach budżetu Rola Kierownika zespołu w PRINCE2 jest nieobowiązkowa Występuje gdy Kierownik projektu nie posiada merytorycznych kwalifikacji potrzebnych do planowania lub sterowania specyficznymi częściami projektu Określenie Lidera zespołu bardzo pomaga Kierownik Zespołu Kierownik Projektu Wsparcie Projektu Kierownik Zespołu Kierownik Zespołu Kierownik Zespołu Zasoby Projektu i Zespoły - 24
Zespoły specjalistyczne Zespoły specjalistów, których zadaniem jest wykonywanie określonych działań i tworzenie produktów etapu Organizacja zespołu, zakresy odpowiedzialności i ich przypisanie do poszczególnych osób zależy od rozmiaru i charakteru projektu, jak też różnorodności dostępnych umiejętności PRINCE2 widzi potrzebę ustanowienia roli kierownika zespołu w projektach, w których ma to sens i jest właściwe Problem dwu zespołów środowisko Klienta i Dostawcy po stronie użytkownika (Odbiorcy) sponsor (komitet sterujący) zespół projektowy kierownik (dyrektor) projektu po stronie wykonawcy (Dostawcy) sponsor (komitet sterujący) zespół projektowy kierownik (dyrektor) projektu Tak jest w rzeczywistości, aby nie było konfliktów podczas realizacji zadania Wymogi PRINCE2 jeden wspólny komitet sterujący, przewodniczący i kierownik projektu - 25
Schemat organizacyjny projektu PRINCE2 w środowisku klienta i dostawcy PRINCE2 w zespole projektu część ról obsadzona jest przez dostawcę, część przez klienta Nadzór projektu PRINCE2 odpowiedzialność każdego z członków komitetu sterującego Nadzór nad: Standardami zarządzania projektem Standardami zarządzania jakością Podejściem do projektu Przestrzeganiem zasad etycznych Odpowiedzialności delegować nie można Wsparcie ekspertów delegowanie bieżących czynności nadzoru Ważne: niezależny od kierownika projektu Kierownik może mieć swojego eksperta, bieżące zapewnienie jakości Czy wszystko przebiega tak, jak jest informowany Komitet Sterujący? - 26
Plan szkolenia Podstawy zarządzania projektami 5. Planowanie 6. Organizacja 7. Elementy sterowania 8. Zarządzanie ryzykiem 9. Sterowanie zmianami 10. Zarządzanie jakością 11. Zarządzanie konfiguracją 12. Organizacja systemu gromadzenia akt i zarządzania dokumentacją 13. Podsumowanie Komponent ELEMENTY STEROWANIA Kontrola - podejmowanie decyzji Planuj Monitoruj Kontroluj - 27
Elementy sterowania Przykłady Zezwolenia Komitetu Sterującego: Zezwolenie na inicjację projektu Zezwolenie na rozpoczęcie etapu Zamknięcie projektu Zgoda na wykonanie grupy zadań Raporty Kierownika Projektu do Komitetu Sterującego Raport o ważnych zdarzeniach Raport o odchyleniach Oceny decyzyjne Inne Ocena końcowa etapu Ocena nadzwyczajna Tolerancje Punkty kontrolne Przeglądy jakości Zarządzanie dokumentacją PRINCE2 wykorzystanie elementów sterowania Wszystkie procesy wykorzystują komponent Elementy sterowania Szczególnie: Inicjowanie projektu,, w ramach którego jest ustalana ogólna struktura sterowania projektem Sterowanie etapem,, wykorzystuje: Raporty z punktów kontrolnych do odnotowywania postępu i rejestracji faktycznego wykorzystania zasobów Raporty o ważnych zdarzeniach służą do informowania Komitetu sterującego o postępie prac Zarządzanie wytwarzaniem produktów raporty z punktów kontrolnych służące celom kontroli Zarządzanie zakresem etapu Zatwierdzanie etapów w wyniku oceny końcowej etapu Raporty o odchyleniach informowanie o sytuacjach alarmowych Strategiczne zarządzanie projektem podejmowane są decyzje o wszelkich zezwoleniach W tym celu wykorzystuje on takie elementy, jak: Ocena końcowa etapu. Ocena odchyleń, Tolerancje, Inicjowanie projektu i Zamykanie projektu - 28
Raporty o ważnych zdarzeniach Cel: informowanie Komitetu sterującego o postępach prac w stosunku do planów przyjętych dla poszczególnych etapów zarządczych, i dla całego projektu Przygotowywane przez Kierownika projektu Raporty regularne, przekazywane w określonych terminach Zazwyczaj co miesiąc, ale ich częstotliwość powinna być zawsze uzgodniona z Komitetem sterującym Zawiera: oświadczenie o postępie osiągniętym w ostatnim okresie (zwykle miesięcznym) zestawienie problemów występujących w ostatnim okresie wraz z opisem podjętych działań potwierdzenie działań i produktów, które mają być wykonane w następnym okresie oświadczenie o sytuacji finansowej i realizacji harmonogramu dla całego projektu oraz dla aktualnego etapu zarządczego Ocena końcowa etapu Jest to obowiązkowy zarządczy element sterowania występujący na końcu każdego etapu zarządczego Przygotowywany przez kierownika projektu Cel: Zakończenie etapu, wydanie zgody na realizację następnego Zanim projekt przejdzie do następnego etapu, musi uzyskać akceptację Komitetu sterującego, uzgodnioną przez wszystkich jego członków - 29
Ocena końcowa etapu Zwykle składa się z formalnej prezentacji Komitetowi sterującemu: Aktualnego statusu projektu Przeglądu pełnego uzasadnienia biznesowego (korzyści i ryzyka) Akceptacja planów proponowanych dla następnego etapu przez komitet sterujący Decyzja co do ewentualnego rozpoczęcia następnego etapu Raport o istotnych odchyleniach Opracowywany prze Kierownika Projektu, w sytuacjach, kiedy przewiduje się, że koszty lub terminy wyjdą poza tolerancje określone przez Komitet sterujący Cel: jak najszybsze zaalarmowanie Komitetu sterującego, kiedy tylko t stanie się widoczne, że przewidywane jest znaczące odchylenie od przyjętego planu Raport o odchyleniach opisuje: zaistniałe okoliczności przyczynę odchylenia od planu jego konsekwencje dla etapu, całego projektu, uzasadnienie biznesowe rekomenduje Komitetowi sterującemu działania korygujące, aby w miarę możliwości uzyskać poprawę sytuacji lub wcześniejsze zamknięcie! KS po rozpatrzeniu Raportu zleca KP ewentualne przygotowanie planu naprawczego Plan naprawczy jest rozpatrywany przez Komitet sterujący w trakcie Oceny nadzwyczajnej - 30
Ocena nadzwyczajna Służy do zbadania przez Komitet Sterujący znaczących odchyleń od zatwierdzonego planu etapu i podjęciu decyzji o: Zatwierdzeniu planu naprawczego etapu Wcześniejszym zamknięciu projektu Kierownik projektu opracowuje plan naprawczy etapu na żądanie Komitetu sterującego w następstwie Raportu o Odchyleniach Po zatwierdzeniu, plan naprawczy zastępuje część planu aktualnego etapu, jaka pozostała jeszcze do realizacji Plan szkolenia Podstawy zarządzania projektami 5. Planowanie 6. Organizacja 7. Elementy sterowania 8. Zarządzanie ryzykiem 9. Sterowanie zmianami 10. Zarządzanie jakością 11. Zarządzanie konfiguracją 12. Organizacja systemu gromadzenia akt i zarządzania dokumentacją 13. Podsumowanie - 31
Ryzyko Możliwość wystąpienia niepomyślnych przyszłych zdarzeń i ich konsekwencje Dwa rodzaje ryzyka: Ryzyko Biznesowe Ryzyko Projektowe Możliwość, prawdopodobieństwo, że coś się nie uda (zagrożenie) Typowe źródła ryzyka charakter projektu duży stopień złożoności napięte (mało elastyczne) terminy długi czas trwania projektu duże prawdopodobieństwo znacznych zmian (technologii, pracowników, otoczenia, kierownictwa, prawa, itd.) zbyt optymistyczny budżet nieznana, nie wypróbowana nowa technologia środowisko zespołu wykonawczego doświadczenie i umiejętności zespołu (merytoryczne, w metodykach prowadzenia projektu, w zarządzaniu, itd.) motywacja i zaangażowanie zespołu zdrowie fizyczne i psychiczne koordynacja duża liczba kooperantów (dostawców, podwykonawców itd.) rozmieszczenie miejsc realizacji projektu środowisko klienta zaangażowanie klienta w projekt (specyfikacja wymagań, zmiany wymagań, komunikacja) poziom wiedzy użytkowników organizacja klienta liczba komórek objętych projektem konieczność wprowadzenia reorganizacji czynniki zewnętrzne - 32
Kategorie ryzyka znane gdy wystąpienie zagrożenia jest prawie pewne; przewidywalne gdy wystąpienie zagrożenia jest prawdopodobne i może być wcześniej wykryte/rozpoznane; nieprzewidywalne gdy wystąpienia zagrożenia nie można przewidzieć z wyprzedzeniem (przypadki losowe).! Zarządzanie ryzykiem zajmuje się dwiema pierwszymi kategoriami tzn. ryzykiem znanym oraz przewidywalnym koncentruje się na: wczesnym wykrywaniu możliwego ryzyka i działaniach zapobiegawczych, nie zaś na usuwaniu skutków powstałych problemów - 33
Zarządzanie Ryzykiem Analiza Ryzyka Zarządzanie Ryzykiem Identyfikacja Oszacowanie Ewaluacja Określenie reakcji Wybór reakcji Planowanie Przydzielanie Zasobów Kontrolowanie Monitorowanie i raportowanie Identyfikacja ryzyka analiza źródeł ryzyka charakter projektu klient wykonawcy podwykonawcy procesy zarządzania i tworzenia oprogramowania technologia (sprzęt, oprogramowanie) inne czynniki wewnętrzne i zewnętrzne wywiady, warsztaty, burze mózgów listy kontrolne kwestionariusze oceny zagrożeń (ryzyka) informacja archiwalna z poprzednich projektów analogie do znanych przypadków eksperymenty lub testy (np( np.. nowej technologii) - 34
Strategie zarządzania ryzykiem Unikanie ryzyka eliminacja zagrożeń, np.. Przez usuwanie ich przyczyn, rezygnację z ryzykownych alternatyw Łagodzenie wpływu ryzyka Redukcja prawdopodobieństwa wystąpienia, np.. Poprzez wprowadzenie redundancji, prototypowanie, wybór standardowych rozwiązań Redukcja wartości strat Przenoszenie ryzyka np.. Na inny etap, na klienta (ujmując to w umowie) lub inną instytucję (ubezpieczenie) Akceptacja ryzyka zgoda na skutki ryzyka Ustalenie procedury działania w przypadku wystąpienia zagrożenia Śledzenie poziomu ryzyka Zarządzanie ryzykiem Zidentyfikowane ryzyko jest rejestrowane przez Kierownika Projektu w Rejestrze Ryzyka Może on zawierać, np: Lista zidentyfikowanych czynników ryzyka Waga (Prawdopodobieństwa wystąpienia x istotność wpływu na projekt Możliwe skutki wystąpienia Propozycje działań zapobiegawczych lub łagodzących skutki Wpis o podjęciu działań zapobiegawczych i ich skutkach Aktualizacja rejestru! - 35
Szacowanie ryzyka Prawdopodobieństwo wystąpienia parametry liczbowe podział na kategorie np.. prawdopodobieństwo bardzo wysokie, wysokie,, średnie, niskie, bardzo niskie Skutki wystąpienia liczone w pracochłonności, koszcie, opóźnieniu, jakości produktu itp. podział na kategorie np.. skutki katastrofalne, duże, średnie, małe Określenie wagi ryzyka waga ryzyka = (prawdopodobieństwo) (skutek) na podstawie macierzy wag np.. ryzyko wysokie, średnie, niskie, nieistotne, itp. Reprezentacja w tabeli - prosta Identyfikacja i Szacowanie ryzyka - problemy Trudności w zidentyfikowaniu Polityka! 2 listy ryzyka klienta i dostawcy (nie ujawniamy słabości drugiej stronie) Podwładny a kierownictwo Trudności w szacowaniu prawdopodobieństwa i skutków Niedoszacowanie! - 36
Zarządzanie ryzykiem w projekcie PRINCE2 Ocena ryzyka jest przeprowadzana początkowo w ramach Przygotowania założeń projektu,, kiedy tworzone są założenia projektu i jest zakładany Rejestr ryzyka Wstępnie zidentyfikowane ryzyka są doprecyzowane w inicjowaniu projektu,, kiedy powstaje Uzasadnienie biznesowe Analiza ryzyka jest uaktualniana w trakcie Zarządzania zakresem etapu,, w celu stworzenia podstawy dla decyzji podejmowanych przez Komitet sterujący Komitet sterujący, w ramach Zarządzania strategicznego projektem podejmuje decyzje (np( np.. o przejściu do następnego etapu) m.in., na podstawie przygotowanych przez Kierownika Projektu rejestru ryzyka Zarządzanie ryzykiem Zarządzanie ryzykiem ściśle wiąże się z korzyściami biznesowymi, które są określone i przedstawione w Uzasadnieniu biznesowym Są rozpatrywane razem Zarówno Uzasadnienie biznesowe, jak i analiza ryzyka są uaktualniane przez Kierownika Projektu przynajmniej na koniec każdego etapu zarządczego (w trakcie przygotowań do Oceny końcowej etapu lub Oceny nadzwyczajnej) PRINCE nie zaleca żadnych konkretnych narzędzia do analizy ryzyka - 37
Plan szkolenia Podstawy zarządzania projektami 5. Planowanie 6. Organizacja 7. Elementy sterowania 8. Zarządzanie ryzykiem 9. Sterowanie zmianami 10. Zarządzanie jakością 11. Zarządzanie konfiguracją 12. Organizacja systemu gromadzenia akt i zarządzania dokumentacją 13. Podsumowanie Sterowanie Zmianami Wszystkie potencjalne zmiany są traktowane jako problemy projektowe Zmiany w specyfikacji czy zakresie projektu mogą zrujnować projekt Zmiany są bardzo prawdopodobne Muszą być kontrolowane Mogą być wprowadzane jedynie w sposób zdyscyplinowany, w oparciu o formalne procedury Muszą być zarejestrowane w rejestrze zmian Konieczne jest uzgodnienie działań w celu określenia wpływu zmiany a także uniknięcia znacznych odstępstw od planu - 38
Sterowanie zmianami Wychwytywane propozycji zmian Oszacowywanie wpływu na projekt Podejmowane wynikających z tego działań Sterowanie zmianami w PRINCE2 Właściwa obsługa propozycji wprowadzenia zmian w projekcie jest istotnym aspektem zarządzania projektem W szczególności procesu sterowanie etapem Propozycje zmian, jako zagadnienia projektowe najlepiej jest rozwiązywać w ramach formalnego schematu zarządzania konfiguracją - 39
Przykłady propozycji zmian Nieplanowane sytuacje związane ze zmianami w jednym lub kilku produktach Usprawnienia sugerowane przez członków zespołu Zmiany wymagań zgłaszane przez użytkowników / klientów Zmiany zasobów Błędy wykryte w zakończonych produktach Wykryte odstępstwa od uzgodnionej specyfikacji Nieplanowane sytuacje w otoczeniu, mające wpływ na produkty lub proces wytwórczy (np( np.. Projekty powiązane) Plan szkolenia Podstawy zarządzania projektami 5. Planowanie 6. Organizacja 7. Elementy sterowania 8. Zarządzanie ryzykiem 9. Sterowanie zmianami 10. Zarządzanie jakością 11. Zarządzanie konfiguracją 12. Organizacja systemu gromadzenia akt i zarządzania dokumentacją 13. Podsumowanie - 40
Zarządzanie jakością Służy do oceny produktu lub półproduktu poprzez sprawdzenie jego zgodności z uzgodnionymi i zapisanymi standardami jakości Zarządzanie Jakością w PRINCE2 Zgodność z ISO 9001 Możliwość wykorzystania istniejącego w firmie Systemu Jakości Planowanie jakości definiowanie wymogów jakościowych od najwcześniejszych faz projektu Kontrola Jakości sprawdzanie czy Produkty są zgodne z wymogami Jakości Przegląd Jakości (Quality( Review) technika używana przez Prince - 41
Przeglądy jakości w PRINCE2 PRINCE2 dopuszcza: nieformalne przeglądy jakości (zwykle: sprawdzenie przy biurku, testy zespołu lub inspekcja wizualna) formalne przeglądy jakości (bardziej ustrukturyzowane,, pełne przeglądy produktu) Formalny przegląd jakości składa się z trzech odrębnych faz: przygotowania, narady przegląd jakości działań następczych (naprawa błędów) Uwaga: działania związane z przeglądami jakości i działaniami następczymi zużywają zasoby, czas i musza być uwzględnione w planach projektu i harmonogramamch Działania związane z jakością powinny być zapisywane w Rejestrze Jakości Plan jakości w PRINCE2 Plan działań opracowany w celu zapewnienia, że projekt może wytworzyć produkty zgodnie ze standardami jakości oczekiwanymi przez klienta (wyrażonymi w Jakościowych oczekiwaniach klienta) Kryteria jakości muszą być określone i uzgodnione, dla wszystkich zidentyfikowanych, istotnych produktów, na przykład dla produktów na poziomie projektu i etapów zarządczych Muszą być włączone w Opis produktu (Plan projektu) Należy opracować, opublikować i przyjąć: Plan jakości projektu, a później Plany jakości dla etapów zarządczych Należy określić procedury przeglądów jakości Należy wyszkolić personel do ich właściwego przeprowadzenia Czasem niezbędna budowa środowiska testowego (system IT: serwer testowy, tworzenie danych testowych, scenariusze testowe) Wszelkie działania proponowane w celu wbudowania jakości w projekt muszą być spójne z Systemem zarządzania jakością (SZJ), który już funkcjonuje w instytucji - 42