PRINCE2® - PRojects IN Controlled Environments 2

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

1.1. 1989

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

1.2. PRINCE2® v1 was published in 16.06.1996.

1.2.1. Release of first edition of PRINCE2

1.3. PRINCE2® v2 was published 1998.

1.4. PRINCE2® v3 was published in 2002.

1.5. PRINCE2® v4 was published in 2005.

1.6. PRINCE2® v5 was published in 2009.

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

1.7. PRINCE2® v6 was published in 2017.

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

1.8.1. PRINCE2® in AXELOS® Global Best Practices family

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

1.9.1. PRINCE2® Agile

1.9.1.1. see PRINCE2® Agile mind map

1.9.2. ITIL®

1.9.2.1. see ITIL® mindmap

1.9.3. M_o_R® - Management of Risk

1.9.3.1. see M_o_R® mindmap

1.9.4. MoV® - Management of Value

1.9.4.1. see MoV® mindmap

1.9.5. MoP® - Management of Portfolios

1.9.5.1. see MoP® mindmap

1.9.6. MSP® - Managing Successful Programmes

1.9.6.1. see MSP® mindmap

1.9.7. P3O® - Portfolio, Programme and Project Office

1.9.7.1. see P3O® mindmap

1.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."

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

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

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

2. 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)

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

2.2. Download: PRINCE2® Process Model (PDF)

3. 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!)

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

3.1.1. http://www.miroslawdabrowski.com

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

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

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

3.1.5. https://twitter.com/mirodabrowski

3.1.6. miroslaw_dabrowski

4. PRINCE2® Official publications

4.1. PRINCE2® Skuteczne Zarządzanie Projektami

4.1.1. ISBN-13: 978-0113312245

4.1.2. 365 stron

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

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

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

4.1.4.2. Niezbędna pozycja podczas egzaminu Practitioner

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

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

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

4.2. Directing Successful Projects with PRINCE2®

4.2.1. ISBN-13: 978-0113310609

4.2.2. 166 stron

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

4.3. Passing your PRINCE2 Examinations 2009 Edition

4.3.1. ISBN-13: 978-0113311903

4.3.2. 172 stron

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

4.4. PRINCE2® Maturity Model (P2MM)

4.4.1. 34 strony

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

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

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

4.5.1. 22 strony

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

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

5. PRINCE2® Official resources

5.1. PRINCE2® sample exams available online

5.1.1. Foundation

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

5.1.2. Practitioner

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

5.2. PRINCE2® syllabus

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

5.3. Glosariusz PRINCE2®

5.3.1. EN

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

5.3.2. PL

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

5.4. PRINCE2® management products templates

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

5.5. PRINCE2® official website

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

6. PRINCE2® Foundation exam prep questions

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

7. PRINCE2® Foundation courseware

8. Interactive PRINCE2® Glossary

8.1. Interactive PRINCE2® Glossary

9. How PRINCE2® defines project

9.1. Interpreting project definition

9.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)"

9.1.1.1. temporary organization means ...

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

9.1.1.2. delivering means ...

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

9.1.1.3. one or more business products means ...

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

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

9.1.1.4. products means ...

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

9.1.1.5. business means ...

9.1.1.5.1. Those that are needed for organizations and end users

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

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

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

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

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

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

9.2.1.1. Project is finite.

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

9.2.1.2. We can say that business operations are permanent.

9.2.2. Change

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

9.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.).

9.2.3. Temporary

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

9.2.3.1.1. Once the project begins and comes to an end

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

9.2.4. Cross-Functional

9.2.4.1. Customers and suppliers have various perspectives and motivations.

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

9.2.4.2.1. Supplier

9.2.4.2.2. Klient

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

9.2.5. Unique

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

9.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.)

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

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

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

9.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).

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

9.2.6. Uncertainty

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

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

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

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

9.3. 6 project performance variables (effectiveness aspects)

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

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

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

9.3.3. Costs

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

9.3.3.2. controlled using

9.3.3.2.1. project budget

9.3.3.2.2. risk budget

9.3.3.2.3. change budget

9.3.4. Timescales

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

9.3.4.2. controlled using management products such as ...

9.3.4.2.1. Project Plan (A.16)

9.3.4.2.2. Stage Plan (A.16)

9.3.4.2.3. Exception Plan (A.16)

9.3.4.2.4. Work Package (A.26)

9.3.5. Quality

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

9.3.5.2. controlled using management products such as ...

9.3.5.2.1. Quality Management Strategy (A.22)

9.3.5.2.2. Quality Registry (A.23)

9.3.5.2.3. Project Product Description (A.21)

9.3.5.2.4. Product Description (A.17)

9.3.6. Scope

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

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

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

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

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

9.3.6.3. controlled using management products such as ...

9.3.6.3.1. Project Plan (A.16)

9.3.6.3.2. Stage Plan (A.16)

9.3.6.3.3. Work Package (A.26)

9.3.7. Risk

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

9.3.7.2. controlled using management products such as ...

9.3.7.2.1. Risk Management Strategy (A.24)

9.3.7.2.2. Risk Registry (A.25)

9.3.7.2.3. Work Package (A.26)

9.3.7.3. What is the risk profile of the project?

9.3.8. Benefits

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

9.3.8.2. controlled using management products such as ...

9.3.8.2.1. Business Case (A.2)

9.3.8.2.2. Benefits Review Plan (A.1)

10. Project Management according to PRINCE2®

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

10.1.1. Maintaining control over the work of the specialist

10.1.2. Motivating people involved

10.1.3. Maintain current knowledge of the state of the project

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

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

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

10.2.1.1. Plan

10.2.1.1.1. Planning work to be done.

10.2.1.2. Delegate

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

10.2.1.3. Monitor

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

10.2.1.4. Control

10.2.1.4.1. Controlling the job by taking corrective actions.

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

10.3. Key benefits of adopting PRINCE2®

10.3.1. Applies to any type or project and business domain

10.3.1.1. Generic

10.3.2. License-free

10.3.2.1. Non-proprietary method

10.3.3. Widely recognized and understood

10.3.3.1. Common vocabulary and approach

10.3.4. Project security with EWIs and risk management

10.3.5. Embodies established and proven best practice and governance

10.3.5.1. Full project control/assurance

10.3.6. Provides for the explicit recognition of project responsibilities

10.3.6.1. Accountability with clearly defined roles

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

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

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

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

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

10.3.12. Promotes Learning and continual improvement

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

10.3.14. Facilitates team mobility

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

11. PRINCE2® structure

11.1. PRINCE2® method has 4 integrated elements

11.2. "Magic number 7"

11.2.1. 1. - 7 Principles

11.2.1.1. seven guiding rules / orders

11.2.2. 2. - 7 Themes

11.2.2.1. seven areas of project management knowledge

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

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

11.2.4. 4. Project Environment

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

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

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

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

11.3. What PRINCE2® does not provide?

11.3.1. Specialists aspects

11.3.2. Detailed techniques

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

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

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

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

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

11.3.3. Leadership capability

11.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®.

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

11.3.4. Soft-skills

11.3.5. Communication techniques

11.3.6. Human resource management

11.3.7. Contract negotiations

11.3.8. Software for project management

11.3.9. …

12. PRINCE2® Principles (7)

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

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

12.3. Principles are universally applicable statements.

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

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

12.3.3. Principles are self-validating and empowering.

12.3.4. They provide guidance to organizations.

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

12.3.6. The principles provide a framework of good practice.

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

12.4.1. Universal

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

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

12.4.2. Self-validating

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

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

12.4.3. Empowering

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

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

12.5. 1. Continued business justification

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

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

12.5.1.1.1. potrzebny

12.5.1.1.2. przydatny

12.5.1.1.3. wykonalny

12.5.2. Wymogiem dla projektu zgodnego z PRINCE2® jest:

12.5.2.1. Istnienie uzasadnionego powodu jego rozpoczecia.

12.5.2.1.1. tzw. "powody podjęcia projektu"

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

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

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

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

12.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)

12.5.3. Pryncypium wspierane przez:

12.5.3.1. Produkty Zarządcze

12.5.3.1.1. Uzasadnienie Biznesowe (A.2)

12.5.3.2. Role

12.5.3.2.1. Komitet Sterujący (KS)

12.5.3.2.2. Kierownik Projektu (KP)

12.6. 2. Learn from experience

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

12.6.2. Wymogiem dla projektu zgodnego z PRINCE2® jest:

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

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

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

12.6.3.1. na początku

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

12.6.3.2. w trakcie trwania

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

12.6.3.3. w czasie zamykania

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

12.6.4. Pryncypium wspierane przez:

12.6.4.1. Produkty Zarządcze

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

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

12.6.4.2. Role

12.6.4.2.1. Komitet Sterujący (KS)

12.6.4.2.2. Kierownik Projektu (KP)

12.7. 3. Defined roles and responsibilities

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

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

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

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

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

12.7.5. Pryncypium wspierane przez:

12.7.5.1. Produkty Zarządcze

12.7.5.1.1. Opis roli Przewodniczącego

12.7.5.1.2. Opis roli Kierownika Projekctu

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

12.7.5.1.4. Struktura zespołu zarządzania projektem

12.7.5.2. Role

12.7.5.2.1. Komitet Sterujący (KS)

12.7.5.2.2. Kierownik Projektu (KP)

12.8. 4. Manage by stages

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

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

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

12.8.3. Projekt posiada minimum dwa etapy zarządcze:

12.8.3.1. etap inicjowania

12.8.3.2. jeden lub więcej etapów realizacji

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

12.8.5. Pryncypium wspierane przez:

12.8.5.1. Produkty Zarządcze

12.8.5.1.1. Plan Etapu (A.16)

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

12.8.5.2. Role

12.8.5.2.1. Komitet Sterujący (KS)

12.8.5.2.2. Kierownik Projektu (KP)

12.9. 5. Manage by exception

12.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ń.

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

12.9.3. Pryncypium wspierane przez:

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

12.9.3.1.1. Parametry tolerancji wg. PRINCE2®:

12.9.3.2. Produkty Zarządcze

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

12.9.3.2.2. Plan Projektu (A.16)

12.9.3.2.3. Plan Etapu (A.16)

12.9.3.2.4. Grupa Zadań (A.26)

12.9.3.2.5. Uzasadnienie Biznesowe (A.2)

12.9.3.2.6. Opis Produktu (A.17)

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

12.9.3.3. Role

12.9.3.3.1. Komitet Sterujący (KS)

12.9.3.3.2. Kierownik Projektu (KP)

12.10. 6. Focus on products

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

12.10.2. Pryncypium wspierane przez:

12.10.2.1. Produkty Zarządcze

12.10.2.1.1. Opis Produktu (A.17)

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

12.10.2.2. Role

12.10.2.2.1. Komitet Sterujący (KS)

12.10.2.2.2. Kierownik Projektu (KP)

12.10.2.2.3. Kierownik Zespołu (KZ)

12.11. 7. Tailoring

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

12.11.2. Należy indywidualnie dostosować metodykę PRINCE2® do kazdego projektu.

12.11.2.1. Żaden projekt nie jest taki sam.

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

12.11.3. Pryncypium wspierane przez:

12.11.3.1. Produkty Zarządcze

12.11.3.1.1. Dokumentacja Inicjowanie Projektu (A.20)

12.11.3.2. Role

12.11.3.2.1. Komitet Sterujący (KS)

12.11.3.2.2. Kierownik Projektu (KP)

13. PRINCE2® Themes (7)

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

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

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

13.3. 1. Business Case

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

13.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?

13.3.2. Temat odpowiada na pytanie ...

13.3.2.1. Dlaczego?

13.3.2.1.1. Dlaczego projekt jest nam potrzebny?

13.3.2.1.2. Dlaczego powinniśmy rozpocząć projekt?

13.3.2.1.3. Dlaczego powinniśmy kontynuować projekt?

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

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

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

13.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ąć.

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

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

13.3.4.1.1. potrzebny

13.3.4.1.2. przydatny

13.3.4.1.3. wykonalny

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

13.3.5.1. 1. Opracowanie Uzasadnienia Biznesowego

13.3.5.2. 2. Weryfikowanie Uzasadnienia Biznesowego

13.3.5.3. 3. Utrzymywanie Uzasadnienia Biznesowego

13.3.5.4. 4. Potwierdzenie Uzasadnienia Biznesowego

13.4. 2. Organisation

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

13.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?

13.4.2. Temat odpowiada na pytanie ...

13.4.2.1. Kto?

13.4.2.1.1. Kto za co odpowiada w projekcie?

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

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

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

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

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

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

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

13.4.5.1.1. Zlecanie projektu

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

13.4.5.2. 2. Komitet Sterujący

13.4.5.2.1. Kierowanie projektem

13.4.5.2.2. Strategiczne zarządzanie projektem

13.4.5.3. 3. Kierownk Projekt

13.4.5.3.1. Operacyjne zarządzanie projektem

13.4.5.4. 4. Kierownicy Zespołów

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

13.4.6. Stakeholders

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

13.4.6.1.1. Project decision makers are stakeholders making decisions.

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

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

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

13.5. 3. Quality

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

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

13.5.2. Temat odpowiada na pytanie ...

13.5.2.1. Co?

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

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

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

13.5.4.1. spełniają oczekiwania biznesowe

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

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

13.5.5.1. Oczekiwania jakościowe klienta

13.5.5.2. Kryteria akceptacji

13.5.5.3. Opis Produktu Końcowego Projektu

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

13.5.5.5. Strategia Zarządzania Jakością

13.5.5.6. Opisy Produktów i kryteria jakości

13.5.5.7. Tolerancje jakości

13.5.5.8. Przegląd jakości (technika)

13.5.5.9. Rejestr Jakości

13.5.5.10. Zapisy zatwierdzeń

13.5.5.11. Zapisy akceptacji

13.6. 4. Plans

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

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

13.6.2. Temat odpowiada na pytanie ...

13.6.2.1. Jak? Za ile? Kiedy?

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

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

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

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

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

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

13.6.5.1. 1. Plan Projektu (obowiązkowy)

13.6.5.2. 2. Plan Etapu (obowiązkowy)

13.6.5.3. 3. Plan Zespołu (opcjonalny)

13.6.5.4. 4. Plan Nadzwyczajny

13.7. 5. Risk

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

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

13.7.2. Temat odpowiada na pytanie ...

13.7.2.1. Co, jeżeli?

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

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

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

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

13.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).

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

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

13.7.7. Cykl zarządzania ryzykiem składa się z kroków:

13.7.7.1. 1. Identyfikuj

13.7.7.1.1. dzieli się na dwa pod kroki

13.7.7.2. 2. Oceniaj

13.7.7.2.1. dzieli się na dwa pod kroki

13.7.7.3. 3. Planuj

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

13.7.7.4. 4. Wdrażaj

13.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ń,

13.7.7.5. Komunikacja

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

13.7.8. Parametry ryzyka w PRINCE2:

13.7.8.1. Prawdopodobieństwo

13.7.8.2. Bliskość

13.7.8.3. Wpływ

13.8. 6. Change

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

13.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?

13.8.2. Temat odpowiada na pytanie ...

13.8.2.1. Jaki jest wpływ?

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

13.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).

13.9. 7. Progress

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

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

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

13.9.3. Odpowiada na pytanie ...

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

13.9.3.1.1. Jak ocenić progres projektu?

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

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

14. PRINCE2® Processes (7)

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

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

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

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

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

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

14.3.2. Level 2 - Directing - Project Board

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

14.3.3. Level 3 - Managing - Project Manager

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

14.3.4. Level 4 - Delivering - Team Manager

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

14.4. Starting up a Project (SP)

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

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

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

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

14.4.3. Obecny w fazie przed projektowej

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

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

14.4.3.1.2. Są wytwarzane jedynie podstawowe produkty zarządcze

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

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

14.4.5. Egzamin Foundation

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

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

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

14.4.6. Praktyka

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

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

14.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)

14.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?"

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

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

14.4.7. Rekomendowane czynności w procesie

14.4.7.1. 1. Mianowanie Przewodniczącego i Kierownika Projektu

14.4.7.2. 2. Zgromadzenie dotychczasowych doświadczeń

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

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

14.4.7.5. 5. Przygotowanie zarysu Uzasadnienia Biznesowego

14.4.7.6. 6. Planowanie etapu inicjowania

14.5. Directing a Project (DP)

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

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

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

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

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

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

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

14.5.5. Rekomendowane czynności w procesie

14.5.5.1. Zezwalanie na zainicjowanie projektu

14.5.5.2. Zezwalanie na realizację projektu

14.5.5.3. Zezwalanie na realizację Planu Etapu lub Planu Nadzwyczajnego

14.5.5.4. Podejmowanie decyzji doraźnej

14.5.5.5. Zezwalanie na zamknięcie projektu

14.6. Initiating a Project (IP)

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

14.6.2. Obecny w Etapie Inicjowania

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

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

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

14.6.4. Rekomendowane czynności w procesie

14.6.4.1. Opracowanie Strategii Zarządzania Ryzykiem

14.6.4.2. Opracowanie Strategii Zarządzania Jakością

14.6.4.3. Opracowanie Strategii Zarządzania Konfiguracją

14.6.4.4. Opracowanie Strategii Zarządzania Komunikacją

14.6.4.5. Sporządzanie Planu Projektu

14.6.4.6. Ustanowienie mechanizmów sterowania projektem

14.6.4.7. Doprecyzowanie Uzasadnienia Biznesowego

14.6.4.8. Zestawianie Dokumentacji Inicjowania Projektu (DIP)

14.6.5. Egzamin Foundation

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

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

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

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

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

14.7. Controlling a Stage (CS)

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

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

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

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

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

14.7.4. Rekomendowane czynności w procesie

14.7.4.1. Zezwalanie na wykonanie Grupy Zadań

14.7.4.2. Przeglądanie stanu Grupy Zadań

14.7.4.3. Odbieranie zakończonych Grup Zadań

14.7.4.4. Przeglądanie stanu etapu

14.7.4.5. Podejmowanie działań korygujących

14.7.4.6. Wychwytywanie i badanie zagadnień i ryzyk

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

14.7.4.8. Raportowanie okresowe

14.8. Managing Product Delivery (MPD)

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

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

14.8.2.1. Praca Kierownika Zespołu (KZ)

14.8.3. Obecny w etapach realizacyjnych

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

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

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

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

14.8.5.1. ZATWIERDZENIA (nie mylić z akceptacją)

14.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)

14.8.6. Rekomendowane czynności w procesie

14.8.6.1. Przyjmowanie Grupy Zadań do wykonania

14.8.6.2. Wykonywanie Grupy Zadań

14.8.6.3. Oddawanie wykonanej Grupy Zadań

14.9. Managing a Stage Boundary (MSB)

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

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

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

14.9.2.1. Praca wykonywana głownie przez Kierownika Projektu

14.9.3. Rekomendowane czynności w procesie

14.9.3.1. Planowanie następnego etapu

14.9.3.2. Sporządzanie Planu Nadzwyczajnego

14.9.3.3. Uaktualnianie Planu Projektu

14.9.3.4. Uaktualnianie Uzasadnienia Biznesowego

14.9.3.5. Raportowanie zakończenia etapu

14.10. Closing a Project (CP)

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

14.10.1.1. W ostatnim, końcowym etapie projektu

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

14.10.2.1. Praca wykonywana głownie przez Kierownika Projektu

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

14.10.3.1. AKCEPTACJA (nie mylić z zatwierdzeniem)

14.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)

14.10.4. Rekomendowane czynności w procesie

14.10.4.1. Przygotowanie planowego zamknięcia

14.10.4.2. Przygotowanie przedwczesnego zamknięcia

14.10.4.3. Przekazanie produktów

14.10.4.4. Ocenianie projektu

14.10.4.5. Rekomendowanie zamknięcia projektu

15. PRINCE2® Roles (10)

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

15.2. Project Board (PB) (3)

15.2.1. represents 3 sides of intrests

15.2.1.1. clients side

15.2.1.1.1. Senior User(s)

15.2.1.2. business side

15.2.1.2.1. Executive

15.2.1.3. supplier side

15.2.1.3.1. Senior Supplier(s)

15.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ą

15.2.2.1. to sytuacja typowo teoretyczna, nieralna w praktyce

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

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

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

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

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

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

15.2.8.1. odpowiedzialny za "sukces projektu"

15.2.9. Dla wtajemniczonych ...

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

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

15.3. Project Assurance (PA) (3)

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

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

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

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

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

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

15.3.2.1.3. zagrożenia są kontrolowane

15.3.2.1.4. Uzasadnienie Biznesowe jest przestrzegane,

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

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

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

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

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

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

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

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

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

15.3.2.1.14. prowadzenie projektu jest nadal uzasadnione,

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

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

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

15.3.2.1.18. przestrzegane są wszystkie ograniczenia prawne,

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

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

15.3.2.1.21. ...

15.3.3. dzieli się na 3 strony

15.3.3.1. Nadzór ze strony biznesu

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

15.3.3.2. Nadzór ze strony dostawcy

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

15.3.3.3. Nadzór ze strony użytkownika

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

15.3.4. Rola wymagana, ale ...

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

15.4. Change Authority (CA)

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

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

15.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)

15.4.3. Rola wymagana, ale ...

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

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

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

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

15.4.4.1.1. Organizacja

15.4.4.1.2. K.S.

15.4.4.1.3. O.Z.

15.4.4.1.4. K.P.

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

15.5. Project Manager (PM)

15.5.1. Rola wymagana

15.5.2. Rola niepodzielna, zawsze 1 Kierownik Projektu

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

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

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

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

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

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

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

15.5.8. Odpowiedzialny ze osiągniecie CELÓW projektu (dostarczenie produktów specialistycznych)

15.5.8.1. CELÓW nie SUKCESU projektu

15.5.9. Dla wtajemniczonych ...

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

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

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

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

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

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

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

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

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

15.6. Team Manager(s) (TM)

15.6.1. Wytwarza produkty specjalistyczne

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

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

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

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

15.6.5. Przygotowuje Raporty z Punktów Kontrolnych

15.6.6. Rola wymagana, ale ...

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

15.6.7. Dla wtajemniczonych ...

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

15.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."

15.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!"

15.6.7.2. (miś) "A niech rzesz Pan siada i opowiada! Nowiny! Nowiny!"

15.7. Project Support (PS)

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

15.7.2. Rola wymagana, ale ...

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

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

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

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

16. Quality Review Roles (4)

16.1. chair

16.1.1. responsible for the overall conduct of the quality review

16.2. presenter

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

16.3. controller / reviewer

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

16.4. administrator

16.4.1. provides administrative support for the Chair

17. PRINCE2® Techniques (2)

17.1. Product-based planning technique

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

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

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

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

17.1.4.1. 1. Opis Produktu Końcowego Projektu,

17.1.4.2. 2. Diagram struktury produktów,

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

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

17.2. Quality review technique

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

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

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

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

17.2.2.1. chair

17.2.2.1.1. responsible for the overall conduct of the quality review

17.2.2.2. presenter

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

17.2.2.3. controller / reviewer

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

17.2.2.4. administrator

17.2.2.4.1. provides administrative support for the Chair

17.2.2.5. The remaining roles may be combined as needed

17.2.2.5.1. Najmniejsza forma to 2 osoby

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

17.2.3.1. 1. Quality review preparation

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

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

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

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

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

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

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

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

17.2.3.2. 2. Quality review meeting

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

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

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

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

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

17.2.3.2.6. 6. zaktualizowania Rejestru Jakości.

17.2.3.3. 3. Follow-up actions after the meeting

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

17.2.3.3.2. 2. zaplanowania wszelkich potrzebnych prac naprawczych,

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

17.2.3.3.4. 4. zaktualizowania Rejestru Jakości.

18. PRINCE2® Procedures (2)

18.1. Issue and change control procedure

18.1.1. 5 steps working sequentially

18.1.1.1. 1. Capture

18.1.1.2. 2. Examine

18.1.1.3. 3. Propose

18.1.1.4. 4. Decide

18.1.1.5. 5. Implement

18.2. Configuration management procedure

18.2.1. 5 steps working sequentially

18.2.1.1. 1. Planning

18.2.1.2. 2. Identification

18.2.1.3. 3. Control

18.2.1.4. 4. Status accounting

18.2.1.5. 5. Verification and audit (configuration)

19. PRINCE2® Management products (26)

19.1. Baseline

19.1.1. a.k.a. "PRINCE2® base"

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

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

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

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

19.1.4.1. Rekomendowana zawartość

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

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

19.1.4.1.3. Sposoby i terminy pomiaru oczekiwanych korzyści.

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

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

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

19.1.5. A.2 Uzasadnienie Biznesowe

19.1.5.1. Rekomendowana zawartość

19.1.5.1.1. Podsumowanie

19.1.5.1.2. Powody podjęcia projektu

19.1.5.1.3. Możliwe rozwiązania biznesowe

19.1.5.1.4. Oczekiwane korzyści

19.1.5.1.5. Przewidywane niepożądane skutki

19.1.5.1.6. Terminy

19.1.5.1.7. Koszty

19.1.5.1.8. Ocena inwestycji

19.1.5.1.9. Główne ryzyka

19.1.6. A.4 Strategia Zarządzania Komunikacją

19.1.6.1. Rekomendowana zawartość

19.1.6.1.1. Wprowadzenie

19.1.6.1.2. Procedura komunikacji

19.1.6.1.3. Narzędzia i techniki

19.1.6.1.4. Wymagane zapisy

19.1.6.1.5. Raportowanie

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

19.1.6.1.7. Role i ich obowiązki

19.1.6.1.8. Analiza interesariuszy

19.1.6.1.9. Potrzeby informacyjne każdej z zainteresowanych stron

19.1.7. A.6 Strategia Zarządzania Konfiguracją

19.1.7.1. Rekomendowana zawartość

19.1.7.1.1. Wprowadzenie

19.1.7.1.2. Procedura zarządzania konfiguracją

19.1.7.1.3. Procedura obsługi zagadnień i sterowania zmianami

19.1.7.1.4. Narzędzia i techniki

19.1.7.1.5. Wymagane zapisy

19.1.7.1.6. Raportowanie

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

19.1.7.1.8. Role i ich obowiązki

19.1.7.1.9. Skala ocen priorytetu i wagi

19.1.8. A.16 Plan

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

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

19.1.8.1.2. poziom projektu i etapu zarazem

19.1.8.1.3. 3. poziom dostarczania produktów specjalistycznych

19.1.8.2. Rekomendowana zawartość

19.1.8.2.1. Opis planu

19.1.8.2.2. Warunki wstępne dla planu

19.1.8.2.3. Zależności zewnętrzne

19.1.8.2.4. Założenia planistyczne

19.1.8.2.5. Uwzględnione doświadczenia

19.1.8.2.6. Monitorowanie i kontrola

19.1.8.2.7. Budżety

19.1.8.2.8. Tolerancje

19.1.8.2.9. Opisy produktów (A.17)

19.1.8.2.10. Harmonogram

19.1.9. A.17 Opis Produktu

19.1.9.1. Rekomendowana zawartość

19.1.9.1.1. Identyfikator

19.1.9.1.2. Nazwa

19.1.9.1.3. Przeznaczenie

19.1.9.1.4. Zawartość/Skład

19.1.9.1.5. Pochodzenie

19.1.9.1.6. Wymagany format i sposób przedstawienia

19.1.9.1.7. Wymagane umiejętności wytwórcy

19.1.9.1.8. Kryteria jakości

19.1.9.1.9. Tolerancja jakości

19.1.9.1.10. Metoda kontroli jakości

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

19.1.9.1.12. Obowiązki dotyczące jakości

19.1.10. A.19 Założenia Projektu

19.1.10.1. Rekomendowana zawartość

19.1.10.1.1. Definicja projektu

19.1.10.1.2. Zarys Uzasadnienia Biznesowego

19.1.10.1.3. Opis Produktu Końcowego Projektu

19.1.10.1.4. Formuła realizacji projektu

19.1.10.1.5. Struktura zespołu zarządzania projektem

19.1.10.1.6. Opisy ról

19.1.10.1.7. Odniesienia

19.1.11. A.20 Dokumentacja Inicjowania Projektu (DIP)

19.1.11.1. Rekomendowana zawartość

19.1.11.1.1. Definicja projektu

19.1.11.1.2. Formuła realizacji projektu

19.1.11.1.3. Uzasadnienie Biznesowe

19.1.11.1.4. Struktura zespołu zarządzania projektem

19.1.11.1.5. Opisy ról

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

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

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

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

19.1.11.1.10. Plan Projektu (A.16)

19.1.11.1.11. Mechanizmy sterowania

19.1.11.1.12. Dostosowanie metodyki PRINCE2

19.1.12. A.21 Opis Produktu Końcowego Projektu

19.1.12.1. Rekomendowana zawartość

19.1.12.1.1. Nazwa

19.1.12.1.2. Przeznaczenie

19.1.12.1.3. Zawartość/skład

19.1.12.1.4. Pochodzenie

19.1.12.1.5. Wymagane umiejętności wytwórcy

19.1.12.1.6. Oczekiwania jakościowe klienta

19.1.12.1.7. Kryteria akceptacji

19.1.12.1.8. Tolerancje projektu

19.1.12.1.9. Metoda akceptacji

19.1.12.1.10. Obowiązki dotyczące akceptacji

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

19.1.13.1. Rekomendowana zawartość

19.1.13.1.1. Wprowadzenie

19.1.13.1.2. Procedura zarządzania jakością

19.1.13.1.3. Narzędzia i techniki

19.1.13.1.4. Wymagane zapisy

19.1.13.1.5. Raportowanie

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

19.1.13.1.7. Role i obowiązki

19.1.14. A.24 Strategia Zarządzania Ryzykiem

19.1.14.1. Rekomendowana zawartość

19.1.14.1.1. Wprowadzenie

19.1.14.1.2. Procedura zarządzania ryzykiem

19.1.14.1.3. Narzędzia i techniki

19.1.14.1.4. Wymagane zapisy

19.1.14.1.5. Raportowanie

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

19.1.14.1.7. Role i obowiązki

19.1.14.1.8. Skale ocen

19.1.14.1.9. Bliskość

19.1.14.1.10. Kategorie ryzyka

19.1.14.1.11. Kategorie reakcji na ryzyko

19.1.14.1.12. Wskaźniki wczesnego ostrzegania

19.1.14.1.13. Tolerancja ryzyka

19.1.14.1.14. Budżet ryzyka

19.1.15. A.26 Grupa Zadań

19.1.15.1. Rekomendowana zawartość

19.1.15.1.1. Data

19.1.15.1.2. Kierownik Zespołu lub osoba upoważniona

19.1.15.1.3. Opis Grupy Zadań

19.1.15.1.4. Techniki, procesy i procedury

19.1.15.1.5. Punkty styku (interfejsy) w okresie wytwarzania

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

19.1.15.1.7. Wymagania zarządzania konfiguracją

19.1.15.1.8. Uzgodnienia

19.1.15.1.9. Tolerancje

19.1.15.1.10. Ograniczenia

19.1.15.1.11. Uzgodnienia dotyczące raportowania

19.1.15.1.12. Sposoby obsługi i przekazywania problemów

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

19.1.15.1.14. Metoda zatwierdzenia (odbioru) wykonanej Grupy Zadań

19.2. Records

19.2.1. a.k.a. "PRINCE2® dynamic"

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

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

19.2.4. A.5 Zapisy Obiektu Konfiguracji

19.2.4.1. Rekomendowana zawartość

19.2.4.1.1. Identyfikator projektu

19.2.4.1.2. Identyfikator obiektu

19.2.4.1.3. Aktualna wersja

19.2.4.1.4. Nazwa obiektu

19.2.4.1.5. Data ostatniej zmiany statusu

19.2.4.1.6. Docelowy właściciel produktu

19.2.4.1.7. Miejsce przechowywania

19.2.4.1.8. Aktualni posiadacze

19.2.4.1.9. Rodzaj obiektu

19.2.4.1.10. Cechy obiektu

19.2.4.1.11. Etap

19.2.4.1.12. Użytkownicy

19.2.4.1.13. Status

19.2.4.1.14. Stadium produktu

19.2.4.1.15. Wariant

19.2.4.1.16. Wytwórca/producent

19.2.4.1.17. Data przydzielenia wytwórcy

19.2.4.1.18. Pochodzenie produktu

19.2.4.1.19. Związek z innymi produktami

19.2.4.1.20. Powiązania

19.2.5. A.7 Dziennik Projektu

19.2.5.1. Rekomendowana zawartość

19.2.5.1.1. Data wpisu.

19.2.5.1.2. Problem, działanie, zdarzenie lub komentarz

19.2.5.1.3. Osoba odpowiedzialna

19.2.5.1.4. Wyznaczony termin

19.2.5.1.5. Rezultaty

19.2.6. A.12 Rejestr Zagadnień

19.2.6.1. Rekomendowana zawartość

19.2.6.1.1. Identyfikator zagadnienia

19.2.6.1.2. Typ zagadnienia

19.2.6.1.3. Data zgłoszenia

19.2.6.1.4. Zgłoszone przez

19.2.6.1.5. Autor Raportu o Zagadnieniu

19.2.6.1.6. Opis zagadnienia

19.2.6.1.7. Priorytet

19.2.6.1.8. Waga/znaczenie

19.2.6.1.9. Status

19.2.6.1.10. Data zamknięcia

19.2.7. A.14 Dziennik Doświadczeń

19.2.7.1. Rekomendowana zawartość

19.2.7.1.1. Typ doświadczenia

19.2.7.1.2. Opis doświadczenia

19.2.7.1.3. Data wpisu

19.2.7.1.4. Wpisane przez

19.2.7.1.5. Priorytet

19.2.8. A.23 Rejestr Jakości

19.2.8.1. Rekomendowana zawartość

19.2.8.1.1. Numer wpisu

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

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

19.2.8.1.4. Metoda

19.2.8.1.5. Role i obowiązki

19.2.8.1.6. Terminy

19.2.8.1.7. Wynik

19.2.8.1.8. Zapisy jakości

19.2.9. A.25 Rejestr Ryzyk

19.2.9.1. Rekomendowana zawartość

19.2.9.1.1. Identyfikator ryzyka

19.2.9.1.2. Autor zgłoszenia

19.2.9.1.3. Data zarejestrowania

19.2.9.1.4. Kategoria ryzyka

19.2.9.1.5. Opis ryzyka

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

19.2.9.1.7. Bliskość ryzyka

19.2.9.1.8. Kategorie reakcji na ryzyko

19.2.9.1.9. Proponowane reakcje na ryzyko

19.2.9.1.10. Status ryzyka

19.2.9.1.11. Właściciel ryzyka

19.2.9.1.12. Wykonawca reakcji na ryzyko

19.3. Reports

19.3.1. a.k.a. "PRINCE2® static"

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

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

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

19.3.4. A.3 Raport z Punktu Kontrolnego

19.3.4.1. Rekomendowana zawartość

19.3.4.1.1. Data opracowania

19.3.4.1.2. Okres sprawozdawczy

19.3.4.1.3. Wykonanie wcześniej zleconych czynności

19.3.4.1.4. Bieżący okres sprawozdawczy

19.3.4.1.5. Następny okres sprawozdawczy

19.3.4.1.6. Stan tolerancji Grupy Zadań

19.3.4.1.7. Zagadnienia i ryzyka

19.3.5. A.8 Raport Końcowy Projektu

19.3.5.1. Rekomendowana zawartość

19.3.5.1.1. Sprawozdanie Kierownika Projektu

19.3.5.1.2. Przegląd Uzasadnienia Biznesowego

19.3.5.1.3. Przegląd realizacji celów projektu

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

19.3.5.1.5. Przegląd produktów

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

19.3.6. A.9 Raport Końcowy Etapu

19.3.6.1. Rekomendowana zawartość

19.3.6.1.1. Sprawozdanie Kierownika Projektu

19.3.6.1.2. Przegląd Uzasadnienia Biznesowego

19.3.6.1.3. Przegląd realizacji celów projektu

19.3.6.1.4. Przegląd realizacji celów etapu

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

19.3.6.1.6. Przegląd produktów

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

19.3.6.1.8. Zagadnienia i ryzyka

19.3.6.1.9. Prognoza

19.3.7. A.10 Raport Nadzywczajny

19.3.7.1. Rekomendowana zawartość

19.3.7.1.1. Opis sytuacji nadzwyczajnej

19.3.7.1.2. Przyczyna wystąpienia

19.3.7.1.3. Skutki odchylenia

19.3.7.1.4. Możliwe reakcje

19.3.7.1.5. Rekomendacja

19.3.7.1.6. Doświadczenia

19.3.8. A.11 Raport Okresowy

19.3.8.1. Rekomendowana zawartość

19.3.8.1.1. Data opracowania

19.3.8.1.2. Okres sprawozdawczy

19.3.8.1.3. Sumaryczny opis stanu etapu

19.3.8.1.4. Bieżący okres sprawozdawczy

19.3.8.1.5. Następny okres sprawozdawczy

19.3.8.1.6. Stan tolerancji projektu i etapu

19.3.8.1.7. Wnioski o wprowadzenie zmiany

19.3.8.1.8. Główne zagadnienia i ryzyka

19.3.8.1.9. Raport Doświadczeń

19.3.9. A.13 Raport o Zagadnieniu

19.3.9.1. Rekomendowana zawartość

19.3.9.1.1. Identyfikator zagadnienia

19.3.9.1.2. Typ zagadnienia

19.3.9.1.3. Data zgłoszenia

19.3.9.1.4. Zgłoszone przez

19.3.9.1.5. Autor Raportu o Zagadnieniu

19.3.9.1.6. Opis zagadnienia

19.3.9.1.7. Analiza wpływu

19.3.9.1.8. Rekomendacja

19.3.9.1.9. Priorytet

19.3.9.2. Egzamin Foundation

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

19.3.10. A.15 Raport Doświadczeń

19.3.10.1. Rekomendowana zawartość

19.3.10.1.1. Podsumowanie

19.3.10.1.2. Zakres raportu (np. etap lub projekt)

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

19.3.10.1.4. Przegląd użytecznych miar

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

19.3.10.2. Egzamin Foundation

19.3.10.2.1. Raport Doświadczeń NIE Doświadczenia

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

19.3.11.1. Rekomendowana zawartość

19.3.11.1.1. Zakres raportu

19.3.11.1.2. Data wytworzenia

19.3.11.1.3. Status produktów

19.3.11.2. Egzamin Foundation

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

19.4. Praktyka

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

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