PRINCE2® (PL) - Skuteczne Zarządzanie Projektami

1. Role Projektowe (10)

1.1. Role projektowe są ściśle związane z tematem Organizacja

1.2. Struktura zespołu zarządzania projektem według PRINCE2®

1.3. Komitet Sterujący (KS) (3)

1.3.1. reprezentuje 3 strony interesów

1.3.1.1. strona klienta

1.3.1.1.1. Główny Użytkownik(-cy)

1.3.1.2. strona biznesu

1.3.1.2.1. Przewodniczący

1.3.1.3. strona dostawcy

1.3.1.3.1. Główny Dostawca(-cy)

1.3.2. Najmniejsza forma KS to jedna osoba pełniąca wszystkie role KS tj, będąca zarazem Przewodniczącym, Głównym Użytkownikiem oraz Głównym Dostawcą

1.3.2.1. to sytuacja typowo teoretyczna, nierealna w praktyce

1.3.3. Komitet Sterujący realizuje zarządzanie strategiczne projektem – co oznacza podejmowanie kluczowych decyzji i wyznaczanie kierunków działania.

1.3.4. Komitet Sterujący powinien składać się z osób, które są upoważnione do podjęcia wszystkich potencjalnych decyzji w ramach projektu.

1.3.5. Komitet Sterujący to organ, który ostatecznie zatwierdza zakończenie każdego etapu i zezwala na rozpoczęcie etapu następnego.

1.3.6. Zapewnia, aby zostały przydzielone niezbędne zasoby, oraz jest arbitrem we wszelkich konfliktach w projekcie i negocjuje rozwiązania wszelkich problemów, dotyczących projektu i podmiotów zewnętrznych.

1.3.7. Zatwierdza nominacje i obowiązki Kierownika Projektu oraz delegowanie swoich obowiązków związanych z Nadzorem Projektu.

1.3.8. K. S. ponosi całościową odpowiedzialność za projekt zgodnie z instrukcjami organizacji/programu

1.3.8.1. odpowiedzialny za "sukces projektu"

1.3.9. Dla wtajemniczonych...

1.3.9.1. Komitet Sterujący odbierający kolejne raporty Kierownika Projektu

1.3.9.2. Komitet Starujący ustalający tolerancje projektu (budżet, terminy, etc.)

1.4. Nadzór Projektu (NP) (3)

1.4.1. Nadzór projektu oznacza delegowanie czynności Komitetu Sterującego związanych z zapewnieniem, że projekt jest realizowany właściwie. (Komitet Sterujący pozostaje wciąż odpowiedzialny za nadzorowanie projektu)

1.4.1.1. Nadzór Projektu musi być niezależny od Kierownika Projektu i Kierowników Zaspołów, dlatego Komitet Sterujący nie może delegować Kierownikowi Projektu żadnych ze swoich obowiązków nadzorczych.

1.4.2. Nadzór projektu nadzoruje zarazem Kierownika Projektu jak i Kierowników Zespołów

1.4.2.1. Dlatego musi być od nich niezależny, aby nie istniał konflikt interesów (nadzór samego siebie)

1.4.3. Wypełnianie obowiązków związanych z nadzorem wymaga odpowiedzi na pytanie: „Co ma być nadzorowane?”.

1.4.3.1. Lista możliwości mogłaby objąć zapewnienie, że:

1.4.3.1.1. w ciągu całego projektu utrzymywana jest ścisła łączność między Głównym Dostawcą / Wykonawcą a Klientem,

1.4.3.1.2. potrzeby i oczekiwania użytkownika są spełniane lub zarządzane,

1.4.3.1.3. zagrożenia są kontrolowane,

1.4.3.1.4. Uzasadnienie Biznesowe jest przestrzegane,

1.4.3.1.5. przyjmowane rozwiązania są stale oceniane z punktu widzenia dostarczania wartości, usprawiedliwiającej poniesione koszty,

1.4.3.1.6. projekt jest zgodny z Wizja, Misją i Strategią Organizacji,

1.4.3.1.7. właściwe osoby biorą udział w tworzeniu Opisów Produktów,

1.4.3.1.8. zaplanowano zaangażowanie właściwych osób do kontroli jakości we właściwych momentach wytwarzania produktu,

1.4.3.1.9. personel jest właściwie przeszkolony w zakresie procedur kontroli jakości,

1.4.3.1.10. właściwe osoby biorą udział w kontroli jakości,

1.4.3.1.11. procedury przeglądów / kontroli jakości są właściwie realizowane,

1.4.3.1.12. działania następcze, wynikające z kontroli jakości, prowadzone są prawidłowo,

1.4.3.1.13. realizowane rozwiązanie jest możliwe do zaakceptowania,

1.4.3.1.14. prowadzenie projektu jest nadal uzasadnione,

1.4.3.1.15. zakres projektu nie poszerza się niepostrzeżenie,

1.4.3.1.16. komunikacja wewnętrzna i zewnętrzna funkcjonuje zadowalająco,

1.4.3.1.17. używane standardy są właściwe i możliwe do zastosowania,

1.4.3.1.18. przestrzegane są wszystkie ograniczenia prawne,

1.4.3.1.19. spełniane są wymogi specjalistyczne (np. bezpieczeństwa),

1.4.3.1.20. przestrzega się standardów zapewnienia jakości.

1.4.3.1.21. ...

1.4.4. dzieli się na 3 obszary

1.4.4.1. Nadzór ze strony biznesu

1.4.4.1.1. jest to nadzór w imieniu Przewodniczącego

1.4.4.2. Nadzór ze strony dostawcy

1.4.4.2.1. jest to nadzór w imieniu Głównego Dostawcy

1.4.4.3. Nadzór ze strony użytkownika

1.4.4.3.1. jest to nadzór w imieniu Głównego Użytkownika

1.4.5. Rola wymagana

1.4.5.1. Pomimo delegowania czyności związanych z nadzorem projektu, odpowiedzialność za ich realizację pozostaje wciąż w ramach KS

1.5. Obsługa Zmian (OZ)

1.5.1. Rola decyzyjna w sprawie zagadnień typu - wniosek o wprowadzenie zmian.

1.5.2. OZ znajduje się nad KP w kwestii uprawnień o wprowadzenie zmian

1.5.2.1. KP przesyła wnioski o wprowadzenie zmiany (w postaci Raportu o Zagadnieniu) do OZ z prośbą o podjęcie decyzji (akceptację, odrzucenie, odroczenie decyzji)

1.5.3. Rola wymagana

1.5.3.1. Pomimo delegowania czyności związanych z nadzorem projektu, odpowiedzialność za ich realizację pozostaje wciąż w ramach KS

1.5.3.2. W szczególnych przypadkach, KS może przekazać rolę OZ dla KP

1.5.4. Procesu obsługi zmian nie należy utożsamiać z rolą Obłsuga Zmian

1.5.4.1. Proces obsługi zmian w PRINCE2® może odbywać się na 4 poziomach:

1.5.4.1.1. Organizacja

1.5.4.1.2. KS

1.5.4.1.3. OZ

1.5.4.1.4. KP

1.5.4.1.5. Co oznacza niski / średni / wysoki priorytet oraz kto obsługuje jaki priorytet musi zostać opisany w produkcie zarządczym A.6 w zgodzie z 7 prycypium - Dostosowanie do warunków projektu

1.6. Kierownik Projektu (KP)

1.6.1. Rola wymagana

1.6.2. Rola niepodzielna, zawsze 1 Kierownik Projektu

1.6.3. KP może pochodzić z organizacji klienta, dostawcy, być zatrudniony jako konsultant, PRINCE2® nie definiuje ograniczeń odnośnie pochodzenia i powiązań KP

1.6.4. Kierownik Projektu nie może być łączony z Przewodniczącym Komitetu Sterującego oraz z Nadzorem Projektu

1.6.5. Codzienne planowanie oraz sterowanie realizacją bieżących zadań oraz podejmowanie decyzji w drobnych sprawach należy do Kierownika Projektu.

1.6.5.1. Kierownik Projektu posiada uprawnienia do bieżącego prowadzenia projektu w imieniu Komitetu Sterującego, w ramach ograniczeń określanych przez ten Komitet Sterujący.

1.6.5.2. Projektu. Kierownik Projektu odpowiada przed Przewodniczącym Komitetu Sterującego za terminowe i prawidłowe dostarczenie produktów projektu.

1.6.6. Podstawowym obowiązkiem Kierownika Projektu jest zapewnienie, aby projekt wytwarzał wymagane produkty, zgodne z wymaganymi standardami jakości oraz w ramach określonych ograniczeń czasu i kosztów.

1.6.7. Kierownik Projektu jest także odpowiedzialny za to, żeby projekt wytworzył rezultat, który będzie zdolny do osiągnięcia korzyści biznesowych zdefiniowanych w Uzasadnieniu Biznesowym.

1.6.8. Odpowiedzialny za osiągnięcie CELÓW projektu (dostarczenie produktów specjalistycznych)

1.6.8.1. CELÓW nie SUKCESU projektu

1.6.9. Dla wtajemniczonych ...

1.6.9.1. (miś) Kierownik Projektu jest odpowiedzialny za ustalenie Strategi Zarządzania Komunikacją

1.6.9.1.1. https://www.youtube.com/watch?v=kdfq98BaMUU

1.6.9.1.2. (miś) "Wzajemna przyjaźń i zaufanie podstawą prawidłowego funkcjonowania podstawowej komórki społecznej rodziny"

1.6.9.2. (Co mi zrobisz jak mnie złapiesz) Kierownik Projektu dba, aby projekt trzymał się w ustalonych tolerancjach.

1.6.9.2.1. https://www.youtube.com/watch?v=Omo-JU08hXg

1.6.9.3. (miś) "Panowie pozwolą... mój projekt... PRINCE!"

1.6.9.3.1. https://www.youtube.com/watch?v=0QTuJO4lhyk

1.6.9.4. Nowy Kierownik Projektu na pokładzie :-)

1.6.9.5. Reakcja Kierownika Projektu po zatwierdzeniu zwiększenia budżetu projektowego :-)

1.7. Kierownik Zespołu (KZ)

1.7.1. Wytwarza produkty specjalistyczne

1.7.2. W przypadku rozbudowanych projektów poszczególne elementy projektu realizują wyodrębnione zespoły.

1.7.2.1. W takim przypadku do kierowania tymi zespołami powoływany jest Kierownik Zespołu.

1.7.3. Podstawowym obowiązkiem Kierownika Zespołu jest zapewnienie wytworzenia określonych przez Kierownika Projektu produktów o właściwej jakości, terminowo oraz po koszcie akceptowalnym dla Komitetu Sterującego.

1.7.4. Kierownik Zespołu podlega Kierownikowi Projektu i przyjmuje od niego instrukcje.

1.7.5. Przygotowuje Raporty z Punktów Kontrolnych

1.7.6. Rola wymagana, ale ...

1.7.6.1. Jeśli nie jest delegowana, odpowiedzialność przejmuje KP

1.7.7. Dla wtajemniczonych ...

1.7.7.1. zwany również jako Wesoły Romek

1.7.7.1.1. (miś) "Dzień dobry, cześć i czołem! Pytacie skąd się wziąłem?! Jestem wesoły Romek, mam na przedmieściu domek, w tym domku prąd i gaz to ukończę PRINCa w czas."

1.7.7.1.2. (miś) "Panie kierowniku, ja to wszystko rozumiem... Ja rozumiem, że zmiana jest potrzebna, ale jak jest zmiana to musi być budżet! Tak? Panie kierowniku, takie jest odwieczne prawo natury!"

1.7.7.2. (miś) "A niech żesz Pan siada i opowiada! Nowiny! Nowiny!"

1.8. Wsparcie Projektu (WP)

1.8.1. Rola, która dostarcza jedynie wsparcie administracyjne, bez jakichkolwiek uprawnień decyzyjnych.

1.8.2. Rola wymagana, ale ...

1.8.2.1. Jeśli nie jest delegowana, odpowiedzialność przejmuje KP

1.8.3. Rola, którą domyślnie pełni KP

1.8.3.1. Rola domyślnie jest łączona z rolą KP

1.8.4. Role o najmniejszych uprawnieniach w całym projekcie (porównując ją z listą domyślnych ról PRINCE2®)

2. Zarządzanie Projektem wg. PRINCE2®

2.1. Celem zarządzania projektami według PRINCE2® jest:

2.1.1. Utrzymanie kontroli nad pracami specjalistycznymi

2.1.2. Motywowanie zaangażowanych osób

2.1.3. Utrzymanie aktualnej wiedzy o stanie projektu

2.1.4. Zagwarantowanie, że projekt nadal ma ważne uzasadnienie biznesowe

2.1.5. Zagwarantowanie, że projekt jest nadal korzystny dla organizacji

2.2. Zarządzanie projektem wg. PRINCE2® to nieustanny cykl

2.2.1. dostosowany cyklu Deminga na potrzeby PRINCE2®

2.2.1.1. Planuj (ang. Plan)

2.2.1.1.1. Planowanie prac do wykonania.

2.2.1.2. Deleguj (ang. Delegate)

2.2.1.2.1. Delegowanie prac do wykonania innym osobom / jednostkom / firmom / podwykonawcom etc.

2.2.1.3. Monitoruj (ang. Monitor)

2.2.1.3.1. Monitorowanie wykonywania prac poprzez raporty i komunikację.

2.2.1.4. Kontroluj (ang. Control)

2.2.1.4.1. Kontrolowanie wykonywanej pracy poprzez podejmowanie działań korygujących.

2.2.1.4.2. "Kontrola jest najwyższą formą zaufania. Im bardziej się komuś ufa, tym bardziej należy go kontrolować." (Feliks Dzierżyński)

2.2.1.5. czyli planowanie, delegowanie, monitorowanie, kontrolowanie... wszystkich aspektów projektu

2.3. Zalety stosowania PRINCE2®

2.3.1. pełna kontrola nad projektem i efektywne planowanie

2.3.2. analiza wydajności i efektywności procesu realizacji projektu i jego optymalizacja

2.3.3. wczesne ostrzeganie o możliwych problemach i reagowanie na zmiany i ryzyka

2.3.4. wprowadzenie i utrzymywanie dokumentacji i zapisów, budowa bezpieczeństwa projektu

2.3.5. współpraca z systemem zarządzania jakością ISO, korzystanie ze standardów zarządzania organizacją

2.3.6. stosowanie metodyki PRINCE2® podnosi prestiż firmy

2.3.6.1. innymi słowy "dobry marketing PRINCE2®" :-)

2.3.7. z punktu widzenia kontrahenta firma stosująca PRINCE2 jest bardziej atrakcyjnym i wiarygodnym partnerem biznesowym

2.3.7.1. innymi słowy "dobry marketing PRINCE2®" :-)

2.3.8. pozwala bardziej utożsamiać się z projektem osobom, które go realizują

2.3.9. zapewnia strukturę organizacyjną wraz z rolami i przypisanymi im zakresami obowiązków, odpowiedzialności i uprawnień

2.3.10. poprawia komunikację w projekcie

2.3.11. daje sprawdzone rozwiązania zarządcze podnoszące komfort pracy

3. Procesy (7)

3.1. Precyzując 7 typów Procesów, ponieważ niektóre procesy mogą wystąpić kilkukrotnie w projekcie.

3.2. PRINCE2® to sposób podejścia do zarządzania projektami oparty na procesach.

3.2.1. Niektóre procesy działają równolegle, niektóre sekwencyjnie.

3.2.2. Procesów nie należy mylić z etapami, gdyż są to odrębne pojęcia

3.2.2.1. Etapy dzielą cały projekt na określone odcinki czasu (wraz z tolerancjami czasu)

3.2.2.2. Procesy rozpoczynają się i kończą w ramach danego, jednego etapu

3.2.2.2.1. Przez co można powiedzieć, że procesy są częścią etapów.

3.2.2.2.2. Wyjątkiem jest proces Zarządzanie Strategiczne Projektem (ZSP), który trwa praktycznie non stop przez cały okres trwania projektu za wyjątkim początkowej fazy Przed-projektowej w ramach której nie obejmuje jej pełnego zakresu czasowego

3.3. Procesy występują na 3 poziomach zarządzania (choć w PRINCE2® wyróżniamy 4 poziomy zarządzania, jednak jeden z nich znajduje się nad projektem):

3.3.1. Zarządzanie Strategiczne

3.3.2. Zarządzania Opracyjne

3.3.3. Dostarczanie Produktów

3.4. Model procesowy PRINCE2®

3.4.1. Dwuetapowy model procesowy PRINCE2®

3.4.1.1. Jednoetapowy model procesowy PRINCE2® (najmniejsza i najkrótsza wersja PRINCE2®)

3.5. Przygotowanie Projektu (PP)

3.5.1. Występuje tylko raz w całym cyklu życia projektu, jest to pierwszy proces od jakiego rozpoczyna się projekt PRINCE2®

3.5.2. W bardzo skrajnym przypadku, proces może nie wystąpić jako samodzielny, odrębny proces

3.5.2.1. Przypadek najmniejszej wersji PRINCE2® - 1 etapowego projektu (tzw. Mały Książę)

3.5.2.1.1. W tym przypadku proces PP jest łączony z procesem Inicjowanie Projektu (IP) w Etapie Inicjowania, staje się częścią tego etapu

3.5.3. Obecny w fazie przed projektowej (nie należy mylić fazy z etapem)

3.5.3.1. faza przed projektowa (inna nazwa to czynności przed projektowe) nie jest nazywana etapem, ponieważ formalnie nie mamy jeszcze projektu

3.5.3.1.1. W fazie przed projektowej nie są wytwarzane żadne produkty specjalistyczne.

3.5.3.1.2. Są wytwarzane jedynie podstawowe produkty zarządcze

3.5.4. Obecny na DWÓCH poziomach zarządzania - zarządzanie strategiczne oraz zarządzanie operacyjne. PP to jedyny proces w PRINCE2®, który jest obecny na więcej niż jednym poziomie zarządzania.

3.5.4.1. Praca wykonywana głównie przez Przewodniczącego i Kierownika Projektu

3.5.5. Egzamin Foundation

3.5.5.1. W procesie PP powstają "solidne podstawy dla inicjowania projektu" - NIE powstają solidne podstawy dla całego projektu a jedynie solidne podstawy dla pierwszego etapu projektu czyli Etapu Inicjowania

3.5.5.2. Procesu PP należy nie mylić z fazą przed projektową (inna nazwa to czynności przed projektowe)

3.5.5.2.1. Faza przed projektowa (czynności przed projektowe) zawiera w sobie 2 procesy: PP i ZSP

3.5.6. Praktyka

3.5.6.1. Proces PP w bardzo małych projektach trwa nawet kilkanaście minut / kilka godzin.

3.5.6.1.1. często proces PP przebiega jedynie w formie ustnej, bez tworzenia jakiejkolwiek dokumentacji, tj. produktów zarządczych

3.5.6.2. Często proces PP jest procesem "wewnętrznym", tzn. wszystkie działania procesu odbywają się wewnątrz organizacji klienta, bez kontaktu z dostawcą (dostawca nie jest jeszcze znany)

3.5.6.2.1. Klient analizuje wstępne założenia dla projektu, odpowiadając na pytanie - "Czy potrzebujemy taki projekt? Czy projekt ma sens?"

3.5.6.3. W realiach rynku polskiego i przetargów publicznych (dokumenty SIWZ oraz OPZ), często proces PP kończy się ogłoszeniem wyników przetargu, wyłonieniem dostawcy oraz podpisaniem umowy

3.5.6.3.1. Praca z dostawcą rozpoczyna się pierwszy etap w PRINCE2® - Etap Inicjowania, gdzie wspólnie z dostawcą budowany jest min. DIP

3.5.7. Rekomendowane czynności w procesie

3.5.7.1. 1. Mianowanie Przewodniczącego i Kierownika Projektu

3.5.7.2. 2. Zgromadzenie dotychczasowych doświadczeń

3.5.7.3. 3. Projektowanie i mianowanie zespołu zarządzania projektem

3.5.7.4. 4. Wybieranie formuły realizacji projektu i zestawianie Założeń Projektu

3.5.7.5. 5. Przygotowanie zarysu Uzasadnienia Biznesowego

3.5.7.6. 6. Planowanie etapu inicjowania

3.6. Zarządzanie Strategiczne Projektem (ZSP)

3.6.1. Występuje tylko raz w całym cyklu życia projektu, jednak trwa praktycznie przez cały projekt)

3.6.2. ZSP zawsze występuje tylko raz i trwa przez cały czas trwania projektu

3.6.3. Proces rozpoczyna się w fazie przed projektowej, czyli jeszcze przed projektem

3.6.3.1. Pod koniec fazy przez projektowej lub w casie jej trwania, ale nigdy podczas startu procesu PP

3.6.3.1.1. Innymi słowy procesy PP i ZSP nie nachodzą / nakładają się na siebie

3.6.4. Obecny na poziomie zarządzania - zarządzanie strategiczne

3.6.4.1. Praca wykonywana głownie przez Komitet Sterujący (KS)

3.6.5. Rekomendowane czynności w procesie

3.6.5.1. Zezwalanie na zainicjowanie projektu

3.6.5.2. Zezwalanie na realizację projektu

3.6.5.3. Zezwalanie na realizację Planu Etapu lub Planu Nadzwyczajnego

3.6.5.4. Podejmowanie decyzji doraźnej

3.6.5.5. Zezwalanie na zamknięcie projektu

3.7. Inicjowanie Projektu (IP)

3.7.1. Występuje tylko raz w całym cyklu życia projektu w początkowym okresie projektu

3.7.2. Obecny w Etapie Inicjowania

3.7.2.1. Nie mylić Etapu Inicjowania z Procesem Inicjowania (IP)

3.7.3. Obecny na poziomie zarządzania - zarządzanie operacyjne

3.7.3.1. Praca wykonywana głownie przez Kierownika Projektu (KP)

3.7.4. Rekomendowane czynności w procesie

3.7.4.1. Opracowanie Strategii Zarządzania Ryzykiem

3.7.4.2. Opracowanie Strategii Zarządzania Jakością

3.7.4.3. Opracowanie Strategii Zarządzania Konfiguracją

3.7.4.4. Opracowanie Strategii Zarządzania Komunikacją

3.7.4.5. Sporządzanie Planu Projektu

3.7.4.6. Ustanowienie mechanizmów sterowania projektem

3.7.4.7. Doprecyzowanie Uzasadnienia Biznesowego

3.7.4.8. Zestawianie Dokumentacji Inicjowania Projektu (DIP)

3.7.5. Egzamin Foundation

3.7.5.1. Procesu IP należy nie mylić z Etapem Inicjowania

3.7.5.1.1. Etap Inicjowania zawiera w sobie procesy: IP, ZKE, ZSP, oraz w niektórych sytuacjach również procesy SE i ZDP

3.7.5.2. Proces IP jako jedyny posiada dwa sygnały wyjściowe, które odbywają się zawsze jeden po drugim. Innymi słowy po procesie IP zawsze mamy dwa sygnały wyjściowe

3.7.5.2.1. Sygnał 1 - Wniosek o realizację projektu (całego projektu)

3.7.5.2.2. Sygnał 2 - Wniosek o zatwierdzenie Planu Etapu (następnego, zbliżającego się etapu)

3.8. Sterowanie Etapem (SE)

3.8.1. SE występuje MINIMUM raz w całym cyklu życia projektu

3.8.2. W bardzo skrajnym przypadku, proces może wystąpić już w Etapie Inicjowania

3.8.2.1. przypadek najmniejszej wersji PRINCE2® - 1 etapowego projektu (tzw. Mały Książę)

3.8.3. Obecny na poziomie zarządzania - zarządzanie operacyjne

3.8.3.1. czyli praca wykonywana głownie przez Kierownika Projektu (KP)

3.8.4. Rekomendowane czynności w procesie

3.8.4.1. Zezwalanie na wykonanie Grupy Zadań

3.8.4.2. Przeglądanie stanu Grupy Zadań

3.8.4.3. Odbieranie zakończonych Grup Zadań

3.8.4.4. Przeglądanie stanu etapu

3.8.4.5. Podejmowanie działań korygujących

3.8.4.6. Wychwytywanie i badanie zagadnień i ryzyk

3.8.4.7. Przekazywanie zagadnień i ryzyk na wyższy szczebel

3.8.4.8. Raportowanie okresowe

3.9. Zarządzanie Dostarczaniem Produktów (ZDP)

3.9.1. ZDP występuje MINIMUM raz w całym cyklu życia projektu

3.9.2. Obecny na poziomie zarządzania - dostarczanie produktów

3.9.2.1. Praca Kierownika Zespołu (KZ)

3.9.3. Obecny w etapach realizacyjnych

3.9.3.1. ZDP może wystąpić w Etapie Inicjowania, kiedy to Etap Inicjowania jest zarazem etapem realizacyjnym, czyli posiada zarazem procesy IP i SE

3.9.3.1.1. przypadek najmniejszej wersji PRINCE2® - 1 etapowego projektu (tzw. Mały Książę)

3.9.4. Proces ZDP może wystąpić wiele razy w ramach jednego etapu zarządczego

3.9.5. W procesie ZDP odbywają się zatwierdzenia produktów specjalistycznych

3.9.5.1. ZATWIERDZENIA (nie mylić z akceptacją)

3.9.5.1.1. W PRINCE2®, zatwierdzenie NIE JEST równoznaczne z akceptacją. ZATWIERDZANE są produkty specjalistyczne "cząstkowe" (tj. Opisy Produktów) a AKCEPTOWANY jest produkt specjalistyczny "końcowy" (tj. Opis Produktu Końcowego Projektu)

3.9.6. Rekomendowane czynności w procesie

3.9.6.1. Przyjmowanie Grupy Zadań do wykonania

3.9.6.2. Wykonywanie Grupy Zadań

3.9.6.3. Oddawanie wykonanej Grupy Zadań

3.10. Zarządzanie Końcem Etapu (ZKE)

3.10.1. W bardzo skrajnym przypadku, proces ZKE może nie wystąpic

3.10.1.1. przypadek najmniejszej wersji PRINCE2® - 1 etapowego projektu (tzw. Mały Książę)

3.10.2. Obecny na poziomie zarządzania - zarządzanie operacyjne

3.10.2.1. Praca wykonywana głownie przez Kierownika Projektu

3.10.3. Rekomendowane czynności w procesie

3.10.3.1. Planowanie następnego etapu

3.10.3.2. Sporządzanie Planu Nadzwyczajnego

3.10.3.3. Uaktualnianie Planu Projektu

3.10.3.4. Uaktualnianie Uzasadnienia Biznesowego

3.10.3.5. Raportowanie zakończenia etapu

3.11. Zamykanie Projektu (ZP)

3.11.1. Występuje tylko raz w całym cyklu życia projektu

3.11.1.1. W ostatnim, końcowym etapie projektu

3.11.2. Obecny na poziomie zarządzania - zarządzanie operacyjne

3.11.2.1. Praca wykonywana głownie przez Kierownika Projektu

3.11.3. W procesie ZP odbywa się akceptacja końcowego produktu projektu

3.11.3.1. AKCEPTACJA (nie mylić z zatwierdzeniem)

3.11.3.1.1. W PRINCE2®, zatwierdzenie nie jest równoznaczne z akceptacją. ZATWIERDZANE są produkty specjalistyczne "cząstkowe" (tj. Opisy Produktów) a AKCEPTOWANY jest produkt specjalistyczny "końcowy" (tj. Opis Produktu Końcowego Projektu)

3.11.4. Rekomendowane czynności w procesie

3.11.4.1. Przygotowanie planowego zamknięcia

3.11.4.2. Przygotowanie przedwczesnego zamknięcia

3.11.4.3. Przekazanie produktów

3.11.4.4. Ocenianie projektu

3.11.4.5. Rekomendowanie zamknięcia projektu

4. Tematy (7)

4.1. Tematy to obszary którymi musimy zarządzać w projekcie prowadzonym wg. PRINCE2®.

4.1.1. Tematem jest aspekt zarządzania projektem, którym należy się stale zajmować i który wymaga określonego traktowania, aby procesy PRINCE2® były skuteczne.

4.1.2. W PRINCE2® tematy poruszają jedynie pobieżnie daną dziedzinę wiedzy i nie wyczerpują w pełni danego obszaru. Dzieje się tak z prostego powodu, zadaniem PRINCE2® jest jedynie naświetlenie obszarów, które wymagają zarządzania. Natomiast zadaniem Kierownika Projektu jest rozwinięcie oraz dostosowanie obszarów do specyfiki realizowanych projektów oraz branży w której projekty są prowadzone.

4.1.3. Należy pamiętać, że w prawdziwym projekcie takich obszarów jest dużo więcej. Między innymi PRINCE2® nie obejmuje: Motywacji, Przywództwa, Negocjacji, Rozwiązywania konfliktów, Budżetowania itp.

4.2. Każdy z tematów zgdonie ze swoim przeznaczeniem odpowiada na konkretne pytanie.

4.3. 1. Uzasadnienie Biznesowe

4.3.1. Temat odpowiada na pytanie...

4.3.1.1. Dlaczego?

4.3.1.1.1. Dlaczego projekt jest nam potrzebny?

4.3.1.1.2. Dlaczego powinniśmy rozpocząć projekt?

4.3.1.1.3. Dlaczego powinniśmy kontynuować projekt?

4.3.1.1.4. Dlaczego powinniśmy zakończyć projekt?

4.3.2. Powody dla podjęcia projektu różnią się znacząco i są determinowane przez środowisko projektu.

4.3.2.1. Projekt zaczyna się od pomysłu, o którym sądzi się, że ma potencjalną wartość dla zainteresowanej organizacji.

4.3.2.2. Ze względu na rodzaj projektu, można wyznaczyć rozmaite cele, początkowo dla sprawdzania jego atrakcyjności, a w dalszej kolejności, dla potwierdzenia, że produkty projektu są w stanie je osiągnąć.

4.3.3. Project zgodny z PRINCE2® ma ciągle ważne uzasadnienie biznesowe.

4.3.3.1. Innymi słowy jest potrzebny, przydatny i wykonalny.

4.3.3.1.1. potrzebny

4.3.3.1.2. przydatny

4.3.3.1.3. wykonalny

4.3.4. Metodyka PRINCE2® wyróżnia 4 czynności / działania w odniesieniu do Uzasadnienia Biznesowego:

4.3.4.1. 1. Opracowanie Uzasadnienia Biznesowego

4.3.4.2. 2. Weryfikowanie Uzasadnienia Biznesowego

4.3.4.3. 3. Utrzymywanie Uzasadnienia Biznesowego

4.3.4.4. 4. Potwierdzenie Uzasadnienia Biznesowego

4.3.5. Uzasadnienie Biznesowe a cykl życia projektu oraz produktów zarządczych

4.4. 2. Organizacja

4.4.1. Temat odpowiada na pytanie...

4.4.1.1. Kto?

4.4.1.1.1. Kto za co odpowiada w projekcie?

4.4.2. Metodyka PRINCE2® opiera się na środowisku klient / dostawca, zakładając istnienie klienta, który sprecyzuje pożądane rezultaty i zapłaci za projekt oraz dostawcy, który zapewni umiejętności i zasoby w celu dostarczenia pożądanych rezultatów.

4.4.3. Temat Organizacja opisuje strukturę zespołu zarządzania projektem wraz z przydzielonymi odpowiedzialnościami, określa zakresy obowiązków oraz relacje między wszystkimi rolami występującymi w projekcie.

4.4.3.1. Oznacza to również, że organizacja sponsorująca projekt musi przekazać związane z nim prace menedżerom, którzy będą za niego odpowiedzialni i będą nim kierowali aż do jego zakończenia.

4.4.3.1.1. Każdy projekt wymaga skutecznego kierowania, zarządzania, kontroli i komunikacji.

4.4.3.2. Ustanowienie efektywnej struktury zespołu zarządzania projektem wraz ze strategią komunikacji na początku projektu oraz ich utrzymanie przez cały okres trwania projektu, stanowią istotne elementy składające się na sukces projektu.

4.4.4. PRINCE2® wyróżnia 4 poziomy w organizacji (4 poziomy zarządzania projektem)

4.4.4.1. Kierownictwo organizacji lub programu

4.4.4.1.1. Zlecanie projektu

4.4.4.1.2. Pierwsza z tych warstw powołuje projekt i określa ogólne ograniczenia. Zespół zarządzania projektem obejmujący pozostałe trzy warstwy, zarządza projektem i realizuje go w wymiarze technicznym.

4.4.4.1.3. Ten poziom jest poziomem spoza projektu

4.4.4.2. Zarządzanie strategiczne – Komitet Sterujący

4.4.4.2.1. Ukierunkowanie projektu

4.4.4.2.2. Strategiczne zarządzanie projektem

4.4.4.3. Zarządzanie operacyjne – Kierownik Projektu

4.4.4.3.1. Operacyjne zarządzanie projektem

4.4.4.4. Dostarczanie produktów – Kierownik Zespołu

4.4.4.4.1. Zarządzanie zespołem(-ami) i dostarczanie produktów

4.4.5. Interesariusze i decydenci

4.4.5.1. Decydenci są to interesariusze, który są uprawnieni do podejmowanie decyzji projektowych.

4.4.5.2. Nie wszyscy interesariusze są decydentami.

4.4.6. Pobierz: PRINCE2® Macierz Procesy vs Produkty Zarządczy vs Role vs Odpowiedzialności (PDF)

4.4.6.1. http://miroslawdabrowski.com/downloads/PRINCE2/Reference%20cards/PRINCE2%20-%20Macierz%20Procesy%20vs%20Produkty%20Zarzadcze%20vs%20Role%20vs%20Odpowiedzialnosci%20%5Bv1.2%2C%2011.2013%2C%20PL%5D.pdf

4.5. 3. Jakość

4.5.1. Temat odpowiada na pytanie...

4.5.1.1. Co?

4.5.1.1.1. Co mam dostarczyć w jakiej postaci i na jakim poziomie jakości?

4.5.2. Jakość w projektach to kwestia identyfikowania tego, co sprawia, że produkty projektu lub usługi odpowiadają swemu przeznaczeniu, jakim jest zaspokojenie wy-specyfikowanych potrzeb.

4.5.3. Temat Jakość pomaga w zapewnieniu, że produkty projektu:

4.5.3.1. spełniają oczekiwania biznesowe

4.5.3.2. umożliwiają w efekcie uzyskanie pożądanych korzyści opisanych w Uzasadnieniu Biznesowym (A.2)

4.5.4. Ważna terminologia związana z tematem Jakość:

4.5.4.1. Oczekiwania jakościowe klienta

4.5.4.2. Kryteria akceptacji

4.5.4.3. Opis Produktu Końcowego Projektu

4.5.4.4. Formuła realizacji projektu (element Założeń Projektu)

4.5.4.5. Strategia Zarządzania Jakością

4.5.4.6. Opisy Produktów i kryteria jakości

4.5.4.7. Tolerancje jakości

4.5.4.8. Przegląd jakości (technika)

4.5.4.9. Rejestr Jakości

4.5.4.10. Zapisy zatwierdzeń

4.5.4.11. Zapisy akceptacji

4.5.5. Temat Jakość a cykl życia projektu oraz produktów zarządczych

4.6. 4. Plany

4.6.1. Temat odpowiada na pytanie...

4.6.1.1. Jak? Za ile? Kiedy?

4.6.1.1.1. Jak będziemy dostarczać produkty? Czy wytworzymy je samodzielnie, czy wykorzystamy podwykonawcę?

4.6.1.1.2. Ile będzie kosztować dostarczenie / wytworzenie konkretnego produktu?

4.6.1.1.3. Kiedy, w jakim terminie będzie dostarczony / wytworzony / odebrany produkt?

4.6.2. Projekty PRINCE2® przebiegają zgodnie z szeregiem zatwierdzonych planów.

4.6.3. Skuteczne zarządzanie projektami opiera się na efektywnym planowaniu, ponieważ bez planu kontrola nie jest możliwa.

4.6.4. PRINCE2® proponuje dla projektu następujące poziomy planów:

4.6.4.1. 1. Plan Projektu (obowiązkowy)

4.6.4.2. 2. Plan Etapu (obowiązkowy)

4.6.4.3. 3. Plan Zespołu (opcjonalny)

4.6.4.4. 4. Plan Nadzwyczajny

4.6.5. Temat Plany a cykl życia projektu oraz produktów zarządczych

4.7. 5. Ryzyko

4.7.1. Temat odpowiada na pytanie...

4.7.1.1. Co, jeżeli?

4.7.1.1.1. Co zrobimy jeśli wydarzy się dane zdarzenie (negatywne lub pozytywne)?

4.7.2. Każdy projekt z uwagi na niepowtarzalność parametrów realizacyjnych oraz zmiany w otoczeniu biznesowym musi brać pod uwagę możliwość wystąpienia zdarzeń nieplanowanych mogących mieć istotny wpływ na sposób jego realizacji.

4.7.2.1. Zarządzanie ryzykiem polega na utrzymywaniu ryzyka w akceptowalnych granicach w sposób efektywny i racjonalny kosztowo.

4.7.3. Z projektami związane jest zwykle większe ryzyko niż z ustabilizowanymi działaniami operacyjnymi (ang. Business as Usual).

4.7.4. Ryzyko może być zdefiniowane jako niepewność uzyskania zaplanowanego wyniku (w kontekście pozytywnym - traktowana jako szansa, lub negatywnym - widziana jako zagrożenie).

4.7.4.1. Ryzyko to przyszłe niepewne zdarzenie, które jeśli się wydarzy będzie mieć wpływ na cele projektu.

4.7.4.1.1. Zagrożenie (-) – niekorzystny wpływ na cele.

4.7.4.1.2. Szansa (+) – korzystny wpływ na cele.

4.7.5. W żadnym przedsięwzięciu nie powinniśmy sobie pozwolić na ignorowanie niepewności wyniku, z tego względu ważnym aspektem jest zarządzanie ryzykiem.

4.7.5.1. Celem zarządzania ryzykiem jest podejmowanie w sposób kosztowo efektywny działań związanych z utrzymywaniem tej niepewności na niskim poziomie.

4.7.6. Procedura zarządzania ryzykiem składa się z kroków (kroki te wywodzą się bezpośrednio ze standardu M_o_R®):

4.7.6.1. 1. Identyfikuj

4.7.6.1.1. dzieli się na dwa podkroki

4.7.6.2. 2. Oceniaj

4.7.6.2.1. dzieli się na dwa podkroki

4.7.6.3. 3. Planuj

4.7.6.3.1. głównym celem kroku „Planuj" jest przygotowanie określonych reakcji zarządczych na zidentyfikowane zagrożenia i szanse, najlepiej w celu usunięcia lub zmniejszenia zagrożeń oraz maksymalizacji szans,

4.7.6.4. 4. Wdrażaj

4.7.6.4.1. głównym celem kroku „Wdrażaj" jest zapewnienie, aby planowane reakcje na ryzyko zostały zrealizowane, ich efektywność była monitorowana oraz aby zostały podjęte działania korygujące w przypadku, gdyby reakcje te nie spełniały związanych z nimi oczekiwań,

4.7.6.5. Komunikacja

4.7.6.5.1. komunikacja to krok, który jest realizowany ciągle (jakkolwiek dziwnie by to nie brzmiało, wciąż według metodyki nazywany jest on krokiem). Krok „Komunikuj" powinien zapewnić, aby informacje dotyczące zagrożeń i szans dotyczących projektu były przekazywane zarówno w ramach projektu, jak i na zewnątrz, do interesariuszy.

4.7.7. Parametry ryzyka w PRINCE2®:

4.7.7.1. Prawdopodobieństwo

4.7.7.2. Bliskość

4.7.7.3. Wpływ

4.7.7.4. PRINCE2® nie określa czy dane parametry mamy opisywać w sposób ilościowy czy jakościowy.

4.7.7.5. Według PRINCE2® nie mam wpływu na parametr bliskość

4.7.8. Ryzyka możemy podzielić na:

4.7.8.1. Inherentne

4.7.8.1.1. ryzyko pierwotne, wstępne, przed podjęciem działań (reakcji)

4.7.8.2. Rezydualne

4.7.8.2.1. poziom ryzyka po zastosowaniu reakcji na ryzyko

4.7.8.3. Wtórne

4.7.8.3.1. ryzyko, które może wystąpić jako skutek zastosowania reakcji na ryzyko.

4.7.9. Temat Ryzyko a cykl życia projektu oraz produktów zarządczych

4.8. 6. Zmiana

4.8.1. Temat odpowiada na pytanie...

4.8.1.1. Jaki jest wpływ?

4.8.1.1.1. Jak ocenić wpływ zmiany w projekcie na cały projekt?

4.8.2. Opisuje w jaki sposób ocenia się i postępuje z zagadnieniami, które mają potencjalny wpływ na dowolny zatwierdzony aspekt projektu (jego plany lub wytworzone produkty).

4.8.3. Temat Zmiana a cykl życia projektu oraz produktów zarządczych

4.9. 7. Postępy

4.9.1. Temat odpowiada na pytanie...

4.9.1.1. Gdzie teraz jesteśmy? Dokąd zmierzamy? Czy powinniśmy kontynuować?

4.9.1.1.1. Jak ocenić progres projektu?

4.9.1.1.2. Czy wciąż jesteśmy na bieżąco z terminami?

4.9.1.1.3. Czy wystarczy nam czasu, aby ukończyć projekt w terminie?

4.9.2. Wyjaśnia on proces decyzyjny dotyczący zatwierdzania planów, monitorowanie faktycznego wykonania oraz proces przekazywania spraw na wyższy szczebel zarządzania w przypadku, gdy zdarzenia przebiegają niezgodnie z planem.

4.9.3. Delegowanie tolerancji oraz raportowanie

5. Pryncypia (7)

5.1. Projekt PRINCE2® musi bezdyskusyjnie stosować WSZYSTKIE pryncypia

5.1.1. Innymi słowy pryncypia w PRINCE2® to zasady (co jest różnie rozumiane w przypadku innych metodyk)

5.1.2. Jeśli projekt nie stosuje się do pryncypiów to mamy tzw. projekt PINO - "Prince In Name Only"

5.2. Pryncypia wg. PRINCE2® są:

5.2.1. uniwersalne

5.2.1.1. Mają zastosowanie w każdym typie projektu i są niezależne od branży (IT, budownictwo, inżynieria etc.).

5.2.2. samopotwierdzające

5.2.2.1. Sprawdzone na przestrzeni lat praktyki zarządzania projektami.

5.2.3. inspirujące

5.2.3.1. Zwiększają pewność siebie praktyków metodyki PRINCE2®, pozwalają wpływać na projekt, zarządzać i kształtować go.

5.2.4. innymi słowy "dobry marketing PRINCE2®" :-)

5.3. 1. Ciągła zasadność biznesowa

5.3.1. Projekt zgodny z PRINCE2® ma ciągle ważne uzasadnienie biznesowe.

5.3.1.1. Innymi słowy jest potrzebny, przydatny i wykonalny.

5.3.1.1.1. potrzebny

5.3.1.1.2. przydatny

5.3.1.1.3. wykonalny

5.3.2. Wymogiem dla projektu zgodnego z PRINCE2® jest:

5.3.2.1. Istnienie uzasadnionego powodu jego rozpoczęcia.

5.3.2.1.1. tzw. "powody podjęcia projektu"

5.3.2.1.2. Dla każdego projektu są znane uzasadnione powody rozpoczęcia projektu.

5.3.2.2. Uzasadnienie to powinno pozostawać ważne przez cały czas trwania projektu.

5.3.2.2.1. Ważność jest kontrolowana między innymi  poprzez kontrolę / sprawdzanie produktu zarządczego Uzasadnienie Biznesowe (A.2)

5.3.2.2.2. Zasadność realizacji projektu istnieje w czasie całego projektu

5.3.2.3. Uzasadnienie jest udokumentowane (Kierownik Projektu) i zatwierdzane (Komitet Sterujący) w produkcie zarządczym o takie samej nazwie - Uzasadnienie Biznesowe (A.2)

5.3.3. Pryncypium wspierane przez:

5.3.3.1. Produkty Zarządcze

5.3.3.1.1. Uzasadnienie Biznesowe (A.2)

5.3.3.2. Role

5.3.3.2.1. Komitet Sterujący (KS)

5.3.3.2.2. Kierownik Projektu (KP)

5.4. 2. Korzystanie z doświadczeń

5.4.1. Zespoły projektowe stosujące PRINCE2® uczą się z wcześniejszych doświadczeń: doświadczenia są wyszukiwane, zapisywane i wykorzystywane w trakcie całego projektu.

5.4.2. Wymogiem dla projektu zgodnego z PRINCE2® jest:

5.4.2.1. Korzystanie z doświadczeń zdobytych w poprzednich, podobnych projektach lub z zewnątrz organizacji

5.4.2.2. Zdobywanie doświadczeń w aktualnym projekcie i przekazywanie ich organizacji

5.4.3. Uczenie się na podstawie doświadczeń jest obecne w czasie całego projektu:

5.4.3.1. na początku

5.4.3.1.1. przejrzyj poprzednie lub podobne projekty, zgromadź doświadczenia, jeśli trzeba z zewnątrz organizacji (np. publicznie dostępne bazy zaleceń czy rekomendacji)

5.4.3.2. w trakcie trwania

5.4.3.2.1. gromadź dalsze doświadczenia, własne doświadczenia uwzględniaj w raportach i przeglądach

5.4.3.3. w czasie zamykania

5.4.3.3.1. przekaż własne doświadczenia organizacji, by wykorzystanie ich spowodowało korzystne zmiany w organizacji

5.4.4. Pryncypium wspierane przez:

5.4.4.1. Produkty Zarządcze

5.4.4.1.1. Dziennik Doświadczeń (A.14)

5.4.4.1.2. Raport Doświadczeń (A.15)

5.4.4.2. Role

5.4.4.2.1. Komitet Sterujący (KS)

5.4.4.2.2. Kierownik Projektu (KP)

5.5. 3. Zdefiniowane role i obowiązki

5.5.1. Projekt zgodny z PRINCE2® posiada zdefiniowane i uzgodnione role oraz obowiązki w swojej strukturze organizacyjnej, która uwzględnia interesu biznesu, użytkownika i dostawcy.

5.5.2. Jasna i jednoznaczna struktura zespołu zarządzania projektem.

5.5.3. Określone i uzgodnione role i obowiązki osób zaangażowanych w projekt.

5.5.3.1. Każdy wie czego się od niego oczekuje w projekcie.

5.5.4. Zapewnienie efektywnej komunikacji wewnątrz, do i z projektu.

5.5.5. Pryncypium wspierane przez:

5.5.5.1. Produkty Zarządcze

5.5.5.1.1. A.19 Założenia Projektu

5.5.5.1.2. A.20 Dokumentacja Inicjowania Projektu (DIP)

5.5.5.2. Elementy wchodzące w skład produktów zarządczych

5.5.5.2.1. Opis roli Przewodniczącego

5.5.5.2.2. Opis roli Kierownika Projektu

5.5.5.2.3. Opisy ról zespołu zarządzania projektem

5.5.5.2.4. Dodatkowe opisy ról

5.5.5.2.5. Struktura zespołu zarządzania projektem

5.5.5.3. Role

5.5.5.3.1. Kierownictwo organizacji/programu

5.5.5.3.2. Komitet Sterujący (KS)

5.5.5.3.3. Kierownik Projektu (KP)

5.6. 4. Zarządzanie etapowe

5.6.1. Każdy projekt PRINCE2® jest podzielony na Etapy

5.6.1.1. Etapy te nazywają się etapami zarządczymi

5.6.2. Projekt zgodny z PRINCE2® jest planowany, monitorowany i kontrolowany etapowo.

5.6.3. Projekt posiada minimum dwa etapy zarządcze:

5.6.3.1. etap inicjowania

5.6.3.2. jeden lub więcej etapów zarządczych

5.6.4. Projekt realizujemy etap po etapie, tylko jeden etap zarządczy na raz w danej chwili (sekwencyjnie)

5.6.5. Ilość i długość etapów różnicuje kontrolę i monitorowanie prac.

5.6.6. Pryncypium wspierane przez:

5.6.6.1. Produkty Zarządcze

5.6.6.1.1. Plan Projektu (A.16)

5.6.6.1.2. Plan Etapu (A.16)

5.6.6.1.3. Raport Końcowy Etapu (A.9)

5.6.6.2. Role

5.6.6.2.1. Komitet Sterujący (KS)

5.6.6.2.2. Kierownik Projektu (KP)

5.7. 5. Zarządzanie z wykorzystaniem tolerancji

5.7.1. Projekt zgodny z PRINCE2® posiada tolerancje określone dla każdego z celów projektu, służące do ustanowienia granic dla delegowanych uprawnień.

5.7.2. Zdefiniowane, jasno określone i zatwierdzone obowiązki dla każdego szczebla zarządzania.

5.7.3. Pryncypium wspierane przez:

5.7.3.1. Tolerancja to dopuszczalne odchylenie od planu, które nie wymaga poinformowania o nim wyższego szczebla zarządzania projektem. Kierownik Projektu musi informować Komitet Sterujący o wszelkich prognozowanych i istotnych odchyleniach od zatwierdzonego planu.

5.7.3.1.1. Parametry tolerancji według PRINCE2®:

5.7.3.2. Produkty Zarządcze

5.7.3.2.1. Strategia Zarządzania Ryzykiem (A.24)

5.7.3.2.2. Plan Projektu (A.16)

5.7.3.2.3. Plan Etapu (A.16)

5.7.3.2.4. Grupa Zadań (A.26)

5.7.3.2.5. Uzasadnienie Biznesowe (A.2)

5.7.3.2.6. Opis Produktu (A.17)

5.7.3.2.7. Opis Produktu Końcowego Projektu (A.21)

5.7.3.3. Role

5.7.3.3.1. Kierownictwo organizacji/programu

5.7.3.3.2. Komitet Sterujący (KS)

5.7.3.3.3. Kierownik Projektu (KP)

5.8. 6. Koncentracja na produktach

5.8.1. Projekt zgodny z PRINCE2® koncentruje się na zdefiniowaniu i dostarczeniu produktów, a w szczególności na spełnieniu określonych dla nich wymagań jakościowych.

5.8.2. Projekt PRINCE2® rozpoczyna się od określenie przedmiotu zamówienia (Opis Produktu Końcowego Projektu A.21)

5.8.2.1. Logiczne jest, że wiedząc co mamy zrobić, dopiero po tym myślimy o tym na kiedy i za ile

5.8.2.2. Wiedząc co klient zamawia, podzielimy przedmio zamówienia na mniejsze kawałki (dekompozycja) tak, abyśmy w następnej kolejności mogli przydzielić pracą kilku Kierownikom Zespołów w celu optymalizacji harmonogramu

5.8.3. Pryncypium wspierane przez:

5.8.3.1. Produkty Zarządcze

5.8.3.1.1. Opis Produktu (A.17)

5.8.3.1.2. Opis Produktu Końcowego Projektu (A.21)

5.8.3.2. Role

5.8.3.2.1. Komitet Sterujący (KS)

5.8.3.2.2. Kierownik Projektu (KP)

5.8.3.2.3. Kierownik Zespołu (KZ)

5.9. 7. Dostosowanie do warunków projektu

5.9.1. Metodyka PRINCE2® dostosowana jest do warunków konkretnego projektu, jego rozmiaru, budżetu, złożoności, czasochłonności, krytyczności, możliwości i zdolności organizacji, ryzyka etc.

5.9.2. Należy indywidualnie dostosować metodykę PRINCE2® do każdego projektu.

5.9.2.1. Żaden projekt nie jest taki sam.

5.9.2.2. Ustalenie jak metoda zarządzania projektami w organizacji będzie dostosowana do projektu.

5.9.2.3. Minimum szumu informacyjnego

5.9.3. Pryncypium wspierane przez:

5.9.3.1. Produkty Zarządcze

5.9.3.1.1. Dokumentacja Inicjowania Projektu (A.20)

5.9.3.2. Role

5.9.3.2.1. Komitet Sterujący (KS)

5.9.3.2.2. Kierownik Projektu (KP)

6. Oprogramowanie do zarządzania projektami

6.1. Zasada #1 - Oprogramowanie to tylko narzędzie, najważniejszy jest człowiek, jego umiejętności, rzetelność, intuicja, wiarygodność, myślenie analityczne etc. - podstawa to myśląca głowa (człowiek) a nie młotek (narzędzie)!

6.2. Oprogramowanie do zarządzania projektami zgodne z PRINCE2®

6.2.1. The Principal Toolbox

6.2.1.1. http://www.fortesglobal.com/en/solutions

6.2.2. P2ware

6.2.2.1. http://p2ware.com/pl

6.2.3. PPM Studio

6.2.3.1. http://www.ppmstudio.com/

6.2.4. MicroP2

6.2.4.1. http://www.novareconsulting.com/MicroP2/MicroP2.aspx

6.2.5. in-Step PRINCE2

6.2.5.1. http://www.microtool.de/instep/en/download_go.asp?url=2

6.2.6. PROJECT in a Box

6.2.6.1. http://www.projectinabox.org.uk/

6.2.7. P2_PC

6.2.7.1. http://www.projectcommander.co.uk/prince2/home.HTML

6.2.8. UWAGA - Zgodność oprogramowania z PRINCE2® nie czyni narzędzia "najlepszym w klasie", oprogramowanie to jedynie (i aż zarazem) narzędzie wspierające.

6.3. Oprogramowanie do zarządzania projektami "klasy Enterprise"

6.3.1. CA Technologies

6.3.1.1. CA Clarity™ PPM

6.3.1.1.1. http://www.ca.com/us/products/detail/ca-clarity-ppm.aspx

6.3.1.1.2. Najbardziej zaawanoswane narzędzie w klasie PPM.

6.3.1.1.3. Wielokrotny laureat nagród dla narzędzi PPM.

6.3.2. Compuware Corporation

6.3.2.1. Changepoint

6.3.2.1.1. http://www.compuware.com/

6.3.3. Innotas

6.3.3.1. Innotas PPM

6.3.3.1.1. http://www.innotas.com/

6.3.4. PlainView

6.3.4.1. PlainView PPM

6.3.4.1.1. http://www.planview.com/

6.3.5. HP

6.3.5.1. PPM Center

6.3.5.1.1. http://www8.hp.com/us/en/software-solutions/software.html?compURI=1171920#.Uz2J6Pl_t8F

6.3.6. EOS Software

6.3.6.1. EOS ITPM

6.3.6.1.1. http://www.eossoftware.com/

6.3.7. BMC Software

6.3.7.1. IT Business Management Suite

6.3.8. Upland Software Inc.

6.3.8.1. PowerSteering

6.3.8.1.1. http://www.uplandsoftware.com/products-overview/powersteering/

6.3.9. UMT

6.3.9.1. UMT360

6.3.9.1.1. http://www.umt360.com/

6.3.10. Clarizen

6.3.10.1. Clarizen

6.3.10.1.1. http://www.clarizen.com/

6.3.11. AtTask

6.3.11.1. AtTask

6.3.11.1.1. http://www.attask.com/

6.3.12. Daptiv

6.3.12.1. Daptiv PPM

6.3.12.1.1. http://www.daptiv.com/

6.3.13. Genius Inside

6.3.13.1. Genius Project

6.3.13.1.1. http://www.geniusproject.com/

6.3.14. Metafuse

6.3.14.1. Project Insight

6.3.14.1.1. http://www.projectinsight.net/

6.3.15. KeyedIn

6.3.15.1. KeyedIn Projects

6.3.15.1.1. http://www.keyedin.com/

6.3.16. Zilicus

6.3.16.1. ZilicusPM

6.3.16.1.1. http://zilicus.com/

6.4. Oprogramowanie do zarządzania projektami "klasy Business"

6.4.1. LiquidPlanner

6.4.1.1. LiquidPlanner

6.4.1.1.1. http://www.liquidplanner.com/

6.4.2. Upland Software Inc.

6.4.2.1. Tenrox

6.4.2.1.1. http://www.tenrox.com/

6.4.3. Upland Software Inc.

6.4.3.1. EPM Live

6.4.3.1.1. http://www.epmlive.com/

6.4.4. Celoxis Technologies Pvt. Ltd.

6.4.4.1. Celoxis

6.4.4.1.1. http://www.celoxis.com/

6.4.5. Project Manager Online Ltd

6.4.5.1. Project Manager

6.4.5.1.1. http://www.projectmanager.com/

6.5. Oprogramowanie darmowe

6.5.1. Talaia Open PPM

6.5.1.1. http://www.talaia-openppm.com/

6.5.2. PROJECT in a Box (wersja Community)

6.5.2.1. http://www.projectinabox.org.uk/

7. Projekt wg. PRINCE2®

7.1. Interpretacja definicji projektu

7.1.1. "Projekt to organizacja tymczasowa, powołana w celu dostarczenia jednego lub więcej produktów biznesowych według uzgodnionego Uzasadnienia Biznesowego (A.2)"

7.1.1.1. organizacja tymczasowa oznacza ...

7.1.1.1.1. utworzona / powołana tylko na czas projektu o rolach być może innych niż role w stałej strukturze organizacji

7.1.1.2. dostarczenia oznacza ...

7.1.1.2.1. kupienia gotowego, wytworzenia od podstaw, rozbudowy / poprawy obecnego produktu etc.

7.1.1.3. jednego lub więcej produktów oznacza ...

7.1.1.3.1. minimum jeden, aby projekt miał jakikolwiek sens :)

7.1.1.3.2. wielu takich samych, lub wielu całkowicie różnych

7.1.1.4. produktów oznacza ...

7.1.1.4.1. produkt fizyczny, dzieło, usługa, zaprojektowany proces, zatrudniona / przeszkolona osoba, zbudowany system etc.

7.1.1.5. biznesowych oznacza ...

7.1.1.5.1. takich którę są potrzebne dla organizacji i końcowym użytkownikom

7.1.1.5.2. takich które są zgodne z misją, wizją i celami organizacji

7.1.1.5.3. takich które przyniosą korzyści biznesowe dla organizacji klienta / użytkownika

7.1.1.6. Uzasadnienia Biznesowego (A.2) oznacza ...

7.1.1.6.1. opisane w produkcie zarządczym (dla prostoty dokumentacja) o nazwie Uzasadnienie Biznesowe

7.2. 5 Cech wyróżniających projekty od zwykłej działalności biznesowej (tzw. business as usual, BaU)

7.2.1. Zmiany

7.2.1.1. projekt służy do wprowadzania zmian w organizacji

7.2.1.2. zmiany w działalności biznesowej i operacyjnej (BaU) w postaci nowego, użytkowanego produktu po projekcie a wraz z nim zmiany w organizacji (np. nowe procesy, szkolenia po projektowe etc.)

7.2.1.3. Niespodziewana zmiana w organizacji :-)

7.2.2. Tymczasowość

7.2.2.1. projekt ma skończony początek i koniec co odróżnia go od tego czym na co dzień zajmuje się organizacja klienta / użytkownika

7.2.2.1.1. projekt kiedyś się rozpoczyna i kiedyś się kończy

7.2.2.2. podobnie każdy etap w projekcie ma ustalony początek i koniec

7.2.2.3. wszystkie inne prace charakteryzują się tym, że trwają nieprzerwanie, wynikają z procesów biznesowych realizowanych w organizacji

7.2.3. Wielofunkcyjność

7.2.3.1. klienci i dostawcy mają różne perspektywy i motywacje

7.2.3.2. projekt angażuje osoby o różnych oczekiwaniach i nastawieniach do projektu

7.2.3.2.1. dostawca

7.2.3.2.2. klient

7.2.3.3. projekt łączy w sobie umiejętności i doświadczenie różnych osób, ekspertów, specjalistów, konsultantów etc.

7.2.4. Unikalność

7.2.4.1. projekt jest realizowany w niepowtarzalnym otoczeniu / kontekście

7.2.4.1.1. między innymi unikalność oznacza również inny okres czasowy w którym są realizowane projekty,

7.2.4.2. każdy projekt jest unikalny i należy go rozpatrywać indywidualnie w kontekście wszystkich 6 efektywności projektu.

7.2.4.2.1. “Different projects need different methodologies” (Alistair Cockburn)

7.2.4.2.2. Każdy projektu jest unikalny oznacza również to, że metodyka PRINCE2® nie jest odpowiednia do wszystkich typów projektów (co jest całkowicie naturalne praktycznie dla każdej metodyki).

7.2.4.2.3. W przypadkach kiedy istnieje pewność, że wymagania w projekcie będą zmieniać się na przestrzeni projektu lub kiedy nie znamy wszystkich wymagań przy starcie projektu a mimo to mamy rozpocząć projekt podejście zwinne (ang. Agile) może wydawać się bardziej odpowiednie.

7.2.5. Niepewność

7.2.5.1. projekt niesie większy poziom ryzyka niż zwykła działalność biznesowa

7.2.5.2. każdy projekt jest niepewnym przedsięwzięciem, może zakończyć się sukcesem lub porażką, aby wzmocnić szansę ukończenia projektu z sukcesem musimy zarządzać niepewnością w projekcie tj. ryzykiem

7.2.5.2.1. Przemyślenia: Inaczej zamiast zarządzania projektami mielibyśmy automatyzację projektów ...

7.3. 6 zmiennych projektu (tzw. aspekty efektywności)

7.3.1. Zmienne / efektywności projektu, ponieważ mogą zmienić się podczas trwania projektu i musimy je kontrolować.

7.3.2. Oznaczają obszary jakie należy kontrolować przez cały czas trwania projektu.

7.3.3. Koszty

7.3.3.1. kontrolowane min. przez

7.3.3.1.1. budżet projektu

7.3.3.1.2. budżet ryzyka

7.3.3.1.3. budżet zmian

7.3.4. Terminy

7.3.4.1. kontrolowane min. przez

7.3.4.1.1. Plan Projektu (A.16)

7.3.4.1.2. Plany Etapów (A.16)

7.3.4.1.3. Plany Nadzwyczajne (A.16)

7.3.4.1.4. Grupy Zadań (A.26)

7.3.5. Jakość

7.3.5.1. kontrolowane min. przez

7.3.5.1.1. Strategia Zarządzania Jakością (A.22)

7.3.5.1.2. Rejestr Jakości (A.23)

7.3.5.1.3. Opis Produktu Końcowego Projektu (A.21)

7.3.5.1.4. Opis Produktu (A.17)

7.3.6. Zakres

7.3.6.1. Zakres projektu to całkowita suma produktów

7.3.6.1.1. Opisuje on co wchodzi a co nie wchodzi w zakres projektu

7.3.6.1.2. Jest ona określona przez strukturę podziału produktów i związane z nią Opisy Produktów

7.3.6.2. kontrolowane min. przez

7.3.6.2.1. Plan Projektu (A.16)

7.3.6.2.2. Plany Etapów (A.16)

7.3.6.2.3. Grupa Zadań (A.26)

7.3.7. Ryzyko

7.3.7.1. kontrolowane min. przez

7.3.7.1.1. Strategia Zarządzania Ryzykiem (A.24)

7.3.7.1.2. Rejestr Ryzyk (A.25)

7.3.7.1.3. Grupa Zadań (A.26)

7.3.7.2. Jaki jest profil ryzyka projektu

7.3.8. Korzyści

7.3.8.1. kontrolowane min. przez

7.3.8.1.1. Uzasadnienie Biznesowe (A.2)

7.3.8.1.2. Plan Przeglądu Korzyści (A.1)

7.4. Model procesowy PRINCE2®

7.4.1. Dwuetapowy model procesowy PRINCE2®

7.4.1.1. Jednoetapowy model procesowy PRINCE2® (najmniejsza i najkrótsza wersja PRINCE2®)

8. Struktura PRINCE2®

8.1. Metodyka PRINCE2® to 4 zintegrowane elementy

8.1.1. Pryncypia

8.1.2. Tematy

8.1.3. Procesy

8.1.4. Środowisko projektu

8.2. "Magiczna liczba 7"

8.2.1. 7 Pryncypiów

8.2.1.1. siedem przewodnich zasad / nakazów

8.2.2. 7 Tematów

8.2.2.1. siedem obszarów wiedzy zarządzania projektem

8.2.3. 7 Procesów (typów procesów)

8.2.3.1. siedem grup działań, opisujących co należy robić w projekcie w całym jego cyklu życia

8.2.4. Środowisko projektu

8.2.4.1. Dostosowanie metodyki PRINCE2® do środowiska w którym realizowany jest projekt

8.2.4.1.1. środowiska i kultury organizacji / firmy w ramach której prowadzony jest projekt PRINCE2®

8.2.4.1.2. środowiska zewnętrznego spoza organizacji w ramach której prowadzony jest projekt PRINCE2®

8.2.4.2. Oznacza to min. wprowadzeniu specyficznej, branżowej terminologii / języka

8.2.4.3. Dostosowanie dokumentacji pod potrzeby / wymagania organizacji oraz projektu

8.2.4.4. Dostosowanie projektu pod kontekst branży (np. IT, inżynieria, etc.) - metodyka PRINCE2® jest w pełni ogólna i wymaga dostosowania przed jej zastosowaniem

8.3. PRINCE2® nie obejmuje

8.3.1. aspektów specjalistycznych / branżowych

8.3.2. szczegółowych / specjalistycznych technik i narzędzi zarządzania projektami

8.3.3. oprogramowania do zarządzania projektami

8.3.4. zdolności przywódczych

8.3.5. aspektów motywacji pracowników

8.3.6. aspektów miękkich

8.3.7. aspektów prawnych

8.3.8. negocjacji

8.3.9. kontraktowania / umów

8.3.10. rozwiązywania konfliktów

8.3.11. ...

9. Produkty zarządcze (26)

9.1. Produkty zarządcze typu: Bazowe

9.1.1. a.k.a. "fundament PRINCE2®"

9.1.2. Produkty zarządcze typu "bazowe", określają podstawowe aspekty zarządzania projektem PRINCE2®.

9.1.3. K.P. NIE może aktualizować tych produktów zarządczych bez potrzeby zgody Komitetu Sterującego

9.1.3.1. Wyjątkiem jest Grupa Zadań (A.26)

9.1.4. A.1 Plan Przeglądu Korzyści

9.1.4.1. Rekomendowana zawartość

9.1.4.1.1. Zakres Planu Przeglądu Korzyści, obejmujący wykaz oczekiwanych korzyści podlegających pomiarowi.

9.1.4.1.2. Osoby odpowiedzialne za osiągnięcie oczekiwanych korzyści.

9.1.4.1.3. Sposoby i terminy pomiaru oczekiwanych korzyści.

9.1.4.1.4. Zasoby niezbędne do przeprowadzenia przeglądu korzyści.

9.1.4.1.5. Poziomy odniesienia, względem których będzie obliczana poprawa.

9.1.4.1.6. Sposób przeglądu efektywności produktu końcowego projektu.

9.1.5. A.2 Uzasadnienie Biznesowe

9.1.5.1. Rekomendowana zawartość

9.1.5.1.1. Podsumowanie

9.1.5.1.2. Powody podjęcia projektu

9.1.5.1.3. Możliwe rozwiązania biznesowe

9.1.5.1.4. Oczekiwane korzyści

9.1.5.1.5. Przewidywane niepożądane skutki

9.1.5.1.6. Terminy

9.1.5.1.7. Koszty

9.1.5.1.8. Ocena inwestycji

9.1.5.1.9. Główne ryzyka

9.1.6. A.4 Strategia Zarządzania Komunikacją

9.1.6.1. Rekomendowana zawartość

9.1.6.1.1. Wprowadzenie

9.1.6.1.2. Procedura komunikacji

9.1.6.1.3. Narzędzia i techniki

9.1.6.1.4. Wymagane zapisy

9.1.6.1.5. Raportowanie

9.1.6.1.6. Terminy działań związanych z komunikacją

9.1.6.1.7. Role i ich obowiązki

9.1.6.1.8. Analiza interesariuszy

9.1.6.1.9. Potrzeby informacyjne każdej z zainteresowanych stron

9.1.7. A.6 Strategia Zarządzania Konfiguracją

9.1.7.1. Rekomendowana zawartość

9.1.7.1.1. Wprowadzenie

9.1.7.1.2. Procedura zarządzania konfiguracją

9.1.7.1.3. Procedura obsługi zagadnień i sterowania zmianami

9.1.7.1.4. Narzędzia i techniki

9.1.7.1.5. Wymagane zapisy

9.1.7.1.6. Raportowanie

9.1.7.1.7. Terminy działań związanych z zarządzaniem konfiguracją i sterowaniem zagadnieniami oraz zmianami

9.1.7.1.8. Role i ich obowiązki

9.1.7.1.9. Skala ocen priorytetu i wagi

9.1.8. A.16 Plan

9.1.8.1. Plany dzielą się na 3 poziomy planów, ale PRINCE2® identyfikuje 5 typów planów

9.1.8.1.1. spoza PRINCE2®, nad projektem np. wywodzą się z programu

9.1.8.1.2. poziom projektu i etapu zarazem

9.1.8.1.3. 3. poziom dostarczania produktów specjalistycznych

9.1.8.2. Rekomendowana zawartość

9.1.8.2.1. Opis planu

9.1.8.2.2. Warunki wstępne dla planu

9.1.8.2.3. Zależności zewnętrzne

9.1.8.2.4. Założenia planistyczne

9.1.8.2.5. Uwzględnione doświadczenia

9.1.8.2.6. Monitorowanie i kontrola

9.1.8.2.7. Budżety

9.1.8.2.8. Tolerancje

9.1.8.2.9. Opisy produktów (A.17)

9.1.8.2.10. Harmonogram

9.1.9. A.17 Opis Produktu

9.1.9.1. Rekomendowana zawartość

9.1.9.1.1. Identyfikator

9.1.9.1.2. Nazwa

9.1.9.1.3. Przeznaczenie

9.1.9.1.4. Zawartość/Skład

9.1.9.1.5. Pochodzenie

9.1.9.1.6. Wymagany format i sposób przedstawienia

9.1.9.1.7. Wymagane umiejętności wytwórcy

9.1.9.1.8. Kryteria jakości

9.1.9.1.9. Tolerancja jakości

9.1.9.1.10. Metoda kontroli jakości

9.1.9.1.11. Wymagane umiejętności kontrolera jakości

9.1.9.1.12. Obowiązki dotyczące jakości

9.1.10. A.19 Założenia Projektu

9.1.10.1. Rekomendowana zawartość

9.1.10.1.1. Definicja projektu

9.1.10.1.2. Zarys Uzasadnienia Biznesowego

9.1.10.1.3. Opis Produktu Końcowego Projektu

9.1.10.1.4. Formuła realizacji projektu

9.1.10.1.5. Struktura zespołu zarządzania projektem

9.1.10.1.6. Opisy ról

9.1.10.1.7. Odniesienia

9.1.11. A.20 Dokumentacja Inicjowania Projektu (DIP)

9.1.11.1. Rekomendowana zawartość

9.1.11.1.1. Definicja projektu

9.1.11.1.2. Formuła realizacji projektu

9.1.11.1.3. Uzasadnienie Biznesowe

9.1.11.1.4. Struktura zespołu zarządzania projektem

9.1.11.1.5. Opisy ról

9.1.11.1.6. Strategia Zarządzania Jakością (A.22)

9.1.11.1.7. Strategia Zarządzania Konfiguracją (A.6)

9.1.11.1.8. Strategia Zarządzania Ryzykiem (A.24)

9.1.11.1.9. Strategia Zarządzania Komunikacją (A.4)

9.1.11.1.10. Plan Projektu (A.16)

9.1.11.1.11. Mechanizmy sterowania

9.1.11.1.12. Dostosowanie metodyki PRINCE2

9.1.12. A.21 Opis Produktu Końcowego Projektu

9.1.12.1. Rekomendowana zawartość

9.1.12.1.1. Nazwa

9.1.12.1.2. Przeznaczenie

9.1.12.1.3. Zawartość/skład

9.1.12.1.4. Pochodzenie

9.1.12.1.5. Wymagane umiejętności wytwórcy

9.1.12.1.6. Oczekiwania jakościowe klienta

9.1.12.1.7. Kryteria akceptacji

9.1.12.1.8. Tolerancje projektu

9.1.12.1.9. Metoda akceptacji

9.1.12.1.10. Obowiązki dotyczące akceptacji

9.1.13. A.22 Strategia Zarządzania Jakościa

9.1.13.1. Rekomendowana zawartość

9.1.13.1.1. Wprowadzenie

9.1.13.1.2. Procedura zarządzania jakością

9.1.13.1.3. Narzędzia i techniki

9.1.13.1.4. Wymagane zapisy

9.1.13.1.5. Raportowanie

9.1.13.1.6. Terminy działań związanych z zarządzaniem jakością

9.1.13.1.7. Role i obowiązki

9.1.14. A.24 Strategia Zarządzania Ryzykiem

9.1.14.1. Rekomendowana zawartość

9.1.14.1.1. Wprowadzenie

9.1.14.1.2. Procedura zarządzania ryzykiem

9.1.14.1.3. Narzędzia i techniki

9.1.14.1.4. Wymagane zapisy

9.1.14.1.5. Raportowanie

9.1.14.1.6. Terminy działań związanych z zarządzaniem ryzykiem

9.1.14.1.7. Role i obowiązki

9.1.14.1.8. Skale ocen

9.1.14.1.9. Bliskość

9.1.14.1.10. Kategorie ryzyka

9.1.14.1.11. Kategorie reakcji na ryzyko

9.1.14.1.12. Wskaźniki wczesnego ostrzegania

9.1.14.1.13. Tolerancja ryzyka

9.1.14.1.14. Budżet ryzyka

9.1.15. A.26 Grupa Zadań

9.1.15.1. Rekomendowana zawartość

9.1.15.1.1. Data

9.1.15.1.2. Kierownik Zespołu lub osoba upoważniona

9.1.15.1.3. Opis Grupy Zadań

9.1.15.1.4. Techniki, procesy i procedury

9.1.15.1.5. Punkty styku (interfejsy) w okresie wytwarzania

9.1.15.1.6. Punkty styku (interfejsy) związane z eksploatacją i utrzymaniem

9.1.15.1.7. Wymagania zarządzania konfiguracją

9.1.15.1.8. Uzgodnienia

9.1.15.1.9. Tolerancje

9.1.15.1.10. Ograniczenia

9.1.15.1.11. Uzgodnienia dotyczące raportowania

9.1.15.1.12. Sposoby obsługi i przekazywania problemów

9.1.15.1.13. Wyciągi lub odniesienia do dokumentów powiązanych

9.1.15.1.14. Metoda zatwierdzenia (odbioru) wykonanej Grupy Zadań

9.2. Produkty zarządcze typu: Zapisy

9.2.1. a.k.a. "dynamika PRINCE2®"

9.2.2. Produkty zarządcze typu "zapisy", zawierają "dynamiczne" informacje wraz z historią zmian o stanie projektu. Podlegają częstym aktualizacjom.

9.2.3. K.P. może aktualizować te dokumenty bez potrzeby otrzymania zgody od Komitetu Sterującego

9.2.4. A.5 Zapisy Obiektu Konfiguracji

9.2.4.1. Rekomendowana zawartość

9.2.4.1.1. Identyfikator projektu

9.2.4.1.2. Identyfikator obiektu

9.2.4.1.3. Aktualna wersja

9.2.4.1.4. Nazwa obiektu

9.2.4.1.5. Data ostatniej zmiany statusu

9.2.4.1.6. Docelowy właściciel produktu

9.2.4.1.7. Miejsce przechowywania

9.2.4.1.8. Aktualni posiadacze

9.2.4.1.9. Rodzaj obiektu

9.2.4.1.10. Cechy obiektu

9.2.4.1.11. Etap

9.2.4.1.12. Użytkownicy

9.2.4.1.13. Status

9.2.4.1.14. Stadium produktu

9.2.4.1.15. Wariant

9.2.4.1.16. Wytwórca/producent

9.2.4.1.17. Data przydzielenia wytwórcy

9.2.4.1.18. Pochodzenie produktu

9.2.4.1.19. Związek z innymi produktami

9.2.4.1.20. Powiązania

9.2.5. A.7 Dziennik Projektu

9.2.5.1. Rekomendowana zawartość

9.2.5.1.1. Data wpisu.

9.2.5.1.2. Problem, działanie, zdarzenie lub komentarz

9.2.5.1.3. Osoba odpowiedzialna

9.2.5.1.4. Wyznaczony termin

9.2.5.1.5. Rezultaty

9.2.6. A.12 Rejestr Zagadnień

9.2.6.1. Rekomendowana zawartość

9.2.6.1.1. Identyfikator zagadnienia

9.2.6.1.2. Typ zagadnienia

9.2.6.1.3. Data zgłoszenia

9.2.6.1.4. Zgłoszone przez

9.2.6.1.5. Autor Raportu o Zagadnieniu

9.2.6.1.6. Opis zagadnienia

9.2.6.1.7. Priorytet

9.2.6.1.8. Waga/znaczenie

9.2.6.1.9. Status

9.2.6.1.10. Data zamknięcia

9.2.7. A.14 Dziennik Doświadczeń

9.2.7.1. Repozytorium doświadczeń, które mają zastosowanie do tego projektu lub przyszłych projektów.

9.2.7.2. Jego zawartość może pochodzić z innych projektów i zawierać doświadczenie zebrane przez inne podmioty / firmy..

9.2.7.3. Rekomendowana zawartość

9.2.7.3.1. Typ doświadczenia

9.2.7.3.2. Opis doświadczenia

9.2.7.3.3. Data wpisu

9.2.7.3.4. Wpisane przez

9.2.7.3.5. Priorytet

9.2.8. A.23 Rejestr Jakości

9.2.8.1. Rekomendowana zawartość

9.2.8.1.1. Numer wpisu

9.2.8.1.2. identyfikator(y) produktu(-ów)

9.2.8.1.3. Nazwa(-y) produktu(-ów)

9.2.8.1.4. Metoda

9.2.8.1.5. Role i obowiązki

9.2.8.1.6. Terminy

9.2.8.1.7. Wynik

9.2.8.1.8. Zapisy jakości

9.2.9. A.25 Rejestr Ryzyk

9.2.9.1. Rekomendowana zawartość

9.2.9.1.1. Identyfikator ryzyka

9.2.9.1.2. Autor zgłoszenia

9.2.9.1.3. Data zarejestrowania

9.2.9.1.4. Kategoria ryzyka

9.2.9.1.5. Opis ryzyka

9.2.9.1.6. Prawdopodobieństwo, wpływ i wartość oczekiwana

9.2.9.1.7. Bliskość ryzyka

9.2.9.1.8. Kategorie reakcji na ryzyko

9.2.9.1.9. Proponowane reakcje na ryzyko

9.2.9.1.10. Status ryzyka

9.2.9.1.11. Właściciel ryzyka

9.2.9.1.12. Wykonawca reakcji na ryzyko

9.3. Produkty zarządcze typu: Raporty

9.3.1. a.k.a. "statyka PRINCE2®"

9.3.2. Produkty zarządcze typu "raporty", przekazują aktualne informacje o stanie projektu.

9.3.3. Są to "statyczne" (a.k.a. snapshot, point in time / photo) produkty zarządcze, gdyż nie podlegają aktualizacjom.

9.3.3.1. Wyjątkiem jest Raport o Zagadnieniu (A.13)

9.3.4. A.3 Raport z Punktu Kontrolnego

9.3.4.1. Rekomendowana zawartość

9.3.4.1.1. Data opracowania

9.3.4.1.2. Okres sprawozdawczy

9.3.4.1.3. Wykonanie wcześniej zleconych czynności

9.3.4.1.4. Bieżący okres sprawozdawczy

9.3.4.1.5. Następny okres sprawozdawczy

9.3.4.1.6. Stan tolerancji Grupy Zadań

9.3.4.1.7. Zagadnienia i ryzyka

9.3.5. A.8 Raport Końcowy Projektu

9.3.5.1. Rekomendowana zawartość

9.3.5.1.1. Sprawozdanie Kierownika Projektu

9.3.5.1.2. Przegląd Uzasadnienia Biznesowego

9.3.5.1.3. Przegląd realizacji celów projektu

9.3.5.1.4. Przegląd efektywności zespołu projektowego

9.3.5.1.5. Przegląd produktów

9.3.5.1.6. Raport Doświadczeń (A.15)

9.3.6. A.9 Raport Końcowy Etapu

9.3.6.1. Rekomendowana zawartość

9.3.6.1.1. Sprawozdanie Kierownika Projektu

9.3.6.1.2. Przegląd Uzasadnienia Biznesowego

9.3.6.1.3. Przegląd realizacji celów projektu

9.3.6.1.4. Przegląd realizacji celów etapu

9.3.6.1.5. Przegląd efektywności zespołu projektowego

9.3.6.1.6. Przegląd produktów

9.3.6.1.7. Raport Doświadczeń (opcjonalnie) (A.15)

9.3.6.1.8. Zagadnienia i ryzyka

9.3.6.1.9. Prognoza

9.3.7. A.10 Raport Nadzywczajny

9.3.7.1. Rekomendowana zawartość

9.3.7.1.1. Opis sytuacji nadzwyczajnej

9.3.7.1.2. Przyczyna wystąpienia

9.3.7.1.3. Skutki odchylenia

9.3.7.1.4. Możliwe reakcje

9.3.7.1.5. Rekomendacja

9.3.7.1.6. Doświadczenia

9.3.8. A.11 Raport Okresowy

9.3.8.1. Rekomendowana zawartość

9.3.8.1.1. Data opracowania

9.3.8.1.2. Okres sprawozdawczy

9.3.8.1.3. Sumaryczny opis stanu etapu

9.3.8.1.4. Bieżący okres sprawozdawczy

9.3.8.1.5. Następny okres sprawozdawczy

9.3.8.1.6. Stan tolerancji projektu i etapu

9.3.8.1.7. Wnioski o wprowadzenie zmiany

9.3.8.1.8. Główne zagadnienia i ryzyka

9.3.8.1.9. Raport Doświadczeń

9.3.9. A.13 Raport o Zagadnieniu

9.3.9.1. Rekomendowana zawartość

9.3.9.1.1. Identyfikator zagadnienia

9.3.9.1.2. Typ zagadnienia

9.3.9.1.3. Data zgłoszenia

9.3.9.1.4. Zgłoszone przez

9.3.9.1.5. Autor Raportu o Zagadnieniu

9.3.9.1.6. Opis zagadnienia

9.3.9.1.7. Analiza wpływu

9.3.9.1.8. Rekomendacja

9.3.9.1.9. Priorytet

9.3.9.2. Egzamin Foundation

9.3.9.2.1. WYJĄTEK. Raport o Zagadnieniu (A.13) jako jedyny raport w PRINCE2® może być aktualizowany. Pozostałe report wg. PRINCE2® nie są aktualizowane.

9.3.10. A.15 Raport Doświadczeń

9.3.10.1. Wykorzystywany do przekazywania wszelkich doświadczeń, które można z powodzeniem zastosować do innych projektów

9.3.10.2. Ma na celu wywołanie działania – wykorzystanie pozytywnych doświadczeń w sposobie pracy organizacji i uniknięcie negatywnych doświadczeń w przyszłych projektach

9.3.10.3. Rekomendowana zawartość

9.3.10.3.1. Podsumowanie

9.3.10.3.2. Zakres raportu (np. etap lub projekt)

9.3.10.3.3. Przegląd tego, co przebiegło dobrze, co przebiegło źle oraz rekomendacje do rozważenia przez kierownictwo organizacji lub programu

9.3.10.3.4. Przegląd użytecznych miar

9.3.10.3.5. W przypadku doświadczeń o istotnym znaczeniu, przydatne mogą być dodatkowe informacje

9.3.10.4. Egzamin Foundation

9.3.10.4.1. Raport Doświadczeń NIE Doświadczenia

9.3.11. A.18 Zestawienie Statusów Produktów

9.3.11.1. Rekomendowana zawartość

9.3.11.1.1. Zakres raportu

9.3.11.1.2. Data wytworzenia

9.3.11.1.3. Status produktów

9.3.11.2. Egzamin Foundation

9.3.11.2.1. Produkt zarządczy Zestawienie Statusów Produktów (A.18) jest raportem, mimo, że jako jedyny raport w PRINCE2®, NIE POSIADA słowa raport w swojej nazwie (co może zaburzać logikę i zapamietywanie przez analogię).

9.4. Praktyka

9.4.1. Produkty zarządcze to zbiory informacji na temat stanu projektu, nie należy zawsze utożsamiać ich z typową dokumentacją / paperami / Wordami i Excelami.

9.4.1.1. Produkt zarządczy może być generowany automatycznie podczas eksportu z narzędzia / oprogramowania do zarządzania projektami.

10. Zasoby zewnętrzne firm trzecich

10.1. Szablony dokumentów PRINCE2® firm trzecich

10.1.1. P2 Toolkit

10.1.1.1. http://prince2.privacyresources.org/

10.1.2. Management Plaza

10.1.2.1. http://mgmtplaza.com/product/a-sample-prince2-project/

10.1.3. Project In a Box

10.1.3.1. http://www.projectinabox.org.uk/prince2_templates.asp

10.1.4. ILX Group

10.1.4.1. http://www.prince2.com/downloads

10.1.5. Silicon Beach Training

10.1.5.1. http://www.siliconbeachtraining.co.uk/blog/download-prince2-2009-project-templates

10.1.6. Corepm

10.1.6.1. http://www.prince2tool.com/

10.1.7. Cupe

10.1.7.1. http://www.cupe.co.uk/templates.html

10.2. Mapy PDF PRINCE2®

10.2.1. ILX

10.2.1.1. http://www.tel.uva.es/personales/proy/pmodel.pdf

10.2.1.2. http://www.prince2.com/downloads

10.2.2. http://tannerjames.businesscatalyst.com/free_resources/Prince2_Process_Model.pdf

10.2.3. http://www.slideshare.net/frankturley/p2-m-productmap

10.2.4. http://www.knowledgetrain.co.uk/images/kt/PRINCE2_Wallchart_v1.04.pdf

11. PRINCE2® - procesowy standard i kaskadowo-sekwencyjna metodyka zarządzania projektami (nie zalecenia, nie dobre praktyki, nie wytyczne, nie technika, nie framework i nie metodologia a metodyka) do ogólnego (nie związanego z konkretną branżą typu: IT czy budownictwo) kaskadowo-sekwencyjnego (nie iteracyjnego i nie adaptacyjnego) zarządzania projektami. PRINCE2® jest metodyką wchodzącą w skład rodziny brytyjskich standardów o nazwie AXELOS® Global Best Practice.

11.1. PRINCE2® v1 został opublikowany w 1996 roku.

11.2. PRINCE2® v2 został opublikowany w 2002 roku.

11.3. PRINCE2® v3 został opublikowany w 2005 roku.

11.4. PRINCE2® v4 został opublikowany w 2009 roku.

11.4.1. Znacząca aktualizacja

11.5. Jak PRINCE2® łączy się z innymi standarami z "rodziny" brytyjskich standardów zarządzania AXELOS® Global Best Practice

11.6. Rodzina brytyjskich standardów zarządzania AXELOS® Global Best Practice

11.6.1. ITIL®

11.6.1.1. see ITIL® mindmap

11.6.2. M_o_R® - Management of Risk

11.6.2.1. see M_o_R® mindmap

11.6.3. MoV® - Management of Value

11.6.3.1. see MoV® mindmap

11.6.4. MoP® - Management of Portfolios

11.6.4.1. see MoP® mindmap

11.6.5. MSP® - Managing Successful Programmes

11.6.5.1. see MSP® mindmap

11.6.6. P3O® - Portfolio, Programme and Project Office

11.6.6.1. see P3O® mindmap

11.7. Metodyka PRINCE® została po raz pierwszy wprowadzona w 1989 r. przez CCTA (ang.: Central Computer and Telecommunications Agency) jednak została oparta na metodyce PROMPTII stworzonej w 1975 roku.

11.7.1. Oryginalnie oparta została na metodyce PROMPTII utworzonej przez Simpact Systems Ltd w 1975 r. , stosowanej przez CCTA jako narzędzie realizacji informatycznych projektów rządowych.

11.8. W 1996 została wprowadzona metodyka PRINCE2®, która jest niezależna od dziedziny biznesowej i może być stosowana w każdym projekcie (oczywiście po uprzednim jej dostosowaniu).

11.8.1. Prototypem dla metodyki PRINCE2® była metodyka PRINCE®.

12. PRINCE2® to: 7 Pryncypiów, 7 Tematów, 7 Procesów, 40 Pod-procesów, 10 Ról projektowych, 4 Role nadzoru jakości, 3 Typy zagadnień, 3 Poziomy zarządzania, 2 Techniki, 2 Procedury, 3 Typy budżetów, 5 Czynników projektowych, 6 Zmiennych projektowych (aspekty efektywności), 26 Produktów zarządczych (podzielonych na 3 rodzaje)

12.1. Pobierz: PRINCE2® Macierz Procesy vs Produkty Zarządczy vs Role vs Odpowiedzialności (PDF)

12.1.1. http://miroslawdabrowski.com/downloads/PRINCE2/Reference%20cards/PRINCE2%20-%20Macierz%20Procesy%20vs%20Produkty%20Zarzadcze%20vs%20Role%20vs%20Odpowiedzialnosci%20%5Bv1.2%2C%2011.2013%2C%20PL%5D.pdf

12.2. Pobierz: Model Procesów PRINCE2® (PDF)

12.2.1. http://miroslawdabrowski.com/downloads/PRINCE2/Reference%20cards/PRINCE2%20-%20Macierz%20Procesy%20vs%20Produkty%20Zarzadcze%20vs%20Role%20vs%20Odpowiedzialnosci%20%5Bv1.2%2C%2011.2013%2C%20PL%5D.pdf

13. Oficjalne publikacje PRINCE2®

13.1. PRINCE2® Skuteczne Zarządzanie Projektami

13.1.1. ISBN-13: 978-0113312245

13.1.2. 365 stron

13.1.3. http://www.amazon.com/PRINCE2-Skuteczne-Zarzadzanie-Projektami-Edition/dp/0113312245

13.1.4. Najważniejsza, kluczowa pozycja dotycząca PRINCE2® przygotowująca do egzaminów Foundation, Practitioner oraz Professional.

13.1.4.1. Przydatna (ale nie niezbędna) pozycja podczas przygotowań (również samodzielnych) do egzaminu Foundation

13.1.4.2. Niezbędna pozycja podczas egzaminu Practitioner

13.1.4.3. Podczas egzaminu Practitioner można jedynie korzystać z tego podręcznika

13.1.4.3.1. Organizacja szkoleniowa w przypadku braku własnego podręcznika przez kandydata powinna udostępnić podręcznik na czas egzaminu

13.1.5. Jedyna oficjalna pozycja na temat PRINCE2® dostępna w języku PL.

13.2. Directing Successful Projects with PRINCE2®

13.2.1. ISBN-13: 978-0113310609

13.2.2. 166 stron

13.2.3. http://www.amazon.com/Directing-Successful-Projects-PRINCE2-Edition/dp/0113310609

13.3. Passing your PRINCE2 Examinations 2009 Edition

13.3.1. ISBN-13: 978-0113311903

13.3.2. 172 stron

13.3.3. http://www.amazon.com/Passing-your-PRINCE2-Examinations-Edition/dp/0113311907

13.4. PRINCE2® Maturity Model (P2MM)

13.4.1. 34 strony

13.4.2. http://www.p3m3-officialsite.com/nmsruntime/saveasdialog.aspx?lID=462&sID=210

13.4.3. Pozycja darmowa, oficjalna, dostępna online.

13.5. PRINCE2® Maturity Model (P2MM) - Self-Assessment

13.5.1. 22 strony

13.5.2. http://www.p3m3-officialsite.com/nmsruntime/saveasdialog.aspx?lID=469&sID=210

13.5.3. Pozycja darmowa, oficjalna, dostępna online.

14. Interaktywny glosariusz

14.1. Interaktywny glosariusz PRINCE2® (PL)

15. Ta darmowa mapa (zgodna z najnowszą wersją metodyki PRINCE2®) została pieczołowicie stworzona z pasji i zamiłowania do nauki oraz ciągłego rozwoju jak również w celu promocji metodyki PRINCE2®. Mapa pomoże Ci również w nauce do egzaminów Foundation i Practitioner z metodyki PRINCE2®. (podziel się tą mapą z innymi, polub i przekaż informacje zwrotne - Twoja opinie, komentarze i sugestie są moją motywacją do dalszego jej rozwoju THX.!)

15.1. Pytania / wątpliwość / błędy? Zapraszam do kontaktu. Mapa powstała jako pomoc w Twojej nauce. Każda uwaga jest cenna.

15.1.1. http://www.miroslawdabrowski.com

15.1.2. http://www.linkedin.com/in/miroslawdabrowski

15.1.3. https://www.google.com/+MiroslawDabrowski

15.1.4. https://play.spotify.com/user/miroslawdabrowski/

15.1.5. https://twitter.com/mirodabrowski

15.1.6. miroslaw_dabrowski

16. Techniki (2)

16.1. Obie techniki są związana z tematem Jakość.

16.2. Technika planowania opartego na produktach (ang. Product-based Planning)

16.2.1. Cel

16.2.1.1. Identyfikacja produktów które mają być wytworzone lub uzyskane w projekcie

16.2.1.1.1. Znacząco pomaga to w jednoznacznym określeniu zakresu projektu.

16.2.1.2. Określenie dodatkowych produktów potrzebnych do wytworzenia produktu głównego

16.2.1.3. Wypracowanie najlepszego pogrupowania tych produktów

16.2.2. Jest to trzystopniowa, oparta na diagramach, technika prowadząca do ogólnego planu bazującego na wytwarzaniu i dostawach wymaganych wyników projektu.

16.2.2.1. Planowanie oparte na produktach jest integralną częścią PRINCE2® dotyczącą koncentracji na jakości produktów.

16.2.2.2. Technika ta zapewnia platformę planistyczną opartą na produktach, która pozwala ustawić prace nad projektem w logicznej kolejności.

16.2.3. Należy pamiętać przy tym, że w metodyce PRINCE2® pod pojęciem produktów rozumiane są zarówno te materialne, np. dokument, czy część oprogramowania, jak i te niematerialne - np. nowa struktura organizacyjna.

16.2.4. W ramach techniki planowania opartego na produktach powstają cztery produkty zarządcze (krok po kroku, sekwencyjnie):

16.2.4.1. 1. Opis Produktu Końcowego Projektu

16.2.4.2. 2. Diagram struktury produktów (ang. product breakdown structure)

16.2.4.2.1. Jest to hierarchiczne przedstawienie wszystkich produktów, które mają być wytworzone w ramach planu (Planu Projektu lub Planu Etapu).

16.2.4.2.2. Tworząc strukturę produktową zaczyna się od ustalenia produktu projektu (krok 1) i dekompozycji na podprodukty (krok 2).

16.2.4.3. 3. Opis Produktu dla każdego z produktów

16.2.4.3.1. Jasny, kompletny i jednoznaczny opis produktu stanowi ogromną pomoc przy jego tworzeniu.

16.2.4.3.2. Opis taki zawiera informacje o zastosowaniu produktu, kryteriach jakości, tolerancji jakości, ilość wymaganych produków etc.

16.2.4.4. 4. Diagram następstwa produktów

16.2.4.4.1. Diagram następstwa produktów pokazuje kolejność produkowania oraz wzajemne zależności pomiędzy produktami wymienionymi w strukturze projektowej.

16.3. Technika przeglądu jakości

16.3.1. Cel

16.3.1.1. Ocena zgodności z ustalonymi kryteriami produktu w postaci dokumentu (lub prezentacji czy wyników testu)

16.3.1.2. Zaangażowanie kluczowych zainteresowanych stron w sprawdzenie jakości produktu oraz działania na rzecz szerszej akceptacji produktu

16.3.1.3. Potwierdzenie, że produkt został ukończony i jest gotowy do zatwierdzenia

16.3.1.4. Ustanowienie obiektu odniesienia dla produktu na potrzeby sterowania zmianami

16.3.2. „Przegląd jakości", służy do testowania jakości produktów będących dokumentami.

16.3.2.1. Zasady tej techniki mogą być również zastosowane do testowania i przeglądów jakości pozostałych produktów.

16.3.2.2. Przegląd jakości można przeprowadzić w każdym stadium projektu, gdyż każdy produkt może zostać poddany przeglądowi jakości, jeśli istnieją właściwe mu elementy jakości, które powinny być monitorowane.

16.3.3. W PRINCE2® wyróżnia się 4 specyficzne role związane z przeglądem jakości:

16.3.3.1. Kierownik przeglądu jakości

16.3.3.1.1. przewodniczy naradzie przeglądu jakości i odpowiada za jej zorganizowanie, program, przebieg, uzgodnione zadania oraz ustalenie wyniku wspólnie z testerami.

16.3.3.2. Prezenter

16.3.3.2.1. dostarcza stosowne produkty do przeglądu jakości i reprezentuje ich wytwórców; jego zadaniem jest także koordynowanie i śledzenie prac po przeglądzie jakości - np. zastosowanie w produkcie uzgodnionych zmian.

16.3.3.3. Kontroler / Recenzent

16.3.3.3.1. dokonuje przeglądu produktu, ocenia jego zgodność z kryteriami jakości w Opisie Produktu, dokumentuje zastrzeżenia w tym aspekcie i potwierdza, czy dokonane zostały wszelkie zalecane działania następcze.

16.3.3.4. Administrator

16.3.3.4.1. zapewnia pomoc administracyjną Kierownikowi, notuje działania uzgodnione w czasie narady przeglądu jakości i przydzielone do ich wykonania osoby.

16.3.3.5. Role mogą być łączone

16.3.3.5.1. Najmniejsza forma to 2 osoby

16.3.4. W procedurze przeglądu jakości należy wykonać 3 podstawowe kroki

16.3.4.1. 1. Przygotowanie przeglądu (oraz przeprowadzenie przeglądu)

16.3.4.1.1. 1. potwierdzenia, że produkt jest gotowy do przeglądu,

16.3.4.1.2. 2. potwierdzenia dostępności wyznaczonych testerów oraz uzgodnienia daty zwrotu uwag testerów oraz daty samego przeglądu,

16.3.4.1.3. 3. rozprowadzenia wśród testerów kopii produktu oraz jego Opisu Produktu, tam gdzie jest to możliwe, np. jeśli jest to drukowany dokument; alternatywnie może to być udostępnienie produktu do zbadania przez testerów,

16.3.4.1.4. 4. oceny zgodności produktu z kryteriami jakości,

16.3.4.1.5. 5. zapisania zastrzeżeń oraz podejrzewanych błędów na liście zastrzeżeń,

16.3.4.1.6. 6. odnotowania mniej ważnych błędów na produkcie (np. gramatycznych i ortograficznych),

16.3.4.1.7. 7. zwrócenia produktu z adnotacjami wraz z listą zastrzeżeń do wytwórcy,

16.3.4.1.8. 8. zaplanowania narady przeglądu jakości oraz uzgodnienia jej programu (agendy).

16.3.4.2. 2. Narada przeglądu jakości (jeśli wykryto niezgodności w produktach w 1 kroku)

16.3.4.2.1. 1. dyskusji, wyjaśnienia oraz uzgodnienia wszystkich spraw przedstawionych przez testerów,

16.3.4.2.2. 2. uzgodnienia działań następczych odpowiednich dla każdego uzgodnionego błędu,

16.3.4.2.3. 3. udokumentowania odpowiedzialności za działania następcze,

16.3.4.2.4. 4. podsumowania zaplanowanych działań na koniec narady,

16.3.4.2.5. 5. uzgodnienia wyniku przeglądu jakości oraz podpisania zatwierdzenia produktu, jeśli jest to możliwe,

16.3.4.2.6. 6. zaktualizowania Rejestru Jakości.

16.3.4.3. 3. Działania po naradzie przeglądu jakości

16.3.4.3.1. 1. powiadomienia Kierownika Projektu i/lub Kierownika Zespołu o wyniku przeglądu jakości,

16.3.4.3.2. 2. zaplanowania wszelkich potrzebnych prac naprawczych,

16.3.4.3.3. 3. podpisania zatwierdzenia produktu w następstwie zakończonych powodzeniem prac naprawczych,

16.3.4.3.4. 4. zaktualizowania Rejestru Jakości.

17. Procedury (2)

17.1. Obie procedury są związana z tematem Zmiana.

17.2. Procedura sterowania zagadnieniami i zmianami

17.2.1. 5 kroków działających sekwencyjnie

17.2.1.1. 1. Zarejestruj

17.2.1.1.1. Określ rodzaj zagadnienia

17.2.1.1.2. Określ wagę, priorytet

17.2.1.1.3. Zapisz w Dzienniku Projektu lub Rejestrze Zagadnień

17.2.1.2. 2. Analizuj

17.2.1.2.1. Oceń wpływ na cele projektu, Uzasadnienie Biznesowe i profil ryzyka projektu

17.2.1.2.2. Sprawdź wagę, priorytet

17.2.1.3. 3. Proponuj

17.2.1.3.1. Określ możliwe opcje reakcji

17.2.1.3.2. Oceń opcje

17.2.1.3.3. Rekomenduj opcje

17.2.1.4. 4. Zdecyduj

17.2.1.4.1. Przekaż wyżej, jeśli poza delegowanymi uprawnieniami

17.2.1.4.2. Zatwierdź, odrzuć lub odrocz rekomendowaną opcję

17.2.1.5. 5. Wdrażaj

17.2.1.5.1. Podejmij działania korygujące

17.2.1.5.2. Uaktualnij zapisy i plany

17.3. Procedura zarządzania konfiguracją

17.3.1. 5 kroków działających sekwencyjnie

17.3.1.1. 1. Planowanie

17.3.1.1.1. Określenie, jaki poziom szczegółowości zarządzania konfiguracją jest właściwy dla projektu.

17.3.1.2. 2. Identyfikowanie

17.3.1.2.1. Identyfikowanie obiektów konfiguracji na ustalonym poziomie szczegółowości.

17.3.1.3. 3. Sterowanie

17.3.1.3.1. zatwierdzanie produktów projektu,

17.3.1.3.2. nadawanie im statusu obiektów odniesienia,

17.3.1.3.3. wprowadzanie zmian zgodnie z procedurą i przez uprawnionych decydentów,

17.3.1.3.4. archiwizowanie poprzednich wersji obiektów odniesienia,

17.3.1.3.5. przechowywanie i odzyskiwanie informacji istotnych dla zarządzania projektem,

17.3.1.3.6. zapewnianie bezpieczeństwa,

17.3.1.3.7. kontrolowanie dostępu,

17.3.1.3.8. dystrybuowanie kopii obiektów konfiguracji,

17.3.1.3.9. archiwizowanie dokumentacji projektu.

17.3.1.4. 4. Zestawienie statusu

17.3.1.4.1. Tworzenie raportu Zestawienie Statusu Produktów w celu uchwycenia bieżących i historycznych danych dotyczących danych produktów.

17.3.1.5. 5. Weryfikowanie i audyt (konfiguracji)

17.3.1.5.1. Weryfikowanie, czy faktyczny zatwierdzony stan produktów odpowiada ich statusom zarejestrowanym w Zapisach Obiektów Konfiguracji.

17.3.1.5.2. Sprawdzenie, czy w projekcie zarządzanie konfiguracją odbywa się zgodnie z wytycznymi Strategii Zarządzania Konfiguracją.

18. Oficjalne zasoby PRINCE2®

18.1. Przykładowe egzaminy PRINCE2®, dostępne online

18.1.1. Foundation

18.1.1.1. http://www.apmg-exams.com/index.aspx?subid=8

18.1.2. Practitioner

18.1.2.1. https://www.exin.com/assets/exin/exams/2050/samples/polish_sample_exam_fx02_pr2p_201311.pdf

18.1.2.2. http://www.apmg-exams.com/index.aspx?subid=9

18.2. Sylabus egzaminacyjny PRINCE2®

18.2.1. Sylabus opisuje zakres wiedzy wymaganej na poziomie egzaminów Foundation i Practitioner

18.2.2. http://www.prince-officialsite.com/nmsruntime/saveasdialog.aspx?lID=1731&sID=406

18.3. Glosariusz PRINCE2®

18.3.1. EN

18.3.1.1. http://www.prince-officialsite.com/nmsruntime/saveasdialog.aspx?lID=1486&sID=557

18.3.2. PL

18.3.2.1. http://www.prince-officialsite.com/nmsruntime/saveasdialog.aspx?lID=1515&sID=557

18.4. Szablony dokumentów PRINCE2®

18.4.1. http://www.prince-officialsite.com/nmsruntime/saveasdialog.aspx?lID=1493&sID=455

18.5. Strona PRINCE2®

18.5.1. http://www.prince-officialsite.com/

19. Pytania przygotowujące do egzaminu PRINCE2® Foundation

19.1. http://miroslawdabrowski.com/downloads/PRINCE2/Exam%20prep%20questions/

20. Role Przeglądu Jakości (4)

20.1. Kierownik przeglądu jakości

20.1.1. przewodniczy naradzie przeglądu jakości i odpowiada za jej zorganizowanie, program, przebieg, uzgodnione zadania oraz ustalenie wyniku wspólnie z testerami.

20.2. Prezenter

20.2.1. dostarcza stosowne produkty do przeglądu jakości i reprezentuje ich wytwórców; jego zadaniem jest także koordynowanie i śledzenie prac po przeglądzie jakości - np. zastosowanie w produkcie uzgodnionych zmian.

20.3. Kontroler / Recenzent

20.3.1. dokonuje przeglądu produktu, ocenia jego zgodność z kryteriami jakości w Opisie Produktu, dokumentuje zastrzeżenia w tym aspekcie i potwierdza, czy dokonane zostały wszelkie zalecane działania następcze.

20.4. Administrator

20.4.1. zapewnia pomoc administracyjną Kierownikowi, notuje działania uzgodnione w czasie narady przeglądu jakości i przydzielone do ich wykonania osoby.