PRINCE2® - PRojects IN Controlled Environments 2

1. PRINCE2® Roles (10)

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

1.2. Project Board (PB) (3)

1.2.1. represents 3 sides of intrests

1.2.1.1. clients side

1.2.1.1.1. Senior User(s)

1.2.1.2. business side

1.2.1.2.1. Executive

1.2.1.3. supplier side

1.2.1.3.1. Senior Supplier(s)

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

1.2.2.1. to sytuacja typowo teoretyczna, nieralna w praktyce

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

1.2.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.2.5. Komitet Sterujący to organ, który ostatecznie zatwierdza zakończenie każdego etapu i zezwala na rozpoczęcie etapu następnego.

1.2.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.2.7. Zatwierdza nominacje i obowiązki Kierownika Projektu oraz delegowanie swoich obowiązków związanych z Nadzorem Projektu.

1.2.8. K. S. ponosi całościową odpowiedzialność za projekt zgodnie z instrukcjami

1.2.8.1. odpowiedzialny za "sukces projektu"

1.2.9. Dla wtajemniczonych ...

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

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

1.3. Project Assurance (PA) (3)

1.3.1. Nadzór projektu oznacza delegowanie obowiązków Komitetu Sterującego związanych z zapewnieniem, że projekt jest realizowany właściwie.

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

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

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

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

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

1.3.2.1.3. zagrożenia są kontrolowane

1.3.2.1.4. Uzasadnienie Biznesowe jest przestrzegane,

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

1.3.2.1.6. projekt jest zgodny ze Wizja, Misją i Strategią organizacji,

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

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

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

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

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

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

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

1.3.2.1.14. prowadzenie projektu jest nadal uzasadnione,

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

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

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

1.3.2.1.18. przestrzegane są wszystkie ograniczenia prawne,

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

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

1.3.2.1.21. ...

1.3.3. dzieli się na 3 strony

1.3.3.1. Nadzór ze strony biznesu

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

1.3.3.2. Nadzór ze strony dostawcy

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

1.3.3.3. Nadzór ze strony użytkownika

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

1.3.4. Rola wymagana, ale ...

1.3.4.1. Jeśli nie jest delegowana, odpowiedzialność przejmują konkretne osoby z K.S.

1.4. Change Authority (CA)

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

1.4.2. O.Z. znajduje się nad K.P. w kwestii uprawnień o wprowadzenie zmian

1.4.2.1. K.P. przesyła wnioski o wprowadzenie zmiany (w postaci Raprtu o Zagadnieniu) do O.Z. z prośbą o podjęcie decyzji (akceptację, odrzucenie, odroczenie decyzji)

1.4.3. Rola wymagana, ale ...

1.4.3.1. Jeśli nie jest delegowana, odpowiedzialność przejmuje Komitet Sterujący.

1.4.3.2. W szczególnych przypadkach, K. S. może przekazać rolę O. Z. dla K. P.

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

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

1.4.4.1.1. Organizacja

1.4.4.1.2. K.S.

1.4.4.1.3. O.Z.

1.4.4.1.4. K.P.

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

1.5. Project Manager (PM)

1.5.1. Rola wymagana

1.5.2. Rola niepodzielna, zawsze 1 Kierownik Projektu

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

1.5.4. Kierownik Projektu nie może być łączony z Przewodniczącym

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

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

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

1.5.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.5.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.5.8. Odpowiedzialny ze osiągniecie CELÓW projektu (dostarczenie produktów specialistycznych)

1.5.8.1. CELÓW nie SUKCESU projektu

1.5.9. Dla wtajemniczonych ...

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

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

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

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

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

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

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

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

1.5.9.5. Reakcja Kierownika Porjektu po zatwierdzeniu zwiększenia budżetu projektowego :-)

1.6. Team Manager(s) (TM)

1.6.1. Wytwarza produkty specjalistyczne

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

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

1.6.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.6.4. Kierownik Zespołu podlega Kierownikowi Projektu i przyjmuje od niego instrukcje.

1.6.5. Przygotowuje Raporty z Punktów Kontrolnych

1.6.6. Rola wymagana, ale ...

1.6.6.1. Jeśli nie jest delegowana, odpowiedzialność przejmuje K.P.

1.6.7. Dla wtajemniczonych ...

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

1.6.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 gaż to ukończę PRINCa w czas."

1.6.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.6.7.2. (miś) "A niech rzesz Pan siada i opowiada! Nowiny! Nowiny!"

1.7. Project Support (PS)

1.7.1. Rola która dostarcza jedynie wsparciae administracyjne, bez jakichkolwiek uprawnien decyzyjnych.

1.7.2. Rola wymagana, ale ...

1.7.2.1. Jeśli nie jest delegowana, odpowiedzialność przejmuje K.P.

1.7.3. Rola którą domyślnie pełni K.P.

1.7.3.1. Rola domyślnie jest łączona z rolą K.P.

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

2. Project Management according to PRINCE2®

2.1. The goal of project management according to PRINCE2®:

2.1.1. Maintaining control over the work of the specialist

2.1.2. Motivating people involved

2.1.3. Maintain current knowledge of the state of the project

2.1.4. Ensuring that the project still has a valid business justification

2.2. Project management according to PRINCE2® is a constant cycle

2.2.1. Project management cycle according to PRINCE2® (based on Deming cycle)

2.2.1.1. Plan

2.2.1.1.1. Planning work to be done.

2.2.1.2. Delegate

2.2.1.2.1. Delegating work to be done to other people / individuals / companies / contractors etc.

2.2.1.3. Monitor

2.2.1.3.1. Monitoring the performance of work through reports and communication.

2.2.1.4. Control

2.2.1.4.1. Controlling the job by taking corrective actions.

2.2.1.5. planning, delegating, monitoring, controlling all aspects of the project ...

2.3. Key benefits of adopting PRINCE2®

2.3.1. Applies to any type or project and business domain

2.3.1.1. Generic

2.3.2. License-free

2.3.2.1. Non-proprietary method

2.3.3. Widely recognized and understood

2.3.3.1. Common vocabulary and approach

2.3.4. Project security with EWIs and risk management

2.3.5. Embodies established and proven best practice and governance

2.3.5.1. Full project control/assurance

2.3.6. Provides for the explicit recognition of project responsibilities

2.3.6.1. Accountability with clearly defined roles

2.3.7. Clarifies (for all parties) what a project will deliver, why, when, by whom and for whom

2.3.8. Plans are carefully designed to meet the needs of the different levels in the management team

2.3.9. Providing for the efficient and economic use of management time by using “management by exception” approach

2.3.10. Ensures that participants focus on the viability of the project

2.3.11. Ensures that stakeholders (including sponsors and resource providers) are properly represented

2.3.12. Promotes Learning and continual improvement

2.3.13. Promotes consistency of project work and the ability to reuse project assets

2.3.14. Facilitates team mobility

2.3.15. Integration with Agile (e.g. DSDM/AgilePM/Scrum)

3. PRINCE2® Processes (7)

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

3.1.1. Niektóre procesy działają równolengle, niektóre sekwencyjnie.

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

3.3. Processes are positioned across 3 levels (yet PRINCE2® recognizes 4 levels):

3.3.1. Level 1 - Corporate or Programme Management (outside PRINCE2®)

3.3.1.1. The top level is the Corporate or ‘Programme Management" Level. The only product created in this level is the Project Mandate.

3.3.2. Level 2 - Directing - Project Board

3.3.2.1. The Direction or "Directing* Level is where the Project Board works. They interface often with the Management Level and provide the above level with a number of notifications.

3.3.3. Level 3 - Managing - Project Manager

3.3.3.1. “Management" and it is where the Project Manager works. It contains most of the activities and processes, such as Initiating a Project and Controlling a Stage. Most of the management activities for a project are done by the Project Manager.

3.3.4. Level 4 - Delivering - Team Manager

3.3.4.1. The bottom level, “Delivery." is where the project's products are created.

3.4. Starting up a Project (SP)

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

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

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

3.4.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.4.3. Obecny w fazie przed projektowej

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

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

3.4.3.1.2. Są wytwarzane jedynie podstawowe produkty zarządcze

3.4.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.4.4.1. Praca wykonywana głównie przez Przewodniczącego i Kierownika Projektu

3.4.5. Egzamin Foundation

3.4.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.4.5.2. Procesu PP należy nie mylić z fazą przed projektową (inna nazwa to czynności przed projektowe)

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

3.4.6. Praktyka

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

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

3.4.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.4.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.4.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.4.6.3.1. Praca z dostawcą rozpoczyna się pierwszy etap w PRINCE2® - Etap Inicjowania, gdzie wspólnie z dostawcą budowany jest min. DIP

3.4.7. Rekomendowane czynności w procesie

3.4.7.1. 1. Mianowanie Przewodniczącego i Kierownika Projektu

3.4.7.2. 2. Zgromadzenie dotychczasowych doświadczeń

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

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

3.4.7.5. 5. Przygotowanie zarysu Uzasadnienia Biznesowego

3.4.7.6. 6. Planowanie etapu inicjowania

3.5. Directing a Project (DP)

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

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

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

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

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

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

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

3.5.5. Rekomendowane czynności w procesie

3.5.5.1. Zezwalanie na zainicjowanie projektu

3.5.5.2. Zezwalanie na realizację projektu

3.5.5.3. Zezwalanie na realizację Planu Etapu lub Planu Nadzwyczajnego

3.5.5.4. Podejmowanie decyzji doraźnej

3.5.5.5. Zezwalanie na zamknięcie projektu

3.6. Initiating a Project (IP)

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

3.6.2. Obecny w Etapie Inicjowania

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

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

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

3.6.4. Rekomendowane czynności w procesie

3.6.4.1. Opracowanie Strategii Zarządzania Ryzykiem

3.6.4.2. Opracowanie Strategii Zarządzania Jakością

3.6.4.3. Opracowanie Strategii Zarządzania Konfiguracją

3.6.4.4. Opracowanie Strategii Zarządzania Komunikacją

3.6.4.5. Sporządzanie Planu Projektu

3.6.4.6. Ustanowienie mechanizmów sterowania projektem

3.6.4.7. Doprecyzowanie Uzasadnienia Biznesowego

3.6.4.8. Zestawianie Dokumentacji Inicjowania Projektu (DIP)

3.6.5. Egzamin Foundation

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

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

3.6.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.6.5.2.1. Sygnał 1 - Wniosek o realizację projektu (całego projektu)

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

3.7. Controlling a Stage (CS)

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

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

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

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

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

3.7.4. Rekomendowane czynności w procesie

3.7.4.1. Zezwalanie na wykonanie Grupy Zadań

3.7.4.2. Przeglądanie stanu Grupy Zadań

3.7.4.3. Odbieranie zakończonych Grup Zadań

3.7.4.4. Przeglądanie stanu etapu

3.7.4.5. Podejmowanie działań korygujących

3.7.4.6. Wychwytywanie i badanie zagadnień i ryzyk

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

3.7.4.8. Raportowanie okresowe

3.8. Managing Product Delivery (MPD)

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

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

3.8.2.1. Praca Kierownika Zespołu (KZ)

3.8.3. Obecny w etapach realizacyjnych

3.8.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.8.3.1.1. przypadek najmniejszej wersji PRINCE2 - 1 etapowego projektu (tzw. Mały Książę)

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

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

3.8.5.1. ZATWIERDZENIA (nie mylić z akceptacją)

3.8.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.8.6. Rekomendowane czynności w procesie

3.8.6.1. Przyjmowanie Grupy Zadań do wykonania

3.8.6.2. Wykonywanie Grupy Zadań

3.8.6.3. Oddawanie wykonanej Grupy Zadań

3.9. Managing a Stage Boundary (MSB)

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

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

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

3.9.2.1. Praca wykonywana głownie przez Kierownika Projektu

3.9.3. Rekomendowane czynności w procesie

3.9.3.1. Planowanie następnego etapu

3.9.3.2. Sporządzanie Planu Nadzwyczajnego

3.9.3.3. Uaktualnianie Planu Projektu

3.9.3.4. Uaktualnianie Uzasadnienia Biznesowego

3.9.3.5. Raportowanie zakończenia etapu

3.10. Closing a Project (CP)

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

3.10.1.1. W ostatnim, końcowym etapie projektu

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. W procesie ZP odbywa się akceptacja końcowego produktu projektu

3.10.3.1. AKCEPTACJA (nie mylić z zatwierdzeniem)

3.10.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.10.4. Rekomendowane czynności w procesie

3.10.4.1. Przygotowanie planowego zamknięcia

3.10.4.2. Przygotowanie przedwczesnego zamknięcia

3.10.4.3. Przekazanie produktów

3.10.4.4. Ocenianie projektu

3.10.4.5. Rekomendowanie zamknięcia projektu

4. PRINCE2® Themes (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.2. Każdy z tematów zgdonie ze swoim przeznaczeniem odpowiada na konkretne pytanie.

4.3. 1. Business Case

4.3.1. All projects are based on an idea that has potential value for the organization. The Business Case theme addresses how this idea can be developed and converted into a viable investment and business solution.

4.3.1.1. The Business Case theme helps the project manager stay focused on the business objectives throughout the project and it answers the questions; Why are we doing this project? What are the benefits and the return?

4.3.2. Temat odpowiada na pytanie ...

4.3.2.1. Dlaczego?

4.3.2.1.1. Dlaczego projekt jest nam potrzebny?

4.3.2.1.2. Dlaczego powinniśmy rozpocząć projekt?

4.3.2.1.3. Dlaczego powinniśmy kontynuować projekt?

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

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

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

4.3.3.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.4. Project zgodny z PRINCE2® ma ciągle ważne uzasadnienie biznesowe.

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

4.3.4.1.1. potrzebny

4.3.4.1.2. przydatny

4.3.4.1.3. wykonalny

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

4.3.5.1. 1. Opracowanie Uzasadnienia Biznesowego

4.3.5.2. 2. Weryfikowanie Uzasadnienia Biznesowego

4.3.5.3. 3. Utrzymywanie Uzasadnienia Biznesowego

4.3.5.4. 4. Potwierdzenie Uzasadnienia Biznesowego

4.4. 2. Organisation

4.4.1. For a project to be successful, clear accountabilities must be allocated to managers of the organization so that they can steer the project through to completion. As projects are cross-functional normal line structures are not suitable.

4.4.1.1. The Organization theme defines the roles and responsibilities on the project and helps answer the questions; Who does what? Who are the stakeholders? How do we effectively communicate with them?

4.4.2. Temat odpowiada na pytanie ...

4.4.2.1. Kto?

4.4.2.1.1. Kto za co odpowiada w projekcie?

4.4.3. 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.4. 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.4.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.4.1.1. Każdy projekt wymaga skutecznego kierowania, zarządzania, kontroli i komunikacji.

4.4.4.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.5. PRINCE2® wyróżnia 4 poziomy w organizacji (4 poziomy zarządzania projektem)

4.4.5.1. 1. Kierownictwo organizacji / programu (spoza projektu, "nad nim")

4.4.5.1.1. Zlecanie projektu

4.4.5.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.5.2. 2. Komitet Sterujący

4.4.5.2.1. Kierowanie projektem

4.4.5.2.2. Strategiczne zarządzanie projektem

4.4.5.3. 3. Kierownk Projekt

4.4.5.3.1. Operacyjne zarządzanie projektem

4.4.5.4. 4. Kierownicy Zespołów

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

4.4.6. Stakeholders

4.4.6.1. A project requires identification, analysis and communication with stakeholders.

4.4.6.1.1. Project decision makers are stakeholders making decisions.

4.4.6.2. Stakeholders are individuals or groups not part of the project management team who may need to interact with the project or who may be affected by the project’s outcome.

4.4.6.3. They support or oppose the project, gain or lose, and perceive the project as a threat or enhancement. It is important to identify and engage with them appropriately.

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

4.5. 3. Quality

4.5.1. The Quality theme explains how to develop the initial idea of the project into specific quality attributes and ensure that everyone on the team understands exactly what the project needs to deliver. The theme also explains how project management can subsequently make sure that the specified requirements are delivered.

4.5.1.1. The Quality theme answers the questions; What level of quality do we need? How do we plan and control quality?

4.5.2. Temat odpowiada na pytanie ...

4.5.2.1. Co?

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

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

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

4.5.4.1. spełniają oczekiwania biznesowe

4.5.4.2. umożliwiają w efekcie uzyskanie pożądzanych korzyści opisanych w Uzasadnieniu Biznesowych

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

4.5.5.1. Oczekiwania jakościowe klienta

4.5.5.2. Kryteria akceptacji

4.5.5.3. Opis Produktu Końcowego Projektu

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

4.5.5.5. Strategia Zarządzania Jakością

4.5.5.6. Opisy Produktów i kryteria jakości

4.5.5.7. Tolerancje jakości

4.5.5.8. Przegląd jakości (technika)

4.5.5.9. Rejestr Jakości

4.5.5.10. Zapisy zatwierdzeń

4.5.5.11. Zapisy akceptacji

4.6. 4. Plans

4.6.1. A PRINCE2 project contains a series of approved plans that match the various levels of the project organization. The Plans theme describes the steps required to develop these plans along with the PRINCE2 techniques that should be applied. These plans are the focus for communication and control throughout the project.

4.6.1.1. The Plans theme asks the questions; How is it done? How much resource do we need? When do we finish?

4.6.2. Temat odpowiada na pytanie ...

4.6.2.1. Jak? Za ile? Kiedy?

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

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

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

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

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

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

4.6.5.1. 1. Plan Projektu (obowiązkowy)

4.6.5.2. 2. Plan Etapu (obowiązkowy)

4.6.5.3. 3. Plan Zespołu (opcjonalny)

4.6.5.4. 4. Plan Nadzwyczajny

4.7. 5. Risk

4.7.1. Projects typically entail more risk than steady day to-day activities. The Risk theme addresses how project management addresses and mitigates the uncertainties in the project’s plans and in the wider project environment.

4.7.1.1. The Risk theme answers the questions; What if a certain event happens? How are risks managed? How to Report Risks?

4.7.2. Temat odpowiada na pytanie ...

4.7.2.1. Co, jeżeli?

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

4.7.3. 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.3.1. Zarządzanie ryzykiem polega na utrzymywaniu ryzyka w akceptowalnych granicach w sposób efektywny i racjonalny kosztowo.

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

4.7.5. 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.6. 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.6.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.7. Cykl zarządzania ryzykiem składa się z kroków:

4.7.7.1. 1. Identyfikuj

4.7.7.1.1. dzieli się na dwa pod kroki

4.7.7.2. 2. Oceniaj

4.7.7.2.1. dzieli się na dwa pod kroki

4.7.7.3. 3. Planuj

4.7.7.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.7.4. 4. Wdrażaj

4.7.7.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.7.5. Komunikacja

4.7.7.5.1. komunikacja to krok, który jest realizowany ciągle. 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.8. Parametry ryzyka w PRINCE2:

4.7.8.1. Prawdopodobieństwo

4.7.8.2. Bliskość

4.7.8.3. Wpływ

4.8. 6. Change

4.8.1. The Change theme describes how project management handles issues that have the potential to impact any of the baseline aspects of the project, i.e. the project’s plans and completed products. When we say “issues” we mean general problems, requests for changes or quality failures.

4.8.1.1. The Change theme answers the questions; What is the impact of this change? What is the procedure for documenting and handling issues?

4.8.2. Temat odpowiada na pytanie ...

4.8.2.1. Jaki jest wpływ?

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

4.8.3. 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.9. 7. Progress

4.9.1. The Progress theme makes sure that the necessary controls and monitoring mechanisms are in place and that the project’s plans are still viable. It explains the decision-making process for approving plans, monitoring performance and escalating issues if events don’t go according to plan. Ultimately, this theme determines whether and how the project should progress.

4.9.1.1. The Progress theme answers the questions; Where are we now? Where are we going? Should we carry on?

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. Odpowiada na pytanie ...

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

4.9.3.1.1. Jak ocenić progres projektu?

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

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

5. PRINCE2® Principles (7)

5.1. The building blocks upon which the PRINCE2® themes and PRINCE2® processes are based

5.2. In PRINCE2, all principles are rules and must be followed

5.3. Principles are universally applicable statements.

5.3.1. Principles are generic principles - the way in which they are applied must be tailored to suit the organizational circumstances, whilst ensuring the underlying rationale is maintained.

5.3.2. Prainciples are the common, universal and high-level factors that underpin success.

5.3.3. Principles are self-validating and empowering.

5.3.4. They provide guidance to organizations.

5.3.5. They guide the organization on what to aim for.

5.3.6. The principles provide a framework of good practice.

5.4. According to PRINCE2® (and other AXELOS best practices) principles are:

5.4.1. Universal

5.4.1.1. PRINCE2® is based upon these principles for a very simple reason. By being principles-based, it means that the framework can be applied to any shape, size or type of project.

5.4.1.1.1. In this way, the principles can be universally applied, both to a small in-house company project, or equally to a massive international aid project spanning many borders.

5.4.2. Self-validating

5.4.2.1. These principles have also been proven in practice over many years to be the most effective ways of managing projects i.e. they are based upon modern best practices in project management.

5.4.2.1.1. This means they can be applied directly on projects and the project management team does not need to "re-invent the wheel" by creating their own project management method from scratch.

5.4.3. Empowering

5.4.3.1. The principles are also empowering to the project management team because they can give them added confidence and an ability to shape and manage their projects

5.4.4. in other words "a good, old, PRINCE2® marketing" :-)

5.5. 1. Continued business justification

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

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

5.5.1.1.1. potrzebny

5.5.1.1.2. przydatny

5.5.1.1.3. wykonalny

5.5.2. Wymogiem dla projektu zgodnego z PRINCE2® jest:

5.5.2.1. Istnienie uzasadnionego powodu jego rozpoczecia.

5.5.2.1.1. tzw. "powody podjęcia projektu"

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

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

5.5.2.2.1. Ważność jest kontrolowana min. poprzez kontrolę / sprawdzanie produktu zarządczego Uzasadnienie Biznesowe (A.2)

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

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

5.5.3. Pryncypium wspierane przez:

5.5.3.1. Produkty Zarządcze

5.5.3.1.1. Uzasadnienie Biznesowe (A.2)

5.5.3.2. Role

5.5.3.2.1. Komitet Sterujący (KS)

5.5.3.2.2. Kierownik Projektu (KP)

5.6. 2. Learn from experience

5.6.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.6.2. Wymogiem dla projektu zgodnego z PRINCE2® jest:

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

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

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

5.6.3.1. na początku

5.6.3.1.1. przejrzyj poprzednie lub podobne projekty, zgromadź doświadczenia, jeśli trzeba z zewnątrz organizacji

5.6.3.2. w trakcie trwania

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

5.6.3.3. w czasie zamykania

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

5.6.4. Pryncypium wspierane przez:

5.6.4.1. Produkty Zarządcze

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

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

5.6.4.2. Role

5.6.4.2.1. Komitet Sterujący (KS)

5.6.4.2.2. Kierownik Projektu (KP)

5.7. 3. Defined roles and responsibilities

5.7.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.7.2. Jasna i jednoznaczna struktura zespołu zarządzania projektem.

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

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

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

5.7.5. Pryncypium wspierane przez:

5.7.5.1. Produkty Zarządcze

5.7.5.1.1. Opis roli Przewodniczącego

5.7.5.1.2. Opis roli Kierownika Projekctu

5.7.5.1.3. Opisy ról zespołu zarządzanie projektem

5.7.5.1.4. Struktura zespołu zarządzania projektem

5.7.5.2. Role

5.7.5.2.1. Komitet Sterujący (KS)

5.7.5.2.2. Kierownik Projektu (KP)

5.8. 4. Manage by stages

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

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

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

5.8.3. Projekt posiada minimum dwa etapy zarządcze:

5.8.3.1. etap inicjowania

5.8.3.2. jeden lub więcej etapów realizacji

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

5.8.5. Pryncypium wspierane przez:

5.8.5.1. Produkty Zarządcze

5.8.5.1.1. Plan Etapu (A.16)

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

5.8.5.2. Role

5.8.5.2.1. Komitet Sterujący (KS)

5.8.5.2.2. Kierownik Projektu (KP)

5.9. 5. Manage by exception

5.9.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.9.2. Zdefiniowane, jasno określone i zatwierdzone obowiązki dla każdego szczebla zarządzania.

5.9.3. Pryncypium wspierane przez:

5.9.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.9.3.1.1. Parametry tolerancji wg. PRINCE2®:

5.9.3.2. Produkty Zarządcze

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

5.9.3.2.2. Plan Projektu (A.16)

5.9.3.2.3. Plan Etapu (A.16)

5.9.3.2.4. Grupa Zadań (A.26)

5.9.3.2.5. Uzasadnienie Biznesowe (A.2)

5.9.3.2.6. Opis Produktu (A.17)

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

5.9.3.3. Role

5.9.3.3.1. Komitet Sterujący (KS)

5.9.3.3.2. Kierownik Projektu (KP)

5.10. 6. Focus on products

5.10.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.10.2. Pryncypium wspierane przez:

5.10.2.1. Produkty Zarządcze

5.10.2.1.1. Opis Produktu (A.17)

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

5.10.2.2. Role

5.10.2.2.1. Komitet Sterujący (KS)

5.10.2.2.2. Kierownik Projektu (KP)

5.10.2.2.3. Kierownik Zespołu (KZ)

5.11. 7. Tailoring

5.11.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.11.2. Należy indywidualnie dostosować metodykę PRINCE2® do kazdego projektu.

5.11.2.1. Żaden projekt nie jest taki sam.

5.11.2.2. Usatalenie jak metoda zarządzania projektami w organizacji będzie dostosowana do projektu.

5.11.3. Pryncypium wspierane przez:

5.11.3.1. Produkty Zarządcze

5.11.3.1.1. Dokumentacja Inicjowanie Projektu (A.20)

5.11.3.2. Role

5.11.3.2.1. Komitet Sterujący (KS)

5.11.3.2.2. Kierownik Projektu (KP)

6. How PRINCE2® defines project

6.1. Interpreting project definition

6.1.1. "A project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case (A.2)"

6.1.1.1. temporary organization means ...

6.1.1.1.1. Establish only for project needs and can have people having different roles than those which they have been employed in the company

6.1.1.2. delivering means ...

6.1.1.2.1. Buying ready product, producing / developing from the ground up, expanding/improving of the current, existing product, etc.

6.1.1.3. one or more business products means ...

6.1.1.3.1. At least one, so the project will have any sense :)

6.1.1.3.2. Many of the same type, or more completely different

6.1.1.4. products means ...

6.1.1.4.1. Specialist products are those products whose development is the subject of the plan.

6.1.1.5. business means ...

6.1.1.5.1. Those that are needed for organizations and end users

6.1.1.5.2. Those that are aligned with the mission, vision and objectives of the organization

6.1.1.5.3. Those that will bring business benefits for the client / end user organization

6.1.1.6. Business Case (A.2) means ...

6.1.1.6.1. Described in the management product (for simplicity documentation) called the Business Case

6.2. 5 factors that differentiate Projects from Business As Usual (BAU)

6.2.1. "Business as usual refers to the day-to-day business operations that an organization carries out."

6.2.1.1. Project is finite.

6.2.1.1.1. In contrast, business operations exist as long as the organization exists.

6.2.1.2. We can say that business operations are permanent.

6.2.2. Change

6.2.2.1. The project aims to implement changes to the organisation.

6.2.2.2. Changes in the business as Usual (BAU) in the form of a new products delivered by the project and with those new products there will be changes in the organization (e.g. new processes, training to the end users, etc.).

6.2.3. Temporary

6.2.3.1. The project has a finite beginning and end of what distinguishes it from what every day dealing with the client organization.

6.2.3.1.1. Once the project begins and comes to an end

6.2.3.2. Similarly each project phase has it's starting and ending date (with agreed tolerances).

6.2.4. Cross-Functional

6.2.4.1. Customers and suppliers have various perspectives and motivations.

6.2.4.2. Project involves people with different expectations and attitudes to the project

6.2.4.2.1. Supplier

6.2.4.2.2. Klient

6.2.4.3. Bringing together of a temporary team with different skills working together to introduce a change that will impact others outside of the team.

6.2.5. Unique

6.2.5.1. The project is implemented in a unique environment/context

6.2.5.1.1. Among other things, the uniqueness is also another period of time in which the project is conducted (different place in time, different laws and regulations, etc.)

6.2.5.2. The work we do may be similar to things done in the past however a project will be unique in some way: a different team, a different customer, a different location.

6.2.5.3. Each project is unique and must be considered individually in the context of all six project effectiveness project variables.

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

6.2.5.3.2. Each project is unique also means that the PRINCE2® methodology is not suitable for all types of projects (which is completely natural for each methodology).

6.2.5.3.3. In cases where it is certain that the requirements of the project will change over the project or when you do not know all the requirements at the start of the project and yet we have to start agile project approach may seem more appropriate.

6.2.6. Uncertainty

6.2.6.1. Project involves a higher risk level than regular business operations

6.2.6.1.1. Projects introduce threats and opportunities over and above those we would typically encounter

6.2.6.2. Each project is uncertain venture can be successful or a failure to enhance the chance of successful completion of the project we need to manage uncertainty in the project, i.e. the risk

6.2.6.2.1. Thoughts: Otherwise we would have project automation instead of project management ...

6.3. 6 project performance variables (effectiveness aspects)

6.3.1. Variables / effectiveness of the project, as they may change during the course of the project, and we need to control them.

6.3.1.1. All of this variables have defined tolerances, because we cannot precisely define all of those variables, we can only simulate / calculate most probable cost, timescales, risk etc. of the project

6.3.2. Means areas to be monitored constantly throughout the duration of the project.

6.3.3. Costs

6.3.3.1. When you start a project, there may be a particular budget in mind. But there may be several factors that can lead to overspending. It is important to always keep the cost and budget in mind.

6.3.3.2. controlled using

6.3.3.2.1. project budget

6.3.3.2.2. risk budget

6.3.3.2.3. change budget

6.3.4. Timescales

6.3.4.1. A project always has a start and an end date. The Project Manager should try to adhere to these dates.

6.3.4.2. controlled using management products such as ...

6.3.4.2.1. Project Plan (A.16)

6.3.4.2.2. Stage Plan (A.16)

6.3.4.2.3. Exception Plan (A.16)

6.3.4.2.4. Work Package (A.26)

6.3.5. Quality

6.3.5.1. In addition to finishing the project on time and within budget, the Project Manager must also achieve the project goals as expected. In terms of PRINCE2®, the project’s products must be fit for purpose for which they are developed

6.3.5.2. controlled using management products such as ...

6.3.5.2.1. Quality Management Strategy (A.22)

6.3.5.2.2. Quality Registry (A.23)

6.3.5.2.3. Project Product Description (A.21)

6.3.5.2.4. Product Description (A.17)

6.3.6. Scope

6.3.6.1. The scope of the project should be clear to all the parties involved in order to avoid any confusion.

6.3.6.1.1. There must be an agreement on the project scope, and the Project Manager should know what is within or outside the scope. In addition, they should not deliver beyond the scope.

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

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

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

6.3.6.3. controlled using management products such as ...

6.3.6.3.1. Project Plan (A.16)

6.3.6.3.2. Stage Plan (A.16)

6.3.6.3.3. Work Package (A.26)

6.3.7. Risk

6.3.7.1. Each project involves some kind of risk. So, there should be a proper plan to manage such risks.

6.3.7.2. controlled using management products such as ...

6.3.7.2.1. Risk Management Strategy (A.24)

6.3.7.2.2. Risk Registry (A.25)

6.3.7.2.3. Work Package (A.26)

6.3.7.3. What is the risk profile of the project?

6.3.8. Benefits

6.3.8.1. The Project Manager should have a clear understanding of the purpose of the project as an investment and should ensure that the project delivery is consistent with achieving the desired return.

6.3.8.2. controlled using management products such as ...

6.3.8.2.1. Business Case (A.2)

6.3.8.2.2. Benefits Review Plan (A.1)

7. PRINCE2® structure

7.1. PRINCE2® method has 4 integrated elements

7.2. "Magic number 7"

7.2.1. 1. - 7 Principles

7.2.1.1. seven guiding rules / orders

7.2.2. 2. - 7 Themes

7.2.2.1. seven areas of project management knowledge

7.2.3. 3. - 7 Processes (types of processes)

7.2.3.1. seven groups of activities, describing what to do in the project life cycle

7.2.4. 4. Project Environment

7.2.4.1. PRINCE2® methodology adaptation to the environment of the project

7.2.4.2. This means min. the introduction of specific terminology / language

7.2.4.3. Adaptation of the documentation for the needs / requirements of the organization

7.2.4.4. Adaptation of the project in the context of the industry (eg. IT, engineering, etc.) - PRINCE2 methodology is fully general

7.3. What PRINCE2® does not provide?

7.3.1. Specialists aspects

7.3.2. Detailed techniques

7.3.2.1. PRINCE2 is purely general in nature, not industry/domain specific

7.3.2.2. PRINCE2® doesn't cover every aspect of project management.

7.3.2.3. PRINCE2® doesn't specify the use of specific techniques.

7.3.2.3.1. Only techniques that have a specific PRINCE2® approach are described such as product based planning and the quality review technique.

7.3.2.3.2. For detailed project management techniques (see PMBOK Guide)

7.3.3. Leadership capability

7.3.3.1. Even though it is very important that we have leadership on our project and we are motivating the team, how we do that is not addressed in PRINCE2®.

7.3.3.2. Leadership capability, how you lead and motivate your team will vary depending upon circumstance.

7.3.4. Soft-skills

7.3.5. Communication techniques

7.3.6. Human resource management

7.3.7. Contract negotiations

7.3.8. Software for project management

7.3.9. …

8. PRINCE2® Management products (26)

8.1. Baseline

8.1.1. a.k.a. "PRINCE2® base"

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

8.1.3. K.P. NIE może aktualizować tych dokumentów bez potrzeby zgody Komitetu Starującego

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

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

8.1.4.1. Rekomendowana zawartość

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

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

8.1.4.1.3. Sposoby i terminy pomiaru oczekiwanych korzyści.

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

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

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

8.1.5. A.2 Uzasadnienie Biznesowe

8.1.5.1. Rekomendowana zawartość

8.1.5.1.1. Podsumowanie

8.1.5.1.2. Powody podjęcia projektu

8.1.5.1.3. Możliwe rozwiązania biznesowe

8.1.5.1.4. Oczekiwane korzyści

8.1.5.1.5. Przewidywane niepożądane skutki

8.1.5.1.6. Terminy

8.1.5.1.7. Koszty

8.1.5.1.8. Ocena inwestycji

8.1.5.1.9. Główne ryzyka

8.1.6. A.4 Strategia Zarządzania Komunikacją

8.1.6.1. Rekomendowana zawartość

8.1.6.1.1. Wprowadzenie

8.1.6.1.2. Procedura komunikacji

8.1.6.1.3. Narzędzia i techniki

8.1.6.1.4. Wymagane zapisy

8.1.6.1.5. Raportowanie

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

8.1.6.1.7. Role i ich obowiązki

8.1.6.1.8. Analiza interesariuszy

8.1.6.1.9. Potrzeby informacyjne każdej z zainteresowanych stron

8.1.7. A.6 Strategia Zarządzania Konfiguracją

8.1.7.1. Rekomendowana zawartość

8.1.7.1.1. Wprowadzenie

8.1.7.1.2. Procedura zarządzania konfiguracją

8.1.7.1.3. Procedura obsługi zagadnień i sterowania zmianami

8.1.7.1.4. Narzędzia i techniki

8.1.7.1.5. Wymagane zapisy

8.1.7.1.6. Raportowanie

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

8.1.7.1.8. Role i ich obowiązki

8.1.7.1.9. Skala ocen priorytetu i wagi

8.1.8. A.16 Plan

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

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

8.1.8.1.2. poziom projektu i etapu zarazem

8.1.8.1.3. 3. poziom dostarczania produktów specjalistycznych

8.1.8.2. Rekomendowana zawartość

8.1.8.2.1. Opis planu

8.1.8.2.2. Warunki wstępne dla planu

8.1.8.2.3. Zależności zewnętrzne

8.1.8.2.4. Założenia planistyczne

8.1.8.2.5. Uwzględnione doświadczenia

8.1.8.2.6. Monitorowanie i kontrola

8.1.8.2.7. Budżety

8.1.8.2.8. Tolerancje

8.1.8.2.9. Opisy produktów (A.17)

8.1.8.2.10. Harmonogram

8.1.9. A.17 Opis Produktu

8.1.9.1. Rekomendowana zawartość

8.1.9.1.1. Identyfikator

8.1.9.1.2. Nazwa

8.1.9.1.3. Przeznaczenie

8.1.9.1.4. Zawartość/Skład

8.1.9.1.5. Pochodzenie

8.1.9.1.6. Wymagany format i sposób przedstawienia

8.1.9.1.7. Wymagane umiejętności wytwórcy

8.1.9.1.8. Kryteria jakości

8.1.9.1.9. Tolerancja jakości

8.1.9.1.10. Metoda kontroli jakości

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

8.1.9.1.12. Obowiązki dotyczące jakości

8.1.10. A.19 Założenia Projektu

8.1.10.1. Rekomendowana zawartość

8.1.10.1.1. Definicja projektu

8.1.10.1.2. Zarys Uzasadnienia Biznesowego

8.1.10.1.3. Opis Produktu Końcowego Projektu

8.1.10.1.4. Formuła realizacji projektu

8.1.10.1.5. Struktura zespołu zarządzania projektem

8.1.10.1.6. Opisy ról

8.1.10.1.7. Odniesienia

8.1.11. A.20 Dokumentacja Inicjowania Projektu (DIP)

8.1.11.1. Rekomendowana zawartość

8.1.11.1.1. Definicja projektu

8.1.11.1.2. Formuła realizacji projektu

8.1.11.1.3. Uzasadnienie Biznesowe

8.1.11.1.4. Struktura zespołu zarządzania projektem

8.1.11.1.5. Opisy ról

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

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

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

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

8.1.11.1.10. Plan Projektu (A.16)

8.1.11.1.11. Mechanizmy sterowania

8.1.11.1.12. Dostosowanie metodyki PRINCE2

8.1.12. A.21 Opis Produktu Końcowego Projektu

8.1.12.1. Rekomendowana zawartość

8.1.12.1.1. Nazwa

8.1.12.1.2. Przeznaczenie

8.1.12.1.3. Zawartość/skład

8.1.12.1.4. Pochodzenie

8.1.12.1.5. Wymagane umiejętności wytwórcy

8.1.12.1.6. Oczekiwania jakościowe klienta

8.1.12.1.7. Kryteria akceptacji

8.1.12.1.8. Tolerancje projektu

8.1.12.1.9. Metoda akceptacji

8.1.12.1.10. Obowiązki dotyczące akceptacji

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

8.1.13.1. Rekomendowana zawartość

8.1.13.1.1. Wprowadzenie

8.1.13.1.2. Procedura zarządzania jakością

8.1.13.1.3. Narzędzia i techniki

8.1.13.1.4. Wymagane zapisy

8.1.13.1.5. Raportowanie

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

8.1.13.1.7. Role i obowiązki

8.1.14. A.24 Strategia Zarządzania Ryzykiem

8.1.14.1. Rekomendowana zawartość

8.1.14.1.1. Wprowadzenie

8.1.14.1.2. Procedura zarządzania ryzykiem

8.1.14.1.3. Narzędzia i techniki

8.1.14.1.4. Wymagane zapisy

8.1.14.1.5. Raportowanie

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

8.1.14.1.7. Role i obowiązki

8.1.14.1.8. Skale ocen

8.1.14.1.9. Bliskość

8.1.14.1.10. Kategorie ryzyka

8.1.14.1.11. Kategorie reakcji na ryzyko

8.1.14.1.12. Wskaźniki wczesnego ostrzegania

8.1.14.1.13. Tolerancja ryzyka

8.1.14.1.14. Budżet ryzyka

8.1.15. A.26 Grupa Zadań

8.1.15.1. Rekomendowana zawartość

8.1.15.1.1. Data

8.1.15.1.2. Kierownik Zespołu lub osoba upoważniona

8.1.15.1.3. Opis Grupy Zadań

8.1.15.1.4. Techniki, procesy i procedury

8.1.15.1.5. Punkty styku (interfejsy) w okresie wytwarzania

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

8.1.15.1.7. Wymagania zarządzania konfiguracją

8.1.15.1.8. Uzgodnienia

8.1.15.1.9. Tolerancje

8.1.15.1.10. Ograniczenia

8.1.15.1.11. Uzgodnienia dotyczące raportowania

8.1.15.1.12. Sposoby obsługi i przekazywania problemów

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

8.1.15.1.14. Metoda zatwierdzenia (odbioru) wykonanej Grupy Zadań

8.2. Records

8.2.1. a.k.a. "PRINCE2® dynamic"

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

8.2.3. K.P. może aktualizować te dokumenty bez potrzeby zgody Komitetu Starującego

8.2.4. A.5 Zapisy Obiektu Konfiguracji

8.2.4.1. Rekomendowana zawartość

8.2.4.1.1. Identyfikator projektu

8.2.4.1.2. Identyfikator obiektu

8.2.4.1.3. Aktualna wersja

8.2.4.1.4. Nazwa obiektu

8.2.4.1.5. Data ostatniej zmiany statusu

8.2.4.1.6. Docelowy właściciel produktu

8.2.4.1.7. Miejsce przechowywania

8.2.4.1.8. Aktualni posiadacze

8.2.4.1.9. Rodzaj obiektu

8.2.4.1.10. Cechy obiektu

8.2.4.1.11. Etap

8.2.4.1.12. Użytkownicy

8.2.4.1.13. Status

8.2.4.1.14. Stadium produktu

8.2.4.1.15. Wariant

8.2.4.1.16. Wytwórca/producent

8.2.4.1.17. Data przydzielenia wytwórcy

8.2.4.1.18. Pochodzenie produktu

8.2.4.1.19. Związek z innymi produktami

8.2.4.1.20. Powiązania

8.2.5. A.7 Dziennik Projektu

8.2.5.1. Rekomendowana zawartość

8.2.5.1.1. Data wpisu.

8.2.5.1.2. Problem, działanie, zdarzenie lub komentarz

8.2.5.1.3. Osoba odpowiedzialna

8.2.5.1.4. Wyznaczony termin

8.2.5.1.5. Rezultaty

8.2.6. A.12 Rejestr Zagadnień

8.2.6.1. Rekomendowana zawartość

8.2.6.1.1. Identyfikator zagadnienia

8.2.6.1.2. Typ zagadnienia

8.2.6.1.3. Data zgłoszenia

8.2.6.1.4. Zgłoszone przez

8.2.6.1.5. Autor Raportu o Zagadnieniu

8.2.6.1.6. Opis zagadnienia

8.2.6.1.7. Priorytet

8.2.6.1.8. Waga/znaczenie

8.2.6.1.9. Status

8.2.6.1.10. Data zamknięcia

8.2.7. A.14 Dziennik Doświadczeń

8.2.7.1. Rekomendowana zawartość

8.2.7.1.1. Typ doświadczenia

8.2.7.1.2. Opis doświadczenia

8.2.7.1.3. Data wpisu

8.2.7.1.4. Wpisane przez

8.2.7.1.5. Priorytet

8.2.8. A.23 Rejestr Jakości

8.2.8.1. Rekomendowana zawartość

8.2.8.1.1. Numer wpisu

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

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

8.2.8.1.4. Metoda

8.2.8.1.5. Role i obowiązki

8.2.8.1.6. Terminy

8.2.8.1.7. Wynik

8.2.8.1.8. Zapisy jakości

8.2.9. A.25 Rejestr Ryzyk

8.2.9.1. Rekomendowana zawartość

8.2.9.1.1. Identyfikator ryzyka

8.2.9.1.2. Autor zgłoszenia

8.2.9.1.3. Data zarejestrowania

8.2.9.1.4. Kategoria ryzyka

8.2.9.1.5. Opis ryzyka

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

8.2.9.1.7. Bliskość ryzyka

8.2.9.1.8. Kategorie reakcji na ryzyko

8.2.9.1.9. Proponowane reakcje na ryzyko

8.2.9.1.10. Status ryzyka

8.2.9.1.11. Właściciel ryzyka

8.2.9.1.12. Wykonawca reakcji na ryzyko

8.3. Reports

8.3.1. a.k.a. "PRINCE2® static"

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

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

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

8.3.4. A.3 Raport z Punktu Kontrolnego

8.3.4.1. Rekomendowana zawartość

8.3.4.1.1. Data opracowania

8.3.4.1.2. Okres sprawozdawczy

8.3.4.1.3. Wykonanie wcześniej zleconych czynności

8.3.4.1.4. Bieżący okres sprawozdawczy

8.3.4.1.5. Następny okres sprawozdawczy

8.3.4.1.6. Stan tolerancji Grupy Zadań

8.3.4.1.7. Zagadnienia i ryzyka

8.3.5. A.8 Raport Końcowy Projektu

8.3.5.1. Rekomendowana zawartość

8.3.5.1.1. Sprawozdanie Kierownika Projektu

8.3.5.1.2. Przegląd Uzasadnienia Biznesowego

8.3.5.1.3. Przegląd realizacji celów projektu

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

8.3.5.1.5. Przegląd produktów

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

8.3.6. A.9 Raport Końcowy Etapu

8.3.6.1. Rekomendowana zawartość

8.3.6.1.1. Sprawozdanie Kierownika Projektu

8.3.6.1.2. Przegląd Uzasadnienia Biznesowego

8.3.6.1.3. Przegląd realizacji celów projektu

8.3.6.1.4. Przegląd realizacji celów etapu

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

8.3.6.1.6. Przegląd produktów

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

8.3.6.1.8. Zagadnienia i ryzyka

8.3.6.1.9. Prognoza

8.3.7. A.10 Raport Nadzywczajny

8.3.7.1. Rekomendowana zawartość

8.3.7.1.1. Opis sytuacji nadzwyczajnej

8.3.7.1.2. Przyczyna wystąpienia

8.3.7.1.3. Skutki odchylenia

8.3.7.1.4. Możliwe reakcje

8.3.7.1.5. Rekomendacja

8.3.7.1.6. Doświadczenia

8.3.8. A.11 Raport Okresowy

8.3.8.1. Rekomendowana zawartość

8.3.8.1.1. Data opracowania

8.3.8.1.2. Okres sprawozdawczy

8.3.8.1.3. Sumaryczny opis stanu etapu

8.3.8.1.4. Bieżący okres sprawozdawczy

8.3.8.1.5. Następny okres sprawozdawczy

8.3.8.1.6. Stan tolerancji projektu i etapu

8.3.8.1.7. Wnioski o wprowadzenie zmiany

8.3.8.1.8. Główne zagadnienia i ryzyka

8.3.8.1.9. Raport Doświadczeń

8.3.9. A.13 Raport o Zagadnieniu

8.3.9.1. Rekomendowana zawartość

8.3.9.1.1. Identyfikator zagadnienia

8.3.9.1.2. Typ zagadnienia

8.3.9.1.3. Data zgłoszenia

8.3.9.1.4. Zgłoszone przez

8.3.9.1.5. Autor Raportu o Zagadnieniu

8.3.9.1.6. Opis zagadnienia

8.3.9.1.7. Analiza wpływu

8.3.9.1.8. Rekomendacja

8.3.9.1.9. Priorytet

8.3.9.2. Egzamin Foundation

8.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.

8.3.10. A.15 Raport Doświadczeń

8.3.10.1. Rekomendowana zawartość

8.3.10.1.1. Podsumowanie

8.3.10.1.2. Zakres raportu (np. etap lub projekt)

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

8.3.10.1.4. Przegląd użytecznych miar

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

8.3.10.2. Egzamin Foundation

8.3.10.2.1. Raport Doświadczeń NIE Doświadczenia

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

8.3.11.1. Rekomendowana zawartość

8.3.11.1.1. Zakres raportu

8.3.11.1.2. Data wytworzenia

8.3.11.1.3. Status produktów

8.3.11.2. Egzamin Foundation

8.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ę).

8.4. Praktyka

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

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

9. PRINCE2® - process based standard and sequential/cascading project management methodology (not a recommendation, not a good practice, not guidelines, not technique, not framework) to the general (not related to a specific industry, such as: IT or construction) sequential (non iterative and adaptive) project management. PRINCE2® methodology is one of the 12 recognized globally and practically proven management standards from AXELOS® Global Best Practice family of UK standards.

9.1. 1989

9.1.1. Release of PRINCE, to supersede PROMPTII, focusing on guidance for IT project management

9.2. PRINCE2® v1 was published in 16.06.1996.

9.2.1. Release of first edition of PRINCE2

9.3. PRINCE2® v2 was published 1998.

9.4. PRINCE2® v3 was published in 2002.

9.5. PRINCE2® v4 was published in 2005.

9.6. PRINCE2® v5 was published in 2009.

9.6.1. In June 2009 most significant update to date was published.

9.7. PRINCE2® v6 was published in 2017.

9.8. How PRINCE2® fits into AXELOS® Global Best Practices family of UK standards.

9.8.1. PRINCE2® in AXELOS® Global Best Practices family

9.9. AXELOS® Global Best Practices family of standards from UK.

9.9.1. PRINCE2® Agile

9.9.1.1. see PRINCE2® Agile mind map

9.9.2. ITIL®

9.9.2.1. see ITIL® mindmap

9.9.3. M_o_R® - Management of Risk

9.9.3.1. see M_o_R® mindmap

9.9.4. MoV® - Management of Value

9.9.4.1. see MoV® mindmap

9.9.5. MoP® - Management of Portfolios

9.9.5.1. see MoP® mindmap

9.9.6. MSP® - Managing Successful Programmes

9.9.6.1. see MSP® mindmap

9.9.7. P3O® - Portfolio, Programme and Project Office

9.9.7.1. see P3O® mindmap

9.9.8. yet remember - "In reality there are no such things as best practices. There are only practices that are good within a certain context."

9.10. Since 2000 the Office of Government Commerce (OGC), former owner of PRINCE2® (and other Best Management Practices) has been the custodian of the portfolio on behalf of UKG. In June 2010 as a result of UKG reorganisation the Minister for the Cabinet Office announced that the PRINCE2® functions have moved into Cabinet Office.

9.10.1. AXELOS are a new joint venture company, created by the Cabinet Office on behalf of Her Majesty’s Government (HMG) in the United Kingdom and Capita plc to run the Best Management Practice portfolio, now called AXELOS Global Best Practice

9.10.2. https://www.gov.uk/government/publications/best-management-practice-portfolio/about-the-office-of-government-commerce

10. PRINCE2® consists of: 7 Principles, 7 Themes, 7 Processes, 40 Sub-processes, 10 Project Roles, 4 Quality Assurance Roles, 3 Issue Types, 2 Techniques, 2 Procedures, 3 Budget Types, 5 Project Factors, 6 Project Performance Factors (effectiveness aspects), 26 Management Products (divided on 3 types)

10.1. Download: PRINCE2® Matrix Processes vs Management Products vs Roles vs Responsibilities (PDF)

10.2. Download: PRINCE2® Process Model (PDF)

11. PRINCE2® Official publications

11.1. PRINCE2® Skuteczne Zarządzanie Projektami

11.1.1. ISBN-13: 978-0113312245

11.1.2. 365 stron

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

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

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

11.1.4.2. Niezbędna pozycja podczas egzaminu Practitioner

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

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

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

11.2. Directing Successful Projects with PRINCE2®

11.2.1. ISBN-13: 978-0113310609

11.2.2. 166 stron

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

11.3. Passing your PRINCE2 Examinations 2009 Edition

11.3.1. ISBN-13: 978-0113311903

11.3.2. 172 stron

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

11.4. PRINCE2® Maturity Model (P2MM)

11.4.1. 34 strony

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

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

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

11.5.1. 22 strony

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

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

12. Interactive PRINCE2® Glossary

12.1. Interactive PRINCE2® Glossary

13. This freeware, non-commercial mind map (aligned with the newest version of PRINCE2®) was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the PRINCE2® method and as a learning tool for candidates wanting to gain PRINCE2® qualification. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)

13.1. Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Feel free to visit my website: www.miroslawdabrowski.com

13.1.1. http://www.miroslawdabrowski.com

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

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

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

13.1.5. https://twitter.com/mirodabrowski

13.1.6. miroslaw_dabrowski

14. PRINCE2® Techniques (2)

14.1. Product-based planning technique

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

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

14.1.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.

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

14.1.4.1. 1. Opis Produktu Końcowego Projektu,

14.1.4.2. 2. Diagram struktury produktów,

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

14.1.4.4. 4. Diagram następstwa produktów.

14.2. Quality review technique

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

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

14.2.1.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.

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

14.2.2.1. chair

14.2.2.1.1. responsible for the overall conduct of the quality review

14.2.2.2. presenter

14.2.2.2.1. represents the producer and introduces the product, coordinates the quality review follow-up actions

14.2.2.3. controller / reviewer

14.2.2.3.1. verifies the compliance of the product with the Description, prepares a list of questions

14.2.2.4. administrator

14.2.2.4.1. provides administrative support for the Chair

14.2.2.5. The remaining roles may be combined as needed

14.2.2.5.1. Najmniejsza forma to 2 osoby

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

14.2.3.1. 1. Quality review preparation

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

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

14.2.3.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,

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

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

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

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

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

14.2.3.2. 2. Quality review meeting

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

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

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

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

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

14.2.3.2.6. 6. zaktualizowania Rejestru Jakości.

14.2.3.3. 3. Follow-up actions after the meeting

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

14.2.3.3.2. 2. zaplanowania wszelkich potrzebnych prac naprawczych,

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

14.2.3.3.4. 4. zaktualizowania Rejestru Jakości.

15. PRINCE2® Procedures (2)

15.1. Issue and change control procedure

15.1.1. 5 steps working sequentially

15.1.1.1. 1. Capture

15.1.1.2. 2. Examine

15.1.1.3. 3. Propose

15.1.1.4. 4. Decide

15.1.1.5. 5. Implement

15.2. Configuration management procedure

15.2.1. 5 steps working sequentially

15.2.1.1. 1. Planning

15.2.1.2. 2. Identification

15.2.1.3. 3. Control

15.2.1.4. 4. Status accounting

15.2.1.5. 5. Verification and audit (configuration)

16. PRINCE2® Official resources

16.1. PRINCE2® sample exams available online

16.1.1. Foundation

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

16.1.2. Practitioner

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

16.2. PRINCE2® syllabus

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

16.3. Glosariusz PRINCE2®

16.3.1. EN

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

16.3.2. PL

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

16.4. PRINCE2® management products templates

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

16.5. PRINCE2® official website

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

17. PRINCE2® Foundation exam prep questions

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

18. Quality Review Roles (4)

18.1. chair

18.1.1. responsible for the overall conduct of the quality review

18.2. presenter

18.2.1. represents the producer and introduces the product, coordinates the quality review follow-up actions

18.3. controller / reviewer

18.3.1. verifies the compliance of the product with the Description, prepares a list of questions

18.4. administrator

18.4.1. provides administrative support for the Chair

19. PRINCE2® Foundation courseware