PRINCE2® (PL) - Skuteczne Zarządzanie Projektami
Kontakt: http://www.linkedin.com/in/miroslawdabrowski
1. Oprogramowanie do zarządzania projektami
1.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)!
1.2. Oprogramowanie do zarządzania projektami zgodne z PRINCE2®
1.2.1. The Principal Toolbox
1.2.1.1. http://www.fortesglobal.com/en/solutions
1.2.2. P2ware
1.2.2.1. http://p2ware.com/pl
1.2.3. PPM Studio
1.2.3.1. http://www.ppmstudio.com/
1.2.4. MicroP2
1.2.4.1. http://www.novareconsulting.com/MicroP2/MicroP2.aspx
1.2.5. in-Step PRINCE2
1.2.5.1. http://www.microtool.de/instep/en/download_go.asp?url=2
1.2.6. PROJECT in a Box
1.2.6.1. http://www.projectinabox.org.uk/
1.2.7. P2_PC
1.2.7.1. http://www.projectcommander.co.uk/prince2/home.HTML
1.2.8. UWAGA - Zgodność oprogramowania z PRINCE2® nie czyni narzędzia "najlepszym w klasie", oprogramowanie to jedynie (i aż zarazem) narzędzie wspierające.
1.3. Oprogramowanie do zarządzania projektami "klasy Enterprise"
1.3.1. CA Technologies
1.3.1.1. CA Clarity™ PPM
1.3.1.1.1. http://www.ca.com/us/products/detail/ca-clarity-ppm.aspx
1.3.1.1.2. Najbardziej zaawanoswane narzędzie w klasie PPM.
1.3.1.1.3. Wielokrotny laureat nagród dla narzędzi PPM.
1.3.2. Compuware Corporation
1.3.2.1. Changepoint
1.3.2.1.1. http://www.compuware.com/
1.3.3. Innotas
1.3.3.1. Innotas PPM
1.3.3.1.1. http://www.innotas.com/
1.3.4. PlainView
1.3.4.1. PlainView PPM
1.3.4.1.1. http://www.planview.com/
1.3.5. HP
1.3.5.1. PPM Center
1.3.5.1.1. http://www8.hp.com/us/en/software-solutions/software.html?compURI=1171920#.Uz2J6Pl_t8F
1.3.6. EOS Software
1.3.6.1. EOS ITPM
1.3.6.1.1. http://www.eossoftware.com/
1.3.7. BMC Software
1.3.7.1. IT Business Management Suite
1.3.8. Upland Software Inc.
1.3.8.1. PowerSteering
1.3.8.1.1. http://www.uplandsoftware.com/products-overview/powersteering/
1.3.9. UMT
1.3.9.1. UMT360
1.3.9.1.1. http://www.umt360.com/
1.3.10. Clarizen
1.3.10.1. Clarizen
1.3.10.1.1. http://www.clarizen.com/
1.3.11. AtTask
1.3.11.1. AtTask
1.3.11.1.1. http://www.attask.com/
1.3.12. Daptiv
1.3.12.1. Daptiv PPM
1.3.12.1.1. http://www.daptiv.com/
1.3.13. Genius Inside
1.3.13.1. Genius Project
1.3.13.1.1. http://www.geniusproject.com/
1.3.14. Metafuse
1.3.14.1. Project Insight
1.3.14.1.1. http://www.projectinsight.net/
1.3.15. KeyedIn
1.3.15.1. KeyedIn Projects
1.3.15.1.1. http://www.keyedin.com/
1.3.16. Zilicus
1.3.16.1. ZilicusPM
1.3.16.1.1. http://zilicus.com/
1.4. Oprogramowanie do zarządzania projektami "klasy Business"
1.4.1. LiquidPlanner
1.4.1.1. LiquidPlanner
1.4.1.1.1. http://www.liquidplanner.com/
1.4.2. Upland Software Inc.
1.4.2.1. Tenrox
1.4.2.1.1. http://www.tenrox.com/
1.4.3. Upland Software Inc.
1.4.3.1. EPM Live
1.4.3.1.1. http://www.epmlive.com/
1.4.4. Celoxis Technologies Pvt. Ltd.
1.4.4.1. Celoxis
1.4.4.1.1. http://www.celoxis.com/
1.4.5. Project Manager Online Ltd
1.4.5.1. Project Manager
1.4.5.1.1. http://www.projectmanager.com/
1.5. Oprogramowanie darmowe
1.5.1. Talaia Open PPM
1.5.1.1. http://www.talaia-openppm.com/
1.5.2. PROJECT in a Box (wersja Community)
1.5.2.1. http://www.projectinabox.org.uk/
2. Zasoby zewnętrzne firm trzecich
2.1. Szablony dokumentów PRINCE2® firm trzecich
2.1.1. P2 Toolkit
2.1.1.1. http://prince2.privacyresources.org/
2.1.2. Management Plaza
2.1.2.1. http://mgmtplaza.com/product/a-sample-prince2-project/
2.1.3. Project In a Box
2.1.3.1. http://www.projectinabox.org.uk/prince2_templates.asp
2.1.4. ILX Group
2.1.4.1. http://www.prince2.com/downloads
2.1.5. Silicon Beach Training
2.1.5.1. http://www.siliconbeachtraining.co.uk/blog/download-prince2-2009-project-templates
2.1.6. Corepm
2.1.6.1. http://www.prince2tool.com/
2.1.7. Cupe
2.1.7.1. http://www.cupe.co.uk/templates.html
2.2. Mapy PDF PRINCE2®
2.2.1. ILX
2.2.1.1. http://www.tel.uva.es/personales/proy/pmodel.pdf
2.2.1.2. http://www.prince2.com/downloads
2.2.2. http://tannerjames.businesscatalyst.com/free_resources/Prince2_Process_Model.pdf
2.2.3. http://www.slideshare.net/frankturley/p2-m-productmap
2.2.4. http://www.knowledgetrain.co.uk/images/kt/PRINCE2_Wallchart_v1.04.pdf
3. 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.
3.1. PRINCE2® v1 został opublikowany w 1996 roku.
3.2. PRINCE2® v2 został opublikowany w 2002 roku.
3.3. PRINCE2® v3 został opublikowany w 2005 roku.
3.4. PRINCE2® v4 został opublikowany w 2009 roku.
3.4.1. Znacząca aktualizacja
3.5. Jak PRINCE2® łączy się z innymi standarami z "rodziny" brytyjskich standardów zarządzania AXELOS® Global Best Practice
3.6. Rodzina brytyjskich standardów zarządzania AXELOS® Global Best Practice
3.6.1. ITIL®
3.6.1.1. see ITIL® mindmap
3.6.2. M_o_R® - Management of Risk
3.6.2.1. see M_o_R® mindmap
3.6.3. MoV® - Management of Value
3.6.3.1. see MoV® mindmap
3.6.4. MoP® - Management of Portfolios
3.6.4.1. see MoP® mindmap
3.6.5. MSP® - Managing Successful Programmes
3.6.5.1. see MSP® mindmap
3.6.6. P3O® - Portfolio, Programme and Project Office
3.6.6.1. see P3O® mindmap
3.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.
3.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.
3.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).
3.8.1. Prototypem dla metodyki PRINCE2® była metodyka PRINCE®.
4. 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)
4.1. Pobierz: PRINCE2® Macierz Procesy vs Produkty Zarządczy vs Role vs Odpowiedzialności (PDF)
4.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
4.2. Pobierz: Model Procesów PRINCE2® (PDF)
4.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
5. Oficjalne publikacje PRINCE2®
5.1. PRINCE2® Skuteczne Zarządzanie Projektami
5.1.1. ISBN-13: 978-0113312245
5.1.2. 365 stron
5.1.3. http://www.amazon.com/PRINCE2-Skuteczne-Zarzadzanie-Projektami-Edition/dp/0113312245
5.1.4. Najważniejsza, kluczowa pozycja dotycząca PRINCE2® przygotowująca do egzaminów Foundation, Practitioner oraz Professional.
5.1.4.1. Przydatna (ale nie niezbędna) pozycja podczas przygotowań (również samodzielnych) do egzaminu Foundation
5.1.4.2. Niezbędna pozycja podczas egzaminu Practitioner
5.1.4.3. Podczas egzaminu Practitioner można jedynie korzystać z tego podręcznika
5.1.4.3.1. Organizacja szkoleniowa w przypadku braku własnego podręcznika przez kandydata powinna udostępnić podręcznik na czas egzaminu
5.1.5. Jedyna oficjalna pozycja na temat PRINCE2® dostępna w języku PL.
5.2. Directing Successful Projects with PRINCE2®
5.2.1. ISBN-13: 978-0113310609
5.2.2. 166 stron
5.2.3. http://www.amazon.com/Directing-Successful-Projects-PRINCE2-Edition/dp/0113310609
5.3. Passing your PRINCE2 Examinations 2009 Edition
5.3.1. ISBN-13: 978-0113311903
5.3.2. 172 stron
5.3.3. http://www.amazon.com/Passing-your-PRINCE2-Examinations-Edition/dp/0113311907
5.4. PRINCE2® Maturity Model (P2MM)
5.4.1. 34 strony
5.4.2. http://www.p3m3-officialsite.com/nmsruntime/saveasdialog.aspx?lID=462&sID=210
5.4.3. Pozycja darmowa, oficjalna, dostępna online.
5.5. PRINCE2® Maturity Model (P2MM) - Self-Assessment
5.5.1. 22 strony
5.5.2. http://www.p3m3-officialsite.com/nmsruntime/saveasdialog.aspx?lID=469&sID=210
5.5.3. Pozycja darmowa, oficjalna, dostępna online.
6. 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.!)
6.1. Pytania / wątpliwość / błędy? Zapraszam do kontaktu. Mapa powstała jako pomoc w Twojej nauce. Każda uwaga jest cenna.
6.1.1. http://www.miroslawdabrowski.com
6.1.2. http://www.linkedin.com/in/miroslawdabrowski
6.1.3. https://www.google.com/+MiroslawDabrowski
6.1.4. https://play.spotify.com/user/miroslawdabrowski/
6.1.5. https://twitter.com/mirodabrowski
6.1.6. miroslaw_dabrowski
7. Oficjalne zasoby PRINCE2®
7.1. Przykładowe egzaminy PRINCE2®, dostępne online
7.1.1. Foundation
7.1.1.1. http://www.apmg-exams.com/index.aspx?subid=8
7.1.2. Practitioner
7.1.2.1. https://www.exin.com/assets/exin/exams/2050/samples/polish_sample_exam_fx02_pr2p_201311.pdf
7.1.2.2. http://www.apmg-exams.com/index.aspx?subid=9
7.2. Sylabus egzaminacyjny PRINCE2®
7.2.1. Sylabus opisuje zakres wiedzy wymaganej na poziomie egzaminów Foundation i Practitioner
7.2.2. http://www.prince-officialsite.com/nmsruntime/saveasdialog.aspx?lID=1731&sID=406
7.3. Glosariusz PRINCE2®
7.3.1. EN
7.3.1.1. http://www.prince-officialsite.com/nmsruntime/saveasdialog.aspx?lID=1486&sID=557
7.3.2. PL
7.3.2.1. http://www.prince-officialsite.com/nmsruntime/saveasdialog.aspx?lID=1515&sID=557
7.4. Szablony dokumentów PRINCE2®
7.4.1. http://www.prince-officialsite.com/nmsruntime/saveasdialog.aspx?lID=1493&sID=455
7.5. Strona PRINCE2®
7.5.1. http://www.prince-officialsite.com/
8. Pytania przygotowujące do egzaminu PRINCE2® Foundation
8.1. http://miroslawdabrowski.com/downloads/PRINCE2/Exam%20prep%20questions/
9. Role Projektowe (10)
9.1. Role projektowe są ściśle związane z tematem Organizacja
9.2. Struktura zespołu zarządzania projektem według PRINCE2®
9.3. Komitet Sterujący (KS) (3)
9.3.1. reprezentuje 3 strony interesów
9.3.1.1. strona klienta
9.3.1.1.1. Główny Użytkownik(-cy)
9.3.1.2. strona biznesu
9.3.1.2.1. Przewodniczący
9.3.1.3. strona dostawcy
9.3.1.3.1. Główny Dostawca(-cy)
9.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ą
9.3.2.1. to sytuacja typowo teoretyczna, nierealna w praktyce
9.3.3. Komitet Sterujący realizuje zarządzanie strategiczne projektem – co oznacza podejmowanie kluczowych decyzji i wyznaczanie kierunków działania.
9.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.
9.3.5. Komitet Sterujący to organ, który ostatecznie zatwierdza zakończenie każdego etapu i zezwala na rozpoczęcie etapu następnego.
9.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.
9.3.7. Zatwierdza nominacje i obowiązki Kierownika Projektu oraz delegowanie swoich obowiązków związanych z Nadzorem Projektu.
9.3.8. K. S. ponosi całościową odpowiedzialność za projekt zgodnie z instrukcjami organizacji/programu
9.3.8.1. odpowiedzialny za "sukces projektu"
9.3.9. Dla wtajemniczonych...
9.3.9.1. Komitet Sterujący odbierający kolejne raporty Kierownika Projektu
9.3.9.2. Komitet Starujący ustalający tolerancje projektu (budżet, terminy, etc.)
9.4. Nadzór Projektu (NP) (3)
9.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)
9.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.
9.4.2. Nadzór projektu nadzoruje zarazem Kierownika Projektu jak i Kierowników Zespołów
9.4.2.1. Dlatego musi być od nich niezależny, aby nie istniał konflikt interesów (nadzór samego siebie)
9.4.3. Wypełnianie obowiązków związanych z nadzorem wymaga odpowiedzi na pytanie: „Co ma być nadzorowane?”.
9.4.3.1. Lista możliwości mogłaby objąć zapewnienie, że:
9.4.3.1.1. w ciągu całego projektu utrzymywana jest ścisła łączność między Głównym Dostawcą / Wykonawcą a Klientem,
9.4.3.1.2. potrzeby i oczekiwania użytkownika są spełniane lub zarządzane,
9.4.3.1.3. zagrożenia są kontrolowane,
9.4.3.1.4. Uzasadnienie Biznesowe jest przestrzegane,
9.4.3.1.5. przyjmowane rozwiązania są stale oceniane z punktu widzenia dostarczania wartości, usprawiedliwiającej poniesione koszty,
9.4.3.1.6. projekt jest zgodny z Wizja, Misją i Strategią Organizacji,
9.4.3.1.7. właściwe osoby biorą udział w tworzeniu Opisów Produktów,
9.4.3.1.8. zaplanowano zaangażowanie właściwych osób do kontroli jakości we właściwych momentach wytwarzania produktu,
9.4.3.1.9. personel jest właściwie przeszkolony w zakresie procedur kontroli jakości,
9.4.3.1.10. właściwe osoby biorą udział w kontroli jakości,
9.4.3.1.11. procedury przeglądów / kontroli jakości są właściwie realizowane,
9.4.3.1.12. działania następcze, wynikające z kontroli jakości, prowadzone są prawidłowo,
9.4.3.1.13. realizowane rozwiązanie jest możliwe do zaakceptowania,
9.4.3.1.14. prowadzenie projektu jest nadal uzasadnione,
9.4.3.1.15. zakres projektu nie poszerza się niepostrzeżenie,
9.4.3.1.16. komunikacja wewnętrzna i zewnętrzna funkcjonuje zadowalająco,
9.4.3.1.17. używane standardy są właściwe i możliwe do zastosowania,
9.4.3.1.18. przestrzegane są wszystkie ograniczenia prawne,
9.4.3.1.19. spełniane są wymogi specjalistyczne (np. bezpieczeństwa),
9.4.3.1.20. przestrzega się standardów zapewnienia jakości.
9.4.3.1.21. ...
9.4.4. dzieli się na 3 obszary
9.4.4.1. Nadzór ze strony biznesu
9.4.4.1.1. jest to nadzór w imieniu Przewodniczącego
9.4.4.2. Nadzór ze strony dostawcy
9.4.4.2.1. jest to nadzór w imieniu Głównego Dostawcy
9.4.4.3. Nadzór ze strony użytkownika
9.4.4.3.1. jest to nadzór w imieniu Głównego Użytkownika
9.4.5. Rola wymagana
9.4.5.1. Pomimo delegowania czyności związanych z nadzorem projektu, odpowiedzialność za ich realizację pozostaje wciąż w ramach KS
9.5. Obsługa Zmian (OZ)
9.5.1. Rola decyzyjna w sprawie zagadnień typu - wniosek o wprowadzenie zmian.
9.5.2. OZ znajduje się nad KP w kwestii uprawnień o wprowadzenie zmian
9.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)
9.5.3. Rola wymagana
9.5.3.1. Pomimo delegowania czyności związanych z nadzorem projektu, odpowiedzialność za ich realizację pozostaje wciąż w ramach KS
9.5.3.2. W szczególnych przypadkach, KS może przekazać rolę OZ dla KP
9.5.4. Procesu obsługi zmian nie należy utożsamiać z rolą Obłsuga Zmian
9.5.4.1. Proces obsługi zmian w PRINCE2® może odbywać się na 4 poziomach:
9.5.4.1.1. Organizacja
9.5.4.1.2. KS
9.5.4.1.3. OZ
9.5.4.1.4. KP
9.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
9.6. Kierownik Projektu (KP)
9.6.1. Rola wymagana
9.6.2. Rola niepodzielna, zawsze 1 Kierownik Projektu
9.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
9.6.4. Kierownik Projektu nie może być łączony z Przewodniczącym Komitetu Sterującego oraz z Nadzorem Projektu
9.6.5. Codzienne planowanie oraz sterowanie realizacją bieżących zadań oraz podejmowanie decyzji w drobnych sprawach należy do Kierownika Projektu.
9.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.
9.6.5.2. Projektu. Kierownik Projektu odpowiada przed Przewodniczącym Komitetu Sterującego za terminowe i prawidłowe dostarczenie produktów projektu.
9.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.
9.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.
9.6.8. Odpowiedzialny za osiągnięcie CELÓW projektu (dostarczenie produktów specjalistycznych)
9.6.8.1. CELÓW nie SUKCESU projektu
9.6.9. Dla wtajemniczonych ...
9.6.9.1. (miś) Kierownik Projektu jest odpowiedzialny za ustalenie Strategi Zarządzania Komunikacją
9.6.9.1.1. https://www.youtube.com/watch?v=kdfq98BaMUU
9.6.9.1.2. (miś) "Wzajemna przyjaźń i zaufanie podstawą prawidłowego funkcjonowania podstawowej komórki społecznej rodziny"
9.6.9.2. (Co mi zrobisz jak mnie złapiesz) Kierownik Projektu dba, aby projekt trzymał się w ustalonych tolerancjach.
9.6.9.2.1. https://www.youtube.com/watch?v=Omo-JU08hXg
9.6.9.3. (miś) "Panowie pozwolą... mój projekt... PRINCE!"
9.6.9.3.1. https://www.youtube.com/watch?v=0QTuJO4lhyk
9.6.9.4. Nowy Kierownik Projektu na pokładzie :-)
9.6.9.5. Reakcja Kierownika Projektu po zatwierdzeniu zwiększenia budżetu projektowego :-)
9.7. Kierownik Zespołu (KZ)
9.7.1. Wytwarza produkty specjalistyczne
9.7.2. W przypadku rozbudowanych projektów poszczególne elementy projektu realizują wyodrębnione zespoły.
9.7.2.1. W takim przypadku do kierowania tymi zespołami powoływany jest Kierownik Zespołu.
9.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.
9.7.4. Kierownik Zespołu podlega Kierownikowi Projektu i przyjmuje od niego instrukcje.
9.7.5. Przygotowuje Raporty z Punktów Kontrolnych
9.7.6. Rola wymagana, ale ...
9.7.6.1. Jeśli nie jest delegowana, odpowiedzialność przejmuje KP
9.7.7. Dla wtajemniczonych ...
9.7.7.1. zwany również jako Wesoły Romek
9.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."
9.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!"
9.7.7.2. (miś) "A niech żesz Pan siada i opowiada! Nowiny! Nowiny!"
9.8. Wsparcie Projektu (WP)
9.8.1. Rola, która dostarcza jedynie wsparcie administracyjne, bez jakichkolwiek uprawnień decyzyjnych.
9.8.2. Rola wymagana, ale ...
9.8.2.1. Jeśli nie jest delegowana, odpowiedzialność przejmuje KP
9.8.3. Rola, którą domyślnie pełni KP
9.8.3.1. Rola domyślnie jest łączona z rolą KP
9.8.4. Role o najmniejszych uprawnieniach w całym projekcie (porównując ją z listą domyślnych ról PRINCE2®)
10. Zarządzanie Projektem wg. PRINCE2®
10.1. Celem zarządzania projektami według PRINCE2® jest:
10.1.1. Utrzymanie kontroli nad pracami specjalistycznymi
10.1.2. Motywowanie zaangażowanych osób
10.1.3. Utrzymanie aktualnej wiedzy o stanie projektu
10.1.4. Zagwarantowanie, że projekt nadal ma ważne uzasadnienie biznesowe
10.1.5. Zagwarantowanie, że projekt jest nadal korzystny dla organizacji
10.2. Zarządzanie projektem wg. PRINCE2® to nieustanny cykl
10.2.1. dostosowany cyklu Deminga na potrzeby PRINCE2®
10.2.1.1. Planuj (ang. Plan)
10.2.1.1.1. Planowanie prac do wykonania.
10.2.1.2. Deleguj (ang. Delegate)
10.2.1.2.1. Delegowanie prac do wykonania innym osobom / jednostkom / firmom / podwykonawcom etc.
10.2.1.3. Monitoruj (ang. Monitor)
10.2.1.3.1. Monitorowanie wykonywania prac poprzez raporty i komunikację.
10.2.1.4. Kontroluj (ang. Control)
10.2.1.4.1. Kontrolowanie wykonywanej pracy poprzez podejmowanie działań korygujących.
10.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)
10.2.1.5. czyli planowanie, delegowanie, monitorowanie, kontrolowanie... wszystkich aspektów projektu
10.3. Zalety stosowania PRINCE2®
10.3.1. pełna kontrola nad projektem i efektywne planowanie
10.3.2. analiza wydajności i efektywności procesu realizacji projektu i jego optymalizacja
10.3.3. wczesne ostrzeganie o możliwych problemach i reagowanie na zmiany i ryzyka
10.3.4. wprowadzenie i utrzymywanie dokumentacji i zapisów, budowa bezpieczeństwa projektu
10.3.5. współpraca z systemem zarządzania jakością ISO, korzystanie ze standardów zarządzania organizacją
10.3.6. stosowanie metodyki PRINCE2® podnosi prestiż firmy
10.3.6.1. innymi słowy "dobry marketing PRINCE2®" :-)
10.3.7. z punktu widzenia kontrahenta firma stosująca PRINCE2 jest bardziej atrakcyjnym i wiarygodnym partnerem biznesowym
10.3.7.1. innymi słowy "dobry marketing PRINCE2®" :-)
10.3.8. pozwala bardziej utożsamiać się z projektem osobom, które go realizują
10.3.9. zapewnia strukturę organizacyjną wraz z rolami i przypisanymi im zakresami obowiązków, odpowiedzialności i uprawnień
10.3.10. poprawia komunikację w projekcie
10.3.11. daje sprawdzone rozwiązania zarządcze podnoszące komfort pracy
11. Procesy (7)
11.1. Precyzując 7 typów Procesów, ponieważ niektóre procesy mogą wystąpić kilkukrotnie w projekcie.
11.2. PRINCE2® to sposób podejścia do zarządzania projektami oparty na procesach.
11.2.1. Niektóre procesy działają równolegle, niektóre sekwencyjnie.
11.2.2. Procesów nie należy mylić z etapami, gdyż są to odrębne pojęcia
11.2.2.1. Etapy dzielą cały projekt na określone odcinki czasu (wraz z tolerancjami czasu)
11.2.2.2. Procesy rozpoczynają się i kończą w ramach danego, jednego etapu
11.2.2.2.1. Przez co można powiedzieć, że procesy są częścią etapów.
11.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
11.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):
11.3.1. Zarządzanie Strategiczne
11.3.2. Zarządzania Opracyjne
11.3.3. Dostarczanie Produktów
11.4. Model procesowy PRINCE2®
11.4.1. Dwuetapowy model procesowy PRINCE2®
11.4.1.1. Jednoetapowy model procesowy PRINCE2® (najmniejsza i najkrótsza wersja PRINCE2®)
11.5. Przygotowanie Projektu (PP)
11.5.1. Występuje tylko raz w całym cyklu życia projektu, jest to pierwszy proces od jakiego rozpoczyna się projekt PRINCE2®
11.5.2. W bardzo skrajnym przypadku, proces może nie wystąpić jako samodzielny, odrębny proces
11.5.2.1. Przypadek najmniejszej wersji PRINCE2® - 1 etapowego projektu (tzw. Mały Książę)
11.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
11.5.3. Obecny w fazie przed projektowej (nie należy mylić fazy z etapem)
11.5.3.1. faza przed projektowa (inna nazwa to czynności przed projektowe) nie jest nazywana etapem, ponieważ formalnie nie mamy jeszcze projektu
11.5.3.1.1. W fazie przed projektowej nie są wytwarzane żadne produkty specjalistyczne.
11.5.3.1.2. Są wytwarzane jedynie podstawowe produkty zarządcze
11.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.
11.5.4.1. Praca wykonywana głównie przez Przewodniczącego i Kierownika Projektu
11.5.5. Egzamin Foundation
11.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
11.5.5.2. Procesu PP należy nie mylić z fazą przed projektową (inna nazwa to czynności przed projektowe)
11.5.5.2.1. Faza przed projektowa (czynności przed projektowe) zawiera w sobie 2 procesy: PP i ZSP
11.5.6. Praktyka
11.5.6.1. Proces PP w bardzo małych projektach trwa nawet kilkanaście minut / kilka godzin.
11.5.6.1.1. często proces PP przebiega jedynie w formie ustnej, bez tworzenia jakiejkolwiek dokumentacji, tj. produktów zarządczych
11.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)
11.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?"
11.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
11.5.6.3.1. Praca z dostawcą rozpoczyna się pierwszy etap w PRINCE2® - Etap Inicjowania, gdzie wspólnie z dostawcą budowany jest min. DIP
11.5.7. Rekomendowane czynności w procesie
11.5.7.1. 1. Mianowanie Przewodniczącego i Kierownika Projektu
11.5.7.2. 2. Zgromadzenie dotychczasowych doświadczeń
11.5.7.3. 3. Projektowanie i mianowanie zespołu zarządzania projektem
11.5.7.4. 4. Wybieranie formuły realizacji projektu i zestawianie Założeń Projektu
11.5.7.5. 5. Przygotowanie zarysu Uzasadnienia Biznesowego
11.5.7.6. 6. Planowanie etapu inicjowania
11.6. Zarządzanie Strategiczne Projektem (ZSP)
11.6.1. Występuje tylko raz w całym cyklu życia projektu, jednak trwa praktycznie przez cały projekt)
11.6.2. ZSP zawsze występuje tylko raz i trwa przez cały czas trwania projektu
11.6.3. Proces rozpoczyna się w fazie przed projektowej, czyli jeszcze przed projektem
11.6.3.1. Pod koniec fazy przez projektowej lub w casie jej trwania, ale nigdy podczas startu procesu PP
11.6.3.1.1. Innymi słowy procesy PP i ZSP nie nachodzą / nakładają się na siebie
11.6.4. Obecny na poziomie zarządzania - zarządzanie strategiczne
11.6.4.1. Praca wykonywana głownie przez Komitet Sterujący (KS)
11.6.5. Rekomendowane czynności w procesie
11.6.5.1. Zezwalanie na zainicjowanie projektu
11.6.5.2. Zezwalanie na realizację projektu
11.6.5.3. Zezwalanie na realizację Planu Etapu lub Planu Nadzwyczajnego
11.6.5.4. Podejmowanie decyzji doraźnej
11.6.5.5. Zezwalanie na zamknięcie projektu
11.7. Inicjowanie Projektu (IP)
11.7.1. Występuje tylko raz w całym cyklu życia projektu w początkowym okresie projektu
11.7.2. Obecny w Etapie Inicjowania
11.7.2.1. Nie mylić Etapu Inicjowania z Procesem Inicjowania (IP)
11.7.3. Obecny na poziomie zarządzania - zarządzanie operacyjne
11.7.3.1. Praca wykonywana głownie przez Kierownika Projektu (KP)
11.7.4. Rekomendowane czynności w procesie
11.7.4.1. Opracowanie Strategii Zarządzania Ryzykiem
11.7.4.2. Opracowanie Strategii Zarządzania Jakością
11.7.4.3. Opracowanie Strategii Zarządzania Konfiguracją
11.7.4.4. Opracowanie Strategii Zarządzania Komunikacją
11.7.4.5. Sporządzanie Planu Projektu
11.7.4.6. Ustanowienie mechanizmów sterowania projektem
11.7.4.7. Doprecyzowanie Uzasadnienia Biznesowego
11.7.4.8. Zestawianie Dokumentacji Inicjowania Projektu (DIP)
11.7.5. Egzamin Foundation
11.7.5.1. Procesu IP należy nie mylić z Etapem Inicjowania
11.7.5.1.1. Etap Inicjowania zawiera w sobie procesy: IP, ZKE, ZSP, oraz w niektórych sytuacjach również procesy SE i ZDP
11.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
11.7.5.2.1. Sygnał 1 - Wniosek o realizację projektu (całego projektu)
11.7.5.2.2. Sygnał 2 - Wniosek o zatwierdzenie Planu Etapu (następnego, zbliżającego się etapu)
11.8. Sterowanie Etapem (SE)
11.8.1. SE występuje MINIMUM raz w całym cyklu życia projektu
11.8.2. W bardzo skrajnym przypadku, proces może wystąpić już w Etapie Inicjowania
11.8.2.1. przypadek najmniejszej wersji PRINCE2® - 1 etapowego projektu (tzw. Mały Książę)
11.8.3. Obecny na poziomie zarządzania - zarządzanie operacyjne
11.8.3.1. czyli praca wykonywana głownie przez Kierownika Projektu (KP)
11.8.4. Rekomendowane czynności w procesie
11.8.4.1. Zezwalanie na wykonanie Grupy Zadań
11.8.4.2. Przeglądanie stanu Grupy Zadań
11.8.4.3. Odbieranie zakończonych Grup Zadań
11.8.4.4. Przeglądanie stanu etapu
11.8.4.5. Podejmowanie działań korygujących
11.8.4.6. Wychwytywanie i badanie zagadnień i ryzyk
11.8.4.7. Przekazywanie zagadnień i ryzyk na wyższy szczebel
11.8.4.8. Raportowanie okresowe
11.9. Zarządzanie Dostarczaniem Produktów (ZDP)
11.9.1. ZDP występuje MINIMUM raz w całym cyklu życia projektu
11.9.2. Obecny na poziomie zarządzania - dostarczanie produktów
11.9.2.1. Praca Kierownika Zespołu (KZ)
11.9.3. Obecny w etapach realizacyjnych
11.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
11.9.3.1.1. przypadek najmniejszej wersji PRINCE2® - 1 etapowego projektu (tzw. Mały Książę)
11.9.4. Proces ZDP może wystąpić wiele razy w ramach jednego etapu zarządczego
11.9.5. W procesie ZDP odbywają się zatwierdzenia produktów specjalistycznych
11.9.5.1. ZATWIERDZENIA (nie mylić z akceptacją)
11.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)
11.9.6. Rekomendowane czynności w procesie
11.9.6.1. Przyjmowanie Grupy Zadań do wykonania
11.9.6.2. Wykonywanie Grupy Zadań
11.9.6.3. Oddawanie wykonanej Grupy Zadań
11.10. Zarządzanie Końcem Etapu (ZKE)
11.10.1. W bardzo skrajnym przypadku, proces ZKE może nie wystąpic
11.10.1.1. przypadek najmniejszej wersji PRINCE2® - 1 etapowego projektu (tzw. Mały Książę)
11.10.2. Obecny na poziomie zarządzania - zarządzanie operacyjne
11.10.2.1. Praca wykonywana głownie przez Kierownika Projektu
11.10.3. Rekomendowane czynności w procesie
11.10.3.1. Planowanie następnego etapu
11.10.3.2. Sporządzanie Planu Nadzwyczajnego
11.10.3.3. Uaktualnianie Planu Projektu
11.10.3.4. Uaktualnianie Uzasadnienia Biznesowego
11.10.3.5. Raportowanie zakończenia etapu
11.11. Zamykanie Projektu (ZP)
11.11.1. Występuje tylko raz w całym cyklu życia projektu
11.11.1.1. W ostatnim, końcowym etapie projektu
11.11.2. Obecny na poziomie zarządzania - zarządzanie operacyjne
11.11.2.1. Praca wykonywana głownie przez Kierownika Projektu
11.11.3. W procesie ZP odbywa się akceptacja końcowego produktu projektu
11.11.3.1. AKCEPTACJA (nie mylić z zatwierdzeniem)
11.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)
11.11.4. Rekomendowane czynności w procesie
11.11.4.1. Przygotowanie planowego zamknięcia
11.11.4.2. Przygotowanie przedwczesnego zamknięcia
11.11.4.3. Przekazanie produktów
11.11.4.4. Ocenianie projektu
11.11.4.5. Rekomendowanie zamknięcia projektu
12. Tematy (7)
12.1. Tematy to obszary którymi musimy zarządzać w projekcie prowadzonym wg. PRINCE2®.
12.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.
12.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.
12.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.
12.2. Każdy z tematów zgdonie ze swoim przeznaczeniem odpowiada na konkretne pytanie.
12.3. 1. Uzasadnienie Biznesowe
12.3.1. Temat odpowiada na pytanie...
12.3.1.1. Dlaczego?
12.3.1.1.1. Dlaczego projekt jest nam potrzebny?
12.3.1.1.2. Dlaczego powinniśmy rozpocząć projekt?
12.3.1.1.3. Dlaczego powinniśmy kontynuować projekt?
12.3.1.1.4. Dlaczego powinniśmy zakończyć projekt?
12.3.2. Powody dla podjęcia projektu różnią się znacząco i są determinowane przez środowisko projektu.
12.3.2.1. Projekt zaczyna się od pomysłu, o którym sądzi się, że ma potencjalną wartość dla zainteresowanej organizacji.
12.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ąć.
12.3.3. Project zgodny z PRINCE2® ma ciągle ważne uzasadnienie biznesowe.
12.3.3.1. Innymi słowy jest potrzebny, przydatny i wykonalny.
12.3.3.1.1. potrzebny
12.3.3.1.2. przydatny
12.3.3.1.3. wykonalny
12.3.4. Metodyka PRINCE2® wyróżnia 4 czynności / działania w odniesieniu do Uzasadnienia Biznesowego:
12.3.4.1. 1. Opracowanie Uzasadnienia Biznesowego
12.3.4.2. 2. Weryfikowanie Uzasadnienia Biznesowego
12.3.4.3. 3. Utrzymywanie Uzasadnienia Biznesowego
12.3.4.4. 4. Potwierdzenie Uzasadnienia Biznesowego
12.3.5. Uzasadnienie Biznesowe a cykl życia projektu oraz produktów zarządczych
12.4. 2. Organizacja
12.4.1. Temat odpowiada na pytanie...
12.4.1.1. Kto?
12.4.1.1.1. Kto za co odpowiada w projekcie?
12.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.
12.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.
12.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.
12.4.3.1.1. Każdy projekt wymaga skutecznego kierowania, zarządzania, kontroli i komunikacji.
12.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.
12.4.4. PRINCE2® wyróżnia 4 poziomy w organizacji (4 poziomy zarządzania projektem)
12.4.4.1. Kierownictwo organizacji lub programu
12.4.4.1.1. Zlecanie projektu
12.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.
12.4.4.1.3. Ten poziom jest poziomem spoza projektu
12.4.4.2. Zarządzanie strategiczne – Komitet Sterujący
12.4.4.2.1. Ukierunkowanie projektu
12.4.4.2.2. Strategiczne zarządzanie projektem
12.4.4.3. Zarządzanie operacyjne – Kierownik Projektu
12.4.4.3.1. Operacyjne zarządzanie projektem
12.4.4.4. Dostarczanie produktów – Kierownik Zespołu
12.4.4.4.1. Zarządzanie zespołem(-ami) i dostarczanie produktów
12.4.5. Interesariusze i decydenci
12.4.5.1. Decydenci są to interesariusze, który są uprawnieni do podejmowanie decyzji projektowych.
12.4.5.2. Nie wszyscy interesariusze są decydentami.
12.4.6. Pobierz: PRINCE2® Macierz Procesy vs Produkty Zarządczy vs Role vs Odpowiedzialności (PDF)
12.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
12.5. 3. Jakość
12.5.1. Temat odpowiada na pytanie...
12.5.1.1. Co?
12.5.1.1.1. Co mam dostarczyć w jakiej postaci i na jakim poziomie jakości?
12.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.
12.5.3. Temat Jakość pomaga w zapewnieniu, że produkty projektu:
12.5.3.1. spełniają oczekiwania biznesowe
12.5.3.2. umożliwiają w efekcie uzyskanie pożądanych korzyści opisanych w Uzasadnieniu Biznesowym (A.2)
12.5.4. Ważna terminologia związana z tematem Jakość:
12.5.4.1. Oczekiwania jakościowe klienta
12.5.4.2. Kryteria akceptacji
12.5.4.3. Opis Produktu Końcowego Projektu
12.5.4.4. Formuła realizacji projektu (element Założeń Projektu)
12.5.4.5. Strategia Zarządzania Jakością
12.5.4.6. Opisy Produktów i kryteria jakości
12.5.4.7. Tolerancje jakości
12.5.4.8. Przegląd jakości (technika)
12.5.4.9. Rejestr Jakości
12.5.4.10. Zapisy zatwierdzeń
12.5.4.11. Zapisy akceptacji
12.5.5. Temat Jakość a cykl życia projektu oraz produktów zarządczych
12.6. 4. Plany
12.6.1. Temat odpowiada na pytanie...
12.6.1.1. Jak? Za ile? Kiedy?
12.6.1.1.1. Jak będziemy dostarczać produkty? Czy wytworzymy je samodzielnie, czy wykorzystamy podwykonawcę?
12.6.1.1.2. Ile będzie kosztować dostarczenie / wytworzenie konkretnego produktu?
12.6.1.1.3. Kiedy, w jakim terminie będzie dostarczony / wytworzony / odebrany produkt?
12.6.2. Projekty PRINCE2® przebiegają zgodnie z szeregiem zatwierdzonych planów.
12.6.3. Skuteczne zarządzanie projektami opiera się na efektywnym planowaniu, ponieważ bez planu kontrola nie jest możliwa.
12.6.4. PRINCE2® proponuje dla projektu następujące poziomy planów:
12.6.4.1. 1. Plan Projektu (obowiązkowy)
12.6.4.2. 2. Plan Etapu (obowiązkowy)
12.6.4.3. 3. Plan Zespołu (opcjonalny)
12.6.4.4. 4. Plan Nadzwyczajny
12.6.5. Temat Plany a cykl życia projektu oraz produktów zarządczych
12.7. 5. Ryzyko
12.7.1. Temat odpowiada na pytanie...
12.7.1.1. Co, jeżeli?
12.7.1.1.1. Co zrobimy jeśli wydarzy się dane zdarzenie (negatywne lub pozytywne)?
12.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.
12.7.2.1. Zarządzanie ryzykiem polega na utrzymywaniu ryzyka w akceptowalnych granicach w sposób efektywny i racjonalny kosztowo.
12.7.3. Z projektami związane jest zwykle większe ryzyko niż z ustabilizowanymi działaniami operacyjnymi (ang. Business as Usual).
12.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).
12.7.4.1. Ryzyko to przyszłe niepewne zdarzenie, które jeśli się wydarzy będzie mieć wpływ na cele projektu.
12.7.4.1.1. Zagrożenie (-) – niekorzystny wpływ na cele.
12.7.4.1.2. Szansa (+) – korzystny wpływ na cele.
12.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.
12.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.
12.7.6. Procedura zarządzania ryzykiem składa się z kroków (kroki te wywodzą się bezpośrednio ze standardu M_o_R®):
12.7.6.1. 1. Identyfikuj
12.7.6.1.1. dzieli się na dwa podkroki
12.7.6.2. 2. Oceniaj
12.7.6.2.1. dzieli się na dwa podkroki
12.7.6.3. 3. Planuj
12.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,
12.7.6.4. 4. Wdrażaj
12.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ń,
12.7.6.5. Komunikacja
12.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.
12.7.7. Parametry ryzyka w PRINCE2®:
12.7.7.1. Prawdopodobieństwo
12.7.7.2. Bliskość
12.7.7.3. Wpływ
12.7.7.4. PRINCE2® nie określa czy dane parametry mamy opisywać w sposób ilościowy czy jakościowy.
12.7.7.5. Według PRINCE2® nie mam wpływu na parametr bliskość
12.7.8. Ryzyka możemy podzielić na:
12.7.8.1. Inherentne
12.7.8.1.1. ryzyko pierwotne, wstępne, przed podjęciem działań (reakcji)
12.7.8.2. Rezydualne
12.7.8.2.1. poziom ryzyka po zastosowaniu reakcji na ryzyko
12.7.8.3. Wtórne
12.7.8.3.1. ryzyko, które może wystąpić jako skutek zastosowania reakcji na ryzyko.
12.7.9. Temat Ryzyko a cykl życia projektu oraz produktów zarządczych
12.8. 6. Zmiana
12.8.1. Temat odpowiada na pytanie...
12.8.1.1. Jaki jest wpływ?
12.8.1.1.1. Jak ocenić wpływ zmiany w projekcie na cały projekt?
12.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).
12.8.3. Temat Zmiana a cykl życia projektu oraz produktów zarządczych
12.9. 7. Postępy
12.9.1. Temat odpowiada na pytanie...
12.9.1.1. Gdzie teraz jesteśmy? Dokąd zmierzamy? Czy powinniśmy kontynuować?
12.9.1.1.1. Jak ocenić progres projektu?
12.9.1.1.2. Czy wciąż jesteśmy na bieżąco z terminami?
12.9.1.1.3. Czy wystarczy nam czasu, aby ukończyć projekt w terminie?
12.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.
12.9.3. Delegowanie tolerancji oraz raportowanie
13. Pryncypia (7)
13.1. Projekt PRINCE2® musi bezdyskusyjnie stosować WSZYSTKIE pryncypia
13.1.1. Innymi słowy pryncypia w PRINCE2® to zasady (co jest różnie rozumiane w przypadku innych metodyk)
13.1.2. Jeśli projekt nie stosuje się do pryncypiów to mamy tzw. projekt PINO - "Prince In Name Only"
13.2. Pryncypia wg. PRINCE2® są:
13.2.1. uniwersalne
13.2.1.1. Mają zastosowanie w każdym typie projektu i są niezależne od branży (IT, budownictwo, inżynieria etc.).
13.2.2. samopotwierdzające
13.2.2.1. Sprawdzone na przestrzeni lat praktyki zarządzania projektami.
13.2.3. inspirujące
13.2.3.1. Zwiększają pewność siebie praktyków metodyki PRINCE2®, pozwalają wpływać na projekt, zarządzać i kształtować go.
13.2.4. innymi słowy "dobry marketing PRINCE2®" :-)
13.3. 1. Ciągła zasadność biznesowa
13.3.1. Projekt zgodny z PRINCE2® ma ciągle ważne uzasadnienie biznesowe.
13.3.1.1. Innymi słowy jest potrzebny, przydatny i wykonalny.
13.3.1.1.1. potrzebny
13.3.1.1.2. przydatny
13.3.1.1.3. wykonalny
13.3.2. Wymogiem dla projektu zgodnego z PRINCE2® jest:
13.3.2.1. Istnienie uzasadnionego powodu jego rozpoczęcia.
13.3.2.1.1. tzw. "powody podjęcia projektu"
13.3.2.1.2. Dla każdego projektu są znane uzasadnione powody rozpoczęcia projektu.
13.3.2.2. Uzasadnienie to powinno pozostawać ważne przez cały czas trwania projektu.
13.3.2.2.1. Ważność jest kontrolowana między innymi poprzez kontrolę / sprawdzanie produktu zarządczego Uzasadnienie Biznesowe (A.2)
13.3.2.2.2. Zasadność realizacji projektu istnieje w czasie całego projektu
13.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)
13.3.3. Pryncypium wspierane przez:
13.3.3.1. Produkty Zarządcze
13.3.3.1.1. Uzasadnienie Biznesowe (A.2)
13.3.3.2. Role
13.3.3.2.1. Komitet Sterujący (KS)
13.3.3.2.2. Kierownik Projektu (KP)
13.4. 2. Korzystanie z doświadczeń
13.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.
13.4.2. Wymogiem dla projektu zgodnego z PRINCE2® jest:
13.4.2.1. Korzystanie z doświadczeń zdobytych w poprzednich, podobnych projektach lub z zewnątrz organizacji
13.4.2.2. Zdobywanie doświadczeń w aktualnym projekcie i przekazywanie ich organizacji
13.4.3. Uczenie się na podstawie doświadczeń jest obecne w czasie całego projektu:
13.4.3.1. na początku
13.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)
13.4.3.2. w trakcie trwania
13.4.3.2.1. gromadź dalsze doświadczenia, własne doświadczenia uwzględniaj w raportach i przeglądach
13.4.3.3. w czasie zamykania
13.4.3.3.1. przekaż własne doświadczenia organizacji, by wykorzystanie ich spowodowało korzystne zmiany w organizacji
13.4.4. Pryncypium wspierane przez:
13.4.4.1. Produkty Zarządcze
13.4.4.1.1. Dziennik Doświadczeń (A.14)
13.4.4.1.2. Raport Doświadczeń (A.15)
13.4.4.2. Role
13.4.4.2.1. Komitet Sterujący (KS)
13.4.4.2.2. Kierownik Projektu (KP)
13.5. 3. Zdefiniowane role i obowiązki
13.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.
13.5.2. Jasna i jednoznaczna struktura zespołu zarządzania projektem.
13.5.3. Określone i uzgodnione role i obowiązki osób zaangażowanych w projekt.
13.5.3.1. Każdy wie czego się od niego oczekuje w projekcie.
13.5.4. Zapewnienie efektywnej komunikacji wewnątrz, do i z projektu.
13.5.5. Pryncypium wspierane przez:
13.5.5.1. Produkty Zarządcze
13.5.5.1.1. A.19 Założenia Projektu
13.5.5.1.2. A.20 Dokumentacja Inicjowania Projektu (DIP)
13.5.5.2. Elementy wchodzące w skład produktów zarządczych
13.5.5.2.1. Opis roli Przewodniczącego
13.5.5.2.2. Opis roli Kierownika Projektu
13.5.5.2.3. Opisy ról zespołu zarządzania projektem
13.5.5.2.4. Dodatkowe opisy ról
13.5.5.2.5. Struktura zespołu zarządzania projektem
13.5.5.3. Role
13.5.5.3.1. Kierownictwo organizacji/programu
13.5.5.3.2. Komitet Sterujący (KS)
13.5.5.3.3. Kierownik Projektu (KP)
13.6. 4. Zarządzanie etapowe
13.6.1. Każdy projekt PRINCE2® jest podzielony na Etapy
13.6.1.1. Etapy te nazywają się etapami zarządczymi
13.6.2. Projekt zgodny z PRINCE2® jest planowany, monitorowany i kontrolowany etapowo.
13.6.3. Projekt posiada minimum dwa etapy zarządcze:
13.6.3.1. etap inicjowania
13.6.3.2. jeden lub więcej etapów zarządczych
13.6.4. Projekt realizujemy etap po etapie, tylko jeden etap zarządczy na raz w danej chwili (sekwencyjnie)
13.6.5. Ilość i długość etapów różnicuje kontrolę i monitorowanie prac.
13.6.6. Pryncypium wspierane przez:
13.6.6.1. Produkty Zarządcze
13.6.6.1.1. Plan Projektu (A.16)
13.6.6.1.2. Plan Etapu (A.16)
13.6.6.1.3. Raport Końcowy Etapu (A.9)
13.6.6.2. Role
13.6.6.2.1. Komitet Sterujący (KS)
13.6.6.2.2. Kierownik Projektu (KP)
13.7. 5. Zarządzanie z wykorzystaniem tolerancji
13.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ń.
13.7.2. Zdefiniowane, jasno określone i zatwierdzone obowiązki dla każdego szczebla zarządzania.
13.7.3. Pryncypium wspierane przez:
13.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.
13.7.3.1.1. Parametry tolerancji według PRINCE2®:
13.7.3.2. Produkty Zarządcze
13.7.3.2.1. Strategia Zarządzania Ryzykiem (A.24)
13.7.3.2.2. Plan Projektu (A.16)
13.7.3.2.3. Plan Etapu (A.16)
13.7.3.2.4. Grupa Zadań (A.26)
13.7.3.2.5. Uzasadnienie Biznesowe (A.2)
13.7.3.2.6. Opis Produktu (A.17)
13.7.3.2.7. Opis Produktu Końcowego Projektu (A.21)
13.7.3.3. Role
13.7.3.3.1. Kierownictwo organizacji/programu
13.7.3.3.2. Komitet Sterujący (KS)
13.7.3.3.3. Kierownik Projektu (KP)
13.8. 6. Koncentracja na produktach
13.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.
13.8.2. Projekt PRINCE2® rozpoczyna się od określenie przedmiotu zamówienia (Opis Produktu Końcowego Projektu A.21)
13.8.2.1. Logiczne jest, że wiedząc co mamy zrobić, dopiero po tym myślimy o tym na kiedy i za ile
13.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
13.8.3. Pryncypium wspierane przez:
13.8.3.1. Produkty Zarządcze
13.8.3.1.1. Opis Produktu (A.17)
13.8.3.1.2. Opis Produktu Końcowego Projektu (A.21)
13.8.3.2. Role
13.8.3.2.1. Komitet Sterujący (KS)
13.8.3.2.2. Kierownik Projektu (KP)
13.8.3.2.3. Kierownik Zespołu (KZ)
13.9. 7. Dostosowanie do warunków projektu
13.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.
13.9.2. Należy indywidualnie dostosować metodykę PRINCE2® do każdego projektu.
13.9.2.1. Żaden projekt nie jest taki sam.
13.9.2.2. Ustalenie jak metoda zarządzania projektami w organizacji będzie dostosowana do projektu.
13.9.2.3. Minimum szumu informacyjnego
13.9.3. Pryncypium wspierane przez:
13.9.3.1. Produkty Zarządcze
13.9.3.1.1. Dokumentacja Inicjowania Projektu (A.20)
13.9.3.2. Role
13.9.3.2.1. Komitet Sterujący (KS)
13.9.3.2.2. Kierownik Projektu (KP)
14. Projekt wg. PRINCE2®
14.1. Interpretacja definicji projektu
14.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)"
14.1.1.1. organizacja tymczasowa oznacza ...
14.1.1.1.1. utworzona / powołana tylko na czas projektu o rolach być może innych niż role w stałej strukturze organizacji
14.1.1.2. dostarczenia oznacza ...
14.1.1.2.1. kupienia gotowego, wytworzenia od podstaw, rozbudowy / poprawy obecnego produktu etc.
14.1.1.3. jednego lub więcej produktów oznacza ...
14.1.1.3.1. minimum jeden, aby projekt miał jakikolwiek sens :)
14.1.1.3.2. wielu takich samych, lub wielu całkowicie różnych
14.1.1.4. produktów oznacza ...
14.1.1.4.1. produkt fizyczny, dzieło, usługa, zaprojektowany proces, zatrudniona / przeszkolona osoba, zbudowany system etc.
14.1.1.5. biznesowych oznacza ...
14.1.1.5.1. takich którę są potrzebne dla organizacji i końcowym użytkownikom
14.1.1.5.2. takich które są zgodne z misją, wizją i celami organizacji
14.1.1.5.3. takich które przyniosą korzyści biznesowe dla organizacji klienta / użytkownika
14.1.1.6. Uzasadnienia Biznesowego (A.2) oznacza ...
14.1.1.6.1. opisane w produkcie zarządczym (dla prostoty dokumentacja) o nazwie Uzasadnienie Biznesowe
14.2. 5 Cech wyróżniających projekty od zwykłej działalności biznesowej (tzw. business as usual, BaU)
14.2.1. Zmiany
14.2.1.1. projekt służy do wprowadzania zmian w organizacji
14.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.)
14.2.1.3. Niespodziewana zmiana w organizacji :-)
14.2.2. Tymczasowość
14.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
14.2.2.1.1. projekt kiedyś się rozpoczyna i kiedyś się kończy
14.2.2.2. podobnie każdy etap w projekcie ma ustalony początek i koniec
14.2.2.3. wszystkie inne prace charakteryzują się tym, że trwają nieprzerwanie, wynikają z procesów biznesowych realizowanych w organizacji
14.2.3. Wielofunkcyjność
14.2.3.1. klienci i dostawcy mają różne perspektywy i motywacje
14.2.3.2. projekt angażuje osoby o różnych oczekiwaniach i nastawieniach do projektu
14.2.3.2.1. dostawca
14.2.3.2.2. klient
14.2.3.3. projekt łączy w sobie umiejętności i doświadczenie różnych osób, ekspertów, specjalistów, konsultantów etc.
14.2.4. Unikalność
14.2.4.1. projekt jest realizowany w niepowtarzalnym otoczeniu / kontekście
14.2.4.1.1. między innymi unikalność oznacza również inny okres czasowy w którym są realizowane projekty,
14.2.4.2. każdy projekt jest unikalny i należy go rozpatrywać indywidualnie w kontekście wszystkich 6 efektywności projektu.
14.2.4.2.1. “Different projects need different methodologies” (Alistair Cockburn)
14.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).
14.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.
14.2.5. Niepewność
14.2.5.1. projekt niesie większy poziom ryzyka niż zwykła działalność biznesowa
14.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
14.2.5.2.1. Przemyślenia: Inaczej zamiast zarządzania projektami mielibyśmy automatyzację projektów ...
14.3. 6 zmiennych projektu (tzw. aspekty efektywności)
14.3.1. Zmienne / efektywności projektu, ponieważ mogą zmienić się podczas trwania projektu i musimy je kontrolować.
14.3.2. Oznaczają obszary jakie należy kontrolować przez cały czas trwania projektu.
14.3.3. Koszty
14.3.3.1. kontrolowane min. przez
14.3.3.1.1. budżet projektu
14.3.3.1.2. budżet ryzyka
14.3.3.1.3. budżet zmian
14.3.4. Terminy
14.3.4.1. kontrolowane min. przez
14.3.4.1.1. Plan Projektu (A.16)
14.3.4.1.2. Plany Etapów (A.16)
14.3.4.1.3. Plany Nadzwyczajne (A.16)
14.3.4.1.4. Grupy Zadań (A.26)
14.3.5. Jakość
14.3.5.1. kontrolowane min. przez
14.3.5.1.1. Strategia Zarządzania Jakością (A.22)
14.3.5.1.2. Rejestr Jakości (A.23)
14.3.5.1.3. Opis Produktu Końcowego Projektu (A.21)
14.3.5.1.4. Opis Produktu (A.17)
14.3.6. Zakres
14.3.6.1. Zakres projektu to całkowita suma produktów
14.3.6.1.1. Opisuje on co wchodzi a co nie wchodzi w zakres projektu
14.3.6.1.2. Jest ona określona przez strukturę podziału produktów i związane z nią Opisy Produktów
14.3.6.2. kontrolowane min. przez
14.3.6.2.1. Plan Projektu (A.16)
14.3.6.2.2. Plany Etapów (A.16)
14.3.6.2.3. Grupa Zadań (A.26)
14.3.7. Ryzyko
14.3.7.1. kontrolowane min. przez
14.3.7.1.1. Strategia Zarządzania Ryzykiem (A.24)
14.3.7.1.2. Rejestr Ryzyk (A.25)
14.3.7.1.3. Grupa Zadań (A.26)
14.3.7.2. Jaki jest profil ryzyka projektu
14.3.8. Korzyści
14.3.8.1. kontrolowane min. przez
14.3.8.1.1. Uzasadnienie Biznesowe (A.2)
14.3.8.1.2. Plan Przeglądu Korzyści (A.1)
14.4. Model procesowy PRINCE2®
14.4.1. Dwuetapowy model procesowy PRINCE2®
14.4.1.1. Jednoetapowy model procesowy PRINCE2® (najmniejsza i najkrótsza wersja PRINCE2®)
15. Struktura PRINCE2®
15.1. Metodyka PRINCE2® to 4 zintegrowane elementy
15.1.1. Pryncypia
15.1.2. Tematy
15.1.3. Procesy
15.1.4. Środowisko projektu
15.2. "Magiczna liczba 7"
15.2.1. 7 Pryncypiów
15.2.1.1. siedem przewodnich zasad / nakazów
15.2.2. 7 Tematów
15.2.2.1. siedem obszarów wiedzy zarządzania projektem
15.2.3. 7 Procesów (typów procesów)
15.2.3.1. siedem grup działań, opisujących co należy robić w projekcie w całym jego cyklu życia
15.2.4. Środowisko projektu
15.2.4.1. Dostosowanie metodyki PRINCE2® do środowiska w którym realizowany jest projekt
15.2.4.1.1. środowiska i kultury organizacji / firmy w ramach której prowadzony jest projekt PRINCE2®
15.2.4.1.2. środowiska zewnętrznego spoza organizacji w ramach której prowadzony jest projekt PRINCE2®
15.2.4.2. Oznacza to min. wprowadzeniu specyficznej, branżowej terminologii / języka
15.2.4.3. Dostosowanie dokumentacji pod potrzeby / wymagania organizacji oraz projektu
15.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
15.3. PRINCE2® nie obejmuje
15.3.1. aspektów specjalistycznych / branżowych
15.3.2. szczegółowych / specjalistycznych technik i narzędzi zarządzania projektami
15.3.3. oprogramowania do zarządzania projektami
15.3.4. zdolności przywódczych
15.3.5. aspektów motywacji pracowników
15.3.6. aspektów miękkich
15.3.7. aspektów prawnych
15.3.8. negocjacji
15.3.9. kontraktowania / umów
15.3.10. rozwiązywania konfliktów
15.3.11. ...
16. Produkty zarządcze (26)
16.1. Produkty zarządcze typu: Bazowe
16.1.1. a.k.a. "fundament PRINCE2®"
16.1.2. Produkty zarządcze typu "bazowe", określają podstawowe aspekty zarządzania projektem PRINCE2®.
16.1.3. K.P. NIE może aktualizować tych produktów zarządczych bez potrzeby zgody Komitetu Sterującego
16.1.3.1. Wyjątkiem jest Grupa Zadań (A.26)
16.1.4. A.1 Plan Przeglądu Korzyści
16.1.4.1. Rekomendowana zawartość
16.1.4.1.1. Zakres Planu Przeglądu Korzyści, obejmujący wykaz oczekiwanych korzyści podlegających pomiarowi.
16.1.4.1.2. Osoby odpowiedzialne za osiągnięcie oczekiwanych korzyści.
16.1.4.1.3. Sposoby i terminy pomiaru oczekiwanych korzyści.
16.1.4.1.4. Zasoby niezbędne do przeprowadzenia przeglądu korzyści.
16.1.4.1.5. Poziomy odniesienia, względem których będzie obliczana poprawa.
16.1.4.1.6. Sposób przeglądu efektywności produktu końcowego projektu.
16.1.5. A.2 Uzasadnienie Biznesowe
16.1.5.1. Rekomendowana zawartość
16.1.5.1.1. Podsumowanie
16.1.5.1.2. Powody podjęcia projektu
16.1.5.1.3. Możliwe rozwiązania biznesowe
16.1.5.1.4. Oczekiwane korzyści
16.1.5.1.5. Przewidywane niepożądane skutki
16.1.5.1.6. Terminy
16.1.5.1.7. Koszty
16.1.5.1.8. Ocena inwestycji
16.1.5.1.9. Główne ryzyka
16.1.6. A.4 Strategia Zarządzania Komunikacją
16.1.6.1. Rekomendowana zawartość
16.1.6.1.1. Wprowadzenie
16.1.6.1.2. Procedura komunikacji
16.1.6.1.3. Narzędzia i techniki
16.1.6.1.4. Wymagane zapisy
16.1.6.1.5. Raportowanie
16.1.6.1.6. Terminy działań związanych z komunikacją
16.1.6.1.7. Role i ich obowiązki
16.1.6.1.8. Analiza interesariuszy
16.1.6.1.9. Potrzeby informacyjne każdej z zainteresowanych stron
16.1.7. A.6 Strategia Zarządzania Konfiguracją
16.1.7.1. Rekomendowana zawartość
16.1.7.1.1. Wprowadzenie
16.1.7.1.2. Procedura zarządzania konfiguracją
16.1.7.1.3. Procedura obsługi zagadnień i sterowania zmianami
16.1.7.1.4. Narzędzia i techniki
16.1.7.1.5. Wymagane zapisy
16.1.7.1.6. Raportowanie
16.1.7.1.7. Terminy działań związanych z zarządzaniem konfiguracją i sterowaniem zagadnieniami oraz zmianami
16.1.7.1.8. Role i ich obowiązki
16.1.7.1.9. Skala ocen priorytetu i wagi
16.1.8. A.16 Plan
16.1.8.1. Plany dzielą się na 3 poziomy planów, ale PRINCE2® identyfikuje 5 typów planów
16.1.8.1.1. spoza PRINCE2®, nad projektem np. wywodzą się z programu
16.1.8.1.2. poziom projektu i etapu zarazem
16.1.8.1.3. 3. poziom dostarczania produktów specjalistycznych
16.1.8.2. Rekomendowana zawartość
16.1.8.2.1. Opis planu
16.1.8.2.2. Warunki wstępne dla planu
16.1.8.2.3. Zależności zewnętrzne
16.1.8.2.4. Założenia planistyczne
16.1.8.2.5. Uwzględnione doświadczenia
16.1.8.2.6. Monitorowanie i kontrola
16.1.8.2.7. Budżety
16.1.8.2.8. Tolerancje
16.1.8.2.9. Opisy produktów (A.17)
16.1.8.2.10. Harmonogram
16.1.9. A.17 Opis Produktu
16.1.9.1. Rekomendowana zawartość
16.1.9.1.1. Identyfikator
16.1.9.1.2. Nazwa
16.1.9.1.3. Przeznaczenie
16.1.9.1.4. Zawartość/Skład
16.1.9.1.5. Pochodzenie
16.1.9.1.6. Wymagany format i sposób przedstawienia
16.1.9.1.7. Wymagane umiejętności wytwórcy
16.1.9.1.8. Kryteria jakości
16.1.9.1.9. Tolerancja jakości
16.1.9.1.10. Metoda kontroli jakości
16.1.9.1.11. Wymagane umiejętności kontrolera jakości
16.1.9.1.12. Obowiązki dotyczące jakości
16.1.10. A.19 Założenia Projektu
16.1.10.1. Rekomendowana zawartość
16.1.10.1.1. Definicja projektu
16.1.10.1.2. Zarys Uzasadnienia Biznesowego
16.1.10.1.3. Opis Produktu Końcowego Projektu
16.1.10.1.4. Formuła realizacji projektu
16.1.10.1.5. Struktura zespołu zarządzania projektem
16.1.10.1.6. Opisy ról
16.1.10.1.7. Odniesienia
16.1.11. A.20 Dokumentacja Inicjowania Projektu (DIP)
16.1.11.1. Rekomendowana zawartość
16.1.11.1.1. Definicja projektu
16.1.11.1.2. Formuła realizacji projektu
16.1.11.1.3. Uzasadnienie Biznesowe
16.1.11.1.4. Struktura zespołu zarządzania projektem
16.1.11.1.5. Opisy ról
16.1.11.1.6. Strategia Zarządzania Jakością (A.22)
16.1.11.1.7. Strategia Zarządzania Konfiguracją (A.6)
16.1.11.1.8. Strategia Zarządzania Ryzykiem (A.24)
16.1.11.1.9. Strategia Zarządzania Komunikacją (A.4)
16.1.11.1.10. Plan Projektu (A.16)
16.1.11.1.11. Mechanizmy sterowania
16.1.11.1.12. Dostosowanie metodyki PRINCE2
16.1.12. A.21 Opis Produktu Końcowego Projektu
16.1.12.1. Rekomendowana zawartość
16.1.12.1.1. Nazwa
16.1.12.1.2. Przeznaczenie
16.1.12.1.3. Zawartość/skład
16.1.12.1.4. Pochodzenie
16.1.12.1.5. Wymagane umiejętności wytwórcy
16.1.12.1.6. Oczekiwania jakościowe klienta
16.1.12.1.7. Kryteria akceptacji
16.1.12.1.8. Tolerancje projektu
16.1.12.1.9. Metoda akceptacji
16.1.12.1.10. Obowiązki dotyczące akceptacji
16.1.13. A.22 Strategia Zarządzania Jakościa
16.1.13.1. Rekomendowana zawartość
16.1.13.1.1. Wprowadzenie
16.1.13.1.2. Procedura zarządzania jakością
16.1.13.1.3. Narzędzia i techniki
16.1.13.1.4. Wymagane zapisy
16.1.13.1.5. Raportowanie
16.1.13.1.6. Terminy działań związanych z zarządzaniem jakością
16.1.13.1.7. Role i obowiązki
16.1.14. A.24 Strategia Zarządzania Ryzykiem
16.1.14.1. Rekomendowana zawartość
16.1.14.1.1. Wprowadzenie
16.1.14.1.2. Procedura zarządzania ryzykiem
16.1.14.1.3. Narzędzia i techniki
16.1.14.1.4. Wymagane zapisy
16.1.14.1.5. Raportowanie
16.1.14.1.6. Terminy działań związanych z zarządzaniem ryzykiem
16.1.14.1.7. Role i obowiązki
16.1.14.1.8. Skale ocen
16.1.14.1.9. Bliskość
16.1.14.1.10. Kategorie ryzyka
16.1.14.1.11. Kategorie reakcji na ryzyko
16.1.14.1.12. Wskaźniki wczesnego ostrzegania
16.1.14.1.13. Tolerancja ryzyka
16.1.14.1.14. Budżet ryzyka
16.1.15. A.26 Grupa Zadań
16.1.15.1. Rekomendowana zawartość
16.1.15.1.1. Data
16.1.15.1.2. Kierownik Zespołu lub osoba upoważniona
16.1.15.1.3. Opis Grupy Zadań
16.1.15.1.4. Techniki, procesy i procedury
16.1.15.1.5. Punkty styku (interfejsy) w okresie wytwarzania
16.1.15.1.6. Punkty styku (interfejsy) związane z eksploatacją i utrzymaniem
16.1.15.1.7. Wymagania zarządzania konfiguracją
16.1.15.1.8. Uzgodnienia
16.1.15.1.9. Tolerancje
16.1.15.1.10. Ograniczenia
16.1.15.1.11. Uzgodnienia dotyczące raportowania
16.1.15.1.12. Sposoby obsługi i przekazywania problemów
16.1.15.1.13. Wyciągi lub odniesienia do dokumentów powiązanych
16.1.15.1.14. Metoda zatwierdzenia (odbioru) wykonanej Grupy Zadań
16.2. Produkty zarządcze typu: Zapisy
16.2.1. a.k.a. "dynamika PRINCE2®"
16.2.2. Produkty zarządcze typu "zapisy", zawierają "dynamiczne" informacje wraz z historią zmian o stanie projektu. Podlegają częstym aktualizacjom.
16.2.3. K.P. może aktualizować te dokumenty bez potrzeby otrzymania zgody od Komitetu Sterującego
16.2.4. A.5 Zapisy Obiektu Konfiguracji
16.2.4.1. Rekomendowana zawartość
16.2.4.1.1. Identyfikator projektu
16.2.4.1.2. Identyfikator obiektu
16.2.4.1.3. Aktualna wersja
16.2.4.1.4. Nazwa obiektu
16.2.4.1.5. Data ostatniej zmiany statusu
16.2.4.1.6. Docelowy właściciel produktu
16.2.4.1.7. Miejsce przechowywania
16.2.4.1.8. Aktualni posiadacze
16.2.4.1.9. Rodzaj obiektu
16.2.4.1.10. Cechy obiektu
16.2.4.1.11. Etap
16.2.4.1.12. Użytkownicy
16.2.4.1.13. Status
16.2.4.1.14. Stadium produktu
16.2.4.1.15. Wariant
16.2.4.1.16. Wytwórca/producent
16.2.4.1.17. Data przydzielenia wytwórcy
16.2.4.1.18. Pochodzenie produktu
16.2.4.1.19. Związek z innymi produktami
16.2.4.1.20. Powiązania
16.2.5. A.7 Dziennik Projektu
16.2.5.1. Rekomendowana zawartość
16.2.5.1.1. Data wpisu.
16.2.5.1.2. Problem, działanie, zdarzenie lub komentarz
16.2.5.1.3. Osoba odpowiedzialna
16.2.5.1.4. Wyznaczony termin
16.2.5.1.5. Rezultaty
16.2.6. A.12 Rejestr Zagadnień
16.2.6.1. Rekomendowana zawartość
16.2.6.1.1. Identyfikator zagadnienia
16.2.6.1.2. Typ zagadnienia
16.2.6.1.3. Data zgłoszenia
16.2.6.1.4. Zgłoszone przez
16.2.6.1.5. Autor Raportu o Zagadnieniu
16.2.6.1.6. Opis zagadnienia
16.2.6.1.7. Priorytet
16.2.6.1.8. Waga/znaczenie
16.2.6.1.9. Status
16.2.6.1.10. Data zamknięcia
16.2.7. A.14 Dziennik Doświadczeń
16.2.7.1. Repozytorium doświadczeń, które mają zastosowanie do tego projektu lub przyszłych projektów.
16.2.7.2. Jego zawartość może pochodzić z innych projektów i zawierać doświadczenie zebrane przez inne podmioty / firmy..
16.2.7.3. Rekomendowana zawartość
16.2.7.3.1. Typ doświadczenia
16.2.7.3.2. Opis doświadczenia
16.2.7.3.3. Data wpisu
16.2.7.3.4. Wpisane przez
16.2.7.3.5. Priorytet
16.2.8. A.23 Rejestr Jakości
16.2.8.1. Rekomendowana zawartość
16.2.8.1.1. Numer wpisu
16.2.8.1.2. identyfikator(y) produktu(-ów)
16.2.8.1.3. Nazwa(-y) produktu(-ów)
16.2.8.1.4. Metoda
16.2.8.1.5. Role i obowiązki
16.2.8.1.6. Terminy
16.2.8.1.7. Wynik
16.2.8.1.8. Zapisy jakości
16.2.9. A.25 Rejestr Ryzyk
16.2.9.1. Rekomendowana zawartość
16.2.9.1.1. Identyfikator ryzyka
16.2.9.1.2. Autor zgłoszenia
16.2.9.1.3. Data zarejestrowania
16.2.9.1.4. Kategoria ryzyka
16.2.9.1.5. Opis ryzyka
16.2.9.1.6. Prawdopodobieństwo, wpływ i wartość oczekiwana
16.2.9.1.7. Bliskość ryzyka
16.2.9.1.8. Kategorie reakcji na ryzyko
16.2.9.1.9. Proponowane reakcje na ryzyko
16.2.9.1.10. Status ryzyka
16.2.9.1.11. Właściciel ryzyka
16.2.9.1.12. Wykonawca reakcji na ryzyko
16.3. Produkty zarządcze typu: Raporty
16.3.1. a.k.a. "statyka PRINCE2®"
16.3.2. Produkty zarządcze typu "raporty", przekazują aktualne informacje o stanie projektu.
16.3.3. Są to "statyczne" (a.k.a. snapshot, point in time / photo) produkty zarządcze, gdyż nie podlegają aktualizacjom.
16.3.3.1. Wyjątkiem jest Raport o Zagadnieniu (A.13)
16.3.4. A.3 Raport z Punktu Kontrolnego
16.3.4.1. Rekomendowana zawartość
16.3.4.1.1. Data opracowania
16.3.4.1.2. Okres sprawozdawczy
16.3.4.1.3. Wykonanie wcześniej zleconych czynności
16.3.4.1.4. Bieżący okres sprawozdawczy
16.3.4.1.5. Następny okres sprawozdawczy
16.3.4.1.6. Stan tolerancji Grupy Zadań
16.3.4.1.7. Zagadnienia i ryzyka
16.3.5. A.8 Raport Końcowy Projektu
16.3.5.1. Rekomendowana zawartość
16.3.5.1.1. Sprawozdanie Kierownika Projektu
16.3.5.1.2. Przegląd Uzasadnienia Biznesowego
16.3.5.1.3. Przegląd realizacji celów projektu
16.3.5.1.4. Przegląd efektywności zespołu projektowego
16.3.5.1.5. Przegląd produktów
16.3.5.1.6. Raport Doświadczeń (A.15)
16.3.6. A.9 Raport Końcowy Etapu
16.3.6.1. Rekomendowana zawartość
16.3.6.1.1. Sprawozdanie Kierownika Projektu
16.3.6.1.2. Przegląd Uzasadnienia Biznesowego
16.3.6.1.3. Przegląd realizacji celów projektu
16.3.6.1.4. Przegląd realizacji celów etapu
16.3.6.1.5. Przegląd efektywności zespołu projektowego
16.3.6.1.6. Przegląd produktów
16.3.6.1.7. Raport Doświadczeń (opcjonalnie) (A.15)
16.3.6.1.8. Zagadnienia i ryzyka
16.3.6.1.9. Prognoza
16.3.7. A.10 Raport Nadzywczajny
16.3.7.1. Rekomendowana zawartość
16.3.7.1.1. Opis sytuacji nadzwyczajnej
16.3.7.1.2. Przyczyna wystąpienia
16.3.7.1.3. Skutki odchylenia
16.3.7.1.4. Możliwe reakcje
16.3.7.1.5. Rekomendacja
16.3.7.1.6. Doświadczenia
16.3.8. A.11 Raport Okresowy
16.3.8.1. Rekomendowana zawartość
16.3.8.1.1. Data opracowania
16.3.8.1.2. Okres sprawozdawczy
16.3.8.1.3. Sumaryczny opis stanu etapu
16.3.8.1.4. Bieżący okres sprawozdawczy
16.3.8.1.5. Następny okres sprawozdawczy
16.3.8.1.6. Stan tolerancji projektu i etapu
16.3.8.1.7. Wnioski o wprowadzenie zmiany
16.3.8.1.8. Główne zagadnienia i ryzyka
16.3.8.1.9. Raport Doświadczeń
16.3.9. A.13 Raport o Zagadnieniu
16.3.9.1. Rekomendowana zawartość
16.3.9.1.1. Identyfikator zagadnienia
16.3.9.1.2. Typ zagadnienia
16.3.9.1.3. Data zgłoszenia
16.3.9.1.4. Zgłoszone przez
16.3.9.1.5. Autor Raportu o Zagadnieniu
16.3.9.1.6. Opis zagadnienia
16.3.9.1.7. Analiza wpływu
16.3.9.1.8. Rekomendacja
16.3.9.1.9. Priorytet
16.3.9.2. Egzamin Foundation
16.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.
16.3.10. A.15 Raport Doświadczeń
16.3.10.1. Wykorzystywany do przekazywania wszelkich doświadczeń, które można z powodzeniem zastosować do innych projektów
16.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
16.3.10.3. Rekomendowana zawartość
16.3.10.3.1. Podsumowanie
16.3.10.3.2. Zakres raportu (np. etap lub projekt)
16.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
16.3.10.3.4. Przegląd użytecznych miar
16.3.10.3.5. W przypadku doświadczeń o istotnym znaczeniu, przydatne mogą być dodatkowe informacje
16.3.10.4. Egzamin Foundation
16.3.10.4.1. Raport Doświadczeń NIE Doświadczenia
16.3.11. A.18 Zestawienie Statusów Produktów
16.3.11.1. Rekomendowana zawartość
16.3.11.1.1. Zakres raportu
16.3.11.1.2. Data wytworzenia
16.3.11.1.3. Status produktów
16.3.11.2. Egzamin Foundation
16.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ę).
16.4. Praktyka
16.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.
16.4.1.1. Produkt zarządczy może być generowany automatycznie podczas eksportu z narzędzia / oprogramowania do zarządzania projektami.
17. Interaktywny glosariusz
17.1. Interaktywny glosariusz PRINCE2® (PL)
18. Techniki (2)
18.1. Obie techniki są związana z tematem Jakość.
18.2. Technika planowania opartego na produktach (ang. Product-based Planning)
18.2.1. Cel
18.2.1.1. Identyfikacja produktów które mają być wytworzone lub uzyskane w projekcie
18.2.1.1.1. Znacząco pomaga to w jednoznacznym określeniu zakresu projektu.
18.2.1.2. Określenie dodatkowych produktów potrzebnych do wytworzenia produktu głównego
18.2.1.3. Wypracowanie najlepszego pogrupowania tych produktów
18.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.
18.2.2.1. Planowanie oparte na produktach jest integralną częścią PRINCE2® dotyczącą koncentracji na jakości produktów.
18.2.2.2. Technika ta zapewnia platformę planistyczną opartą na produktach, która pozwala ustawić prace nad projektem w logicznej kolejności.
18.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.
18.2.4. W ramach techniki planowania opartego na produktach powstają cztery produkty zarządcze (krok po kroku, sekwencyjnie):
18.2.4.1. 1. Opis Produktu Końcowego Projektu
18.2.4.2. 2. Diagram struktury produktów (ang. product breakdown structure)
18.2.4.2.1. Jest to hierarchiczne przedstawienie wszystkich produktów, które mają być wytworzone w ramach planu (Planu Projektu lub Planu Etapu).
18.2.4.2.2. Tworząc strukturę produktową zaczyna się od ustalenia produktu projektu (krok 1) i dekompozycji na podprodukty (krok 2).
18.2.4.3. 3. Opis Produktu dla każdego z produktów
18.2.4.3.1. Jasny, kompletny i jednoznaczny opis produktu stanowi ogromną pomoc przy jego tworzeniu.
18.2.4.3.2. Opis taki zawiera informacje o zastosowaniu produktu, kryteriach jakości, tolerancji jakości, ilość wymaganych produków etc.
18.2.4.4. 4. Diagram następstwa produktów
18.2.4.4.1. Diagram następstwa produktów pokazuje kolejność produkowania oraz wzajemne zależności pomiędzy produktami wymienionymi w strukturze projektowej.
18.3. Technika przeglądu jakości
18.3.1. Cel
18.3.1.1. Ocena zgodności z ustalonymi kryteriami produktu w postaci dokumentu (lub prezentacji czy wyników testu)
18.3.1.2. Zaangażowanie kluczowych zainteresowanych stron w sprawdzenie jakości produktu oraz działania na rzecz szerszej akceptacji produktu
18.3.1.3. Potwierdzenie, że produkt został ukończony i jest gotowy do zatwierdzenia
18.3.1.4. Ustanowienie obiektu odniesienia dla produktu na potrzeby sterowania zmianami
18.3.2. „Przegląd jakości", służy do testowania jakości produktów będących dokumentami.
18.3.2.1. Zasady tej techniki mogą być również zastosowane do testowania i przeglądów jakości pozostałych produktów.
18.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.
18.3.3. W PRINCE2® wyróżnia się 4 specyficzne role związane z przeglądem jakości:
18.3.3.1. Kierownik przeglądu jakości
18.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.
18.3.3.2. Prezenter
18.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.
18.3.3.3. Kontroler / Recenzent
18.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.
18.3.3.4. Administrator
18.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.
18.3.3.5. Role mogą być łączone
18.3.3.5.1. Najmniejsza forma to 2 osoby
18.3.4. W procedurze przeglądu jakości należy wykonać 3 podstawowe kroki
18.3.4.1. 1. Przygotowanie przeglądu (oraz przeprowadzenie przeglądu)
18.3.4.1.1. 1. potwierdzenia, że produkt jest gotowy do przeglądu,
18.3.4.1.2. 2. potwierdzenia dostępności wyznaczonych testerów oraz uzgodnienia daty zwrotu uwag testerów oraz daty samego przeglądu,
18.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,
18.3.4.1.4. 4. oceny zgodności produktu z kryteriami jakości,
18.3.4.1.5. 5. zapisania zastrzeżeń oraz podejrzewanych błędów na liście zastrzeżeń,
18.3.4.1.6. 6. odnotowania mniej ważnych błędów na produkcie (np. gramatycznych i ortograficznych),
18.3.4.1.7. 7. zwrócenia produktu z adnotacjami wraz z listą zastrzeżeń do wytwórcy,
18.3.4.1.8. 8. zaplanowania narady przeglądu jakości oraz uzgodnienia jej programu (agendy).
18.3.4.2. 2. Narada przeglądu jakości (jeśli wykryto niezgodności w produktach w 1 kroku)
18.3.4.2.1. 1. dyskusji, wyjaśnienia oraz uzgodnienia wszystkich spraw przedstawionych przez testerów,
18.3.4.2.2. 2. uzgodnienia działań następczych odpowiednich dla każdego uzgodnionego błędu,
18.3.4.2.3. 3. udokumentowania odpowiedzialności za działania następcze,
18.3.4.2.4. 4. podsumowania zaplanowanych działań na koniec narady,
18.3.4.2.5. 5. uzgodnienia wyniku przeglądu jakości oraz podpisania zatwierdzenia produktu, jeśli jest to możliwe,
18.3.4.2.6. 6. zaktualizowania Rejestru Jakości.
18.3.4.3. 3. Działania po naradzie przeglądu jakości
18.3.4.3.1. 1. powiadomienia Kierownika Projektu i/lub Kierownika Zespołu o wyniku przeglądu jakości,
18.3.4.3.2. 2. zaplanowania wszelkich potrzebnych prac naprawczych,
18.3.4.3.3. 3. podpisania zatwierdzenia produktu w następstwie zakończonych powodzeniem prac naprawczych,
18.3.4.3.4. 4. zaktualizowania Rejestru Jakości.
19. Procedury (2)
19.1. Obie procedury są związana z tematem Zmiana.
19.2. Procedura sterowania zagadnieniami i zmianami
19.2.1. 5 kroków działających sekwencyjnie
19.2.1.1. 1. Zarejestruj
19.2.1.1.1. Określ rodzaj zagadnienia
19.2.1.1.2. Określ wagę, priorytet
19.2.1.1.3. Zapisz w Dzienniku Projektu lub Rejestrze Zagadnień
19.2.1.2. 2. Analizuj
19.2.1.2.1. Oceń wpływ na cele projektu, Uzasadnienie Biznesowe i profil ryzyka projektu
19.2.1.2.2. Sprawdź wagę, priorytet
19.2.1.3. 3. Proponuj
19.2.1.3.1. Określ możliwe opcje reakcji
19.2.1.3.2. Oceń opcje
19.2.1.3.3. Rekomenduj opcje
19.2.1.4. 4. Zdecyduj
19.2.1.4.1. Przekaż wyżej, jeśli poza delegowanymi uprawnieniami
19.2.1.4.2. Zatwierdź, odrzuć lub odrocz rekomendowaną opcję
19.2.1.5. 5. Wdrażaj
19.2.1.5.1. Podejmij działania korygujące
19.2.1.5.2. Uaktualnij zapisy i plany
19.3. Procedura zarządzania konfiguracją
19.3.1. 5 kroków działających sekwencyjnie
19.3.1.1. 1. Planowanie
19.3.1.1.1. Określenie, jaki poziom szczegółowości zarządzania konfiguracją jest właściwy dla projektu.
19.3.1.2. 2. Identyfikowanie
19.3.1.2.1. Identyfikowanie obiektów konfiguracji na ustalonym poziomie szczegółowości.
19.3.1.3. 3. Sterowanie
19.3.1.3.1. zatwierdzanie produktów projektu,
19.3.1.3.2. nadawanie im statusu obiektów odniesienia,
19.3.1.3.3. wprowadzanie zmian zgodnie z procedurą i przez uprawnionych decydentów,
19.3.1.3.4. archiwizowanie poprzednich wersji obiektów odniesienia,
19.3.1.3.5. przechowywanie i odzyskiwanie informacji istotnych dla zarządzania projektem,
19.3.1.3.6. zapewnianie bezpieczeństwa,
19.3.1.3.7. kontrolowanie dostępu,
19.3.1.3.8. dystrybuowanie kopii obiektów konfiguracji,
19.3.1.3.9. archiwizowanie dokumentacji projektu.
19.3.1.4. 4. Zestawienie statusu
19.3.1.4.1. Tworzenie raportu Zestawienie Statusu Produktów w celu uchwycenia bieżących i historycznych danych dotyczących danych produktów.
19.3.1.5. 5. Weryfikowanie i audyt (konfiguracji)
19.3.1.5.1. Weryfikowanie, czy faktyczny zatwierdzony stan produktów odpowiada ich statusom zarejestrowanym w Zapisach Obiektów Konfiguracji.
19.3.1.5.2. Sprawdzenie, czy w projekcie zarządzanie konfiguracją odbywa się zgodnie z wytycznymi Strategii Zarządzania Konfiguracją.
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.