Your SlideShare is downloading. ×
Prince2 practioner abstract
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Prince2 practioner abstract

579
views

Published on

Prince 2 Practioner Abstract I used to study

Prince 2 Practioner Abstract I used to study

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
579
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
85
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. PRINCE2 PRINCE2 A SUMMARYPRINCE2pracWeb.doc Page i
  • 2. PRINCE2DOCUMENT HISTORY Version Date Author Notes 0.1 25-02-2006 Anne Plancius First draftPRINCE2pracWeb.doc Page ii
  • 3. PRINCE2TABLE OF CONTENTS0. PERSONAL NOTE .................................................................................................................... 81. PRINCE2 TERMINOLOGY ...................................................................................................... 92. AN INTRODUCTION TO PRINCE2 ..................................................................................... 10 2.1. Starting up a Project (SU) .................................................................................................... 10 2.2. Directing a project (DP) ...................................................................................................... 11 2.3. Initiating a project (IP) ........................................................................................................ 11 2.4. Managing stage boundaries (SB) ........................................................................................ 11 2.5. Controlling a stage (CS) ....................................................................................................... 11 2.6. Managing product delivery (MP) ........................................................................................ 11 2.7. Closing a project (CP) .......................................................................................................... 12 2.8. Planning ................................................................................................................................ 12 2.9. The components................................................................................................................... 12 2.9.1. Business Case........................................................................................................................................... 12 2.9.2. Organization ............................................................................................................................................ 12 2.9.3. Plans .......................................................................................................................................................... 13 2.9.4. Controls .................................................................................................................................................... 13 2.9.5. Management of Risk............................................................................................................................... 13 2.9.6. Quality in a project environment ......................................................................................................... 13 2.9.7. Configuration Management .................................................................................................................. 13 2.9.8. Change control ........................................................................................................................................ 13 2.10. The techniques ................................................................................................................... 133. STARTING UP A PROJECT (SU)............................................................................................ 14 3.1. Appointing an Executive and a Project Manager (SU1) ..................................................... 14 3.1.1. Objective .................................................................................................................................................. 14 3.1.2. Responsibilities........................................................................................................................................ 14 3.2. Designing a project management team (SU2) ................................................................... 14 3.2.1. Objective .................................................................................................................................................. 15 3.2.2. Responsibilities........................................................................................................................................ 15 3.3. Appointing a Project Management Team (SU3) ............................................................... 15 3.3.1. Objective .................................................................................................................................................. 15 3.3.2. Responsibilities........................................................................................................................................ 15 3.4. Preparing a Project Brief (SU4) ........................................................................................... 15 3.4.1. Objective .................................................................................................................................................. 15 3.4.2. Responsibilities........................................................................................................................................ 15 3.5. Defining a Project Approach (SU5)..................................................................................... 16 3.5.1. Objective .................................................................................................................................................. 16 3.5.2. Responsibilities........................................................................................................................................ 16 3.6. Planning an Initiation Stage (SU6) ..................................................................................... 16 3.6.1. Objective .................................................................................................................................................. 16 3.6.2. Responsibilities........................................................................................................................................ 16 3.7. Input and output .................................................................................................................. 174. INITIATING A PROJECT (IP) ................................................................................................ 18 4.1. Planning quality (IP1) .......................................................................................................... 18 4.1.1. Objective .................................................................................................................................................. 18 4.1.2. Responsibilities........................................................................................................................................ 18 4.2. Planning a project (IP2) ....................................................................................................... 19 4.2.1. Objective .................................................................................................................................................. 19 4.2.2. Responsibilities........................................................................................................................................ 19PRINCE2pracWeb.doc Page iii
  • 4. PRINCE2 4.3. Refining the Business Case and risks (IP3) ........................................................................ 19 4.3.1. Objective .................................................................................................................................................. 19 4.3.2. Responsibilities........................................................................................................................................ 19 4.4. Setting up Project Control (IP4) .......................................................................................... 19 4.4.1. Objective .................................................................................................................................................. 19 4.4.2. Responsibilities........................................................................................................................................ 20 4.5. Setting up the Project Files (IP5) ........................................................................................20 4.5.1. Objective .................................................................................................................................................. 20 4.5.2. Responsibilities........................................................................................................................................ 20 4.6. Assembling a Project Initiation Document (IP6) ...............................................................20 4.6.1. Objective .................................................................................................................................................. 20 4.6.2. Responsibilities........................................................................................................................................ 20 4.7. Input and output .................................................................................................................. 215. DIRECTING A PROJECT (DP) ...............................................................................................22 5.1. Authorizing Initiation (DP1) ................................................................................................22 5.1.1. Objective .................................................................................................................................................. 22 5.1.2. Responsibilities........................................................................................................................................ 22 5.2. Authorizing a project (DP2) ................................................................................................22 5.2.1. Objective .................................................................................................................................................. 23 5.2.2. Responsibilities........................................................................................................................................ 23 5.3. Authorizing a Stage or Exception Plan (DP3) ....................................................................23 5.3.1. Objective .................................................................................................................................................. 23 5.3.2. Responsibilities........................................................................................................................................ 23 5.4. Giving ad hoc direction (DP4) .............................................................................................23 5.4.1. Objective .................................................................................................................................................. 23 5.4.2. Responsibilities........................................................................................................................................ 23 5.5. Confirming Project Closure (DP5) ......................................................................................23 5.5.1. Objective .................................................................................................................................................. 23 5.5.2. Responsibilities........................................................................................................................................ 24 5.6. Input and output ..................................................................................................................256. CONTROLLING A STAGE (CS) .............................................................................................26 6.1. Authorizing Work Package (CS1) ........................................................................................26 6.1.1. Objective .................................................................................................................................................. 26 6.1.2. Responsibilities........................................................................................................................................ 27 6.2. Assessing progress (CS2) .....................................................................................................27 6.2.1. Objective .................................................................................................................................................. 27 6.2.2. Responsibilities........................................................................................................................................ 27 6.3. Capturing Project Issues (CS3) ...........................................................................................27 6.3.1. Objective .................................................................................................................................................. 27 6.3.2. Responsibilities........................................................................................................................................ 27 6.4. Examining Project issues (CS4) ..........................................................................................27 6.4.1. Objective .................................................................................................................................................. 27 6.4.2. Responsibilities........................................................................................................................................ 27 6.5. Reviewing stage status (CS5)...............................................................................................28 6.5.1. Objective .................................................................................................................................................. 28 6.5.2. Responsibilities........................................................................................................................................ 28 6.6. Reporting Highlights (CS6) .................................................................................................28 6.6.1. Objective .................................................................................................................................................. 28 6.6.2. Responsibilities........................................................................................................................................ 28 6.7. Taking corrective action (CS7) ............................................................................................28 6.7.1. Objective .................................................................................................................................................. 28 6.7.2. Responsibilities........................................................................................................................................ 29 6.8. Escalating project issues (CS8) ...........................................................................................29PRINCE2pracWeb.doc Page iv
  • 5. PRINCE2 6.8.1. Objective .................................................................................................................................................. 29 6.8.2. Responsibilities........................................................................................................................................ 29 6.9. Receiving completed work package (CS9) .........................................................................29 6.9.1. Objective .................................................................................................................................................. 29 6.9.2. Responsibilities........................................................................................................................................ 29 6.10. Input and output .................................................................................................................307. MANAGING PRODUCT DELIVERY (MP) ...........................................................................32 7.1. Accepting a Work Package (MP1) .......................................................................................32 7.1.1. Objective .................................................................................................................................................. 32 7.1.2. Responsibilities........................................................................................................................................ 32 7.2. Executing a Work Package (MP2) ......................................................................................32 7.2.1. Objective .................................................................................................................................................. 32 7.2.2. Responsibilities........................................................................................................................................ 33 7.3. Delivering a Work Package (MP3) ......................................................................................33 7.3.1. Objective .................................................................................................................................................. 33 7.3.2. Responsibilities........................................................................................................................................ 33 7.4. Input and output ..................................................................................................................338. MANAGING STAGE BOUNDARIES (SB) .............................................................................34 8.1. Planning a Stage (SB1) .........................................................................................................34 8.1.1. Objective .................................................................................................................................................. 34 8.1.2. Responsibilities........................................................................................................................................ 34 8.2. Updating a Project Plan (SB2) .............................................................................................34 8.2.1. Objective .................................................................................................................................................. 34 8.2.2. Responsibilities........................................................................................................................................ 35 8.3. Updating a Project Business Case (SB3) ............................................................................35 8.3.1. Objectives ................................................................................................................................................ 35 8.3.2. Responsibilities........................................................................................................................................ 35 8.4. Updating the Risk Log (SB4) ..............................................................................................35 8.4.1. Objectives ................................................................................................................................................ 35 8.4.2. Responsibilities........................................................................................................................................ 35 8.5. Reporting Stage End (SB5)..................................................................................................35 8.5.1. Objective .................................................................................................................................................. 35 8.5.2. Responsibilities........................................................................................................................................ 35 8.6. Producing an Exception Plan (SB6) ...................................................................................36 8.6.1. Objective .................................................................................................................................................. 36 8.6.2. Responsibilities........................................................................................................................................ 36 8.7. Input and output ..................................................................................................................379. CLOSING A PROJECT (CP) ....................................................................................................38 9.1. Decommissioning a Project (CP1).......................................................................................38 9.1.1. Objective .................................................................................................................................................. 38 9.1.2. Responsibilities........................................................................................................................................ 39 9.2. Identifying Follow-on Actions (CP2) ..................................................................................39 9.2.1. Objectives ................................................................................................................................................ 39 9.2.2. Responsibilities........................................................................................................................................ 39 9.3. Evaluating a Project (CP3) ..................................................................................................39 9.3.1. Objective .................................................................................................................................................. 39 9.3.2. Responsibilities........................................................................................................................................ 39 9.4. Input and output ..................................................................................................................4010. PLANNING .............................................................................................................................. 41 10.1. Designing a Plan (PL1)....................................................................................................... 41 10.1.1. Objective ................................................................................................................................................ 41PRINCE2pracWeb.doc Page v
  • 6. PRINCE2 10.1.2. Responsibilities...................................................................................................................................... 41 10.2. Defining and Analyzing Products (PL2) ...........................................................................42 10.2.1. Objective ................................................................................................................................................ 42 10.2.2. Responsibilities...................................................................................................................................... 42 10.3. Identifying Activities and Dependencies (PL3) ................................................................42 10.3.1. Objective ................................................................................................................................................ 42 10.3.2. Responsibilities...................................................................................................................................... 42 10.4. Estimating (PL4) ................................................................................................................42 10.4.1. Objective ................................................................................................................................................ 42 10.4.2. Responsibilities...................................................................................................................................... 42 10.5. Scheduling (PL5) ................................................................................................................43 10.5.1. Objectives .............................................................................................................................................. 43 10.5.2. Responsibilities...................................................................................................................................... 43 10.6. Analyze Risks (PL6) ...........................................................................................................43 10.6.1. Objective ................................................................................................................................................ 43 10.6.2. Responsibilities...................................................................................................................................... 43 10.7. Completing a Plan (PL) .....................................................................................................43 10.7.1. Objective ................................................................................................................................................ 43 10.7.2. Responsibilities...................................................................................................................................... 43 10.8. Input and output .................................................................................................................4411. THE COMPONENTS..............................................................................................................45 11.1. Business Case ......................................................................................................................45 11.2. Organization .......................................................................................................................45 11.2.1. Business .................................................................................................................................................. 46 11.2.2. User ......................................................................................................................................................... 46 11.2.3. Supplier................................................................................................................................................... 46 11.2.4. The project board ................................................................................................................................. 46 11.2.4.1. Executive ............................................................................................................................................ 47 11.2.4.2. Senior User ......................................................................................................................................... 47 11.2.4.3. Senior Supplier ................................................................................................................................... 47 11.2.5. Project Manager .................................................................................................................................... 47 11.2.6. Team Manager....................................................................................................................................... 47 11.2.7. Project Assurance ................................................................................................................................. 47 11.2.8. Project Support ..................................................................................................................................... 48 11.3. Plans ....................................................................................................................................48 11.3.1. Project Plan............................................................................................................................................ 48 11.3.2. Stage Plan ............................................................................................................................................... 49 11.3.3. Team Plan .............................................................................................................................................. 49 11.3.4. Stage and team quality plans ............................................................................................................... 49 11.3.5. Exception plan ...................................................................................................................................... 49 11.4. Controls ...............................................................................................................................49 11.4.1. Tolerance................................................................................................................................................ 51 11.4.2. Product description .............................................................................................................................. 51 11.4.3. Work Package........................................................................................................................................ 51 11.4.4. Quality Log ............................................................................................................................................ 51 11.4.5. Project issues and change control ...................................................................................................... 52 11.4.6. Risk Log ................................................................................................................................................. 52 11.4.7. Checkpoint............................................................................................................................................. 52 11.4.8. Highlight Report ................................................................................................................................... 52 11.4.9. Exception report ................................................................................................................................... 52 11.4.10. End stage assessment ......................................................................................................................... 52 11.4.11. End Stage report ................................................................................................................................. 52 11.4.12. Daily Log ............................................................................................................................................. 53 11.4.13. Lessons Learned Log ......................................................................................................................... 53PRINCE2pracWeb.doc Page vi
  • 7. PRINCE2 11.4.14. Controlled Close ................................................................................................................................. 53 11.4.15. Project closure notification ............................................................................................................... 53 11.4.16. Lesson Learned report ....................................................................................................................... 53 11.4.17. Follow on Action recommendations............................................................................................... 53 11.4.18. End project report .............................................................................................................................. 53 11.4.19. Post Project Review plan................................................................................................................... 53 11.4.20. Stages .................................................................................................................................................... 53 11.4.21. Review and decision points............................................................................................................... 53 11.4.22. Planning horizons ............................................................................................................................... 54 11.4.23. Management versus technical stages ............................................................................................... 54 11.4.23.1. How to define stages ...................................................................................................................... 54 11.4.23.2. How to use stages............................................................................................................................ 54 11.5. Management of risk ............................................................................................................54 11.5.1. Risk tolerance ........................................................................................................................................ 54 11.5.2. Risk responsibilities .............................................................................................................................. 54 11.5.3. Risk ownership ...................................................................................................................................... 55 11.5.4. The risk management cycle ................................................................................................................. 55 11.5.4.1. Identify the risks ................................................................................................................................ 55 11.5.4.2. Evaluate the risks............................................................................................................................... 56 11.5.4.3. Identify suitable responses to risk................................................................................................... 56 11.5.4.4. Select .................................................................................................................................................... 56 11.5.4.5. Plan and Resource ............................................................................................................................. 56 11.5.4.6. Monitor and report............................................................................................................................ 57 11.6. Quality in a project environment .......................................................................................58 11.7. Configuration Management ...............................................................................................58 11.8. Change control ....................................................................................................................59PRINCE2pracWeb.doc Page vii
  • 8. PRINCE20. PERSONAL NOTEThis document is a summary based on: „Managing Successful Projects with Prince2‟. This summary ispurely intended for me personally but might help others. This reason for this abstract is my Prince2Practioner exam.PRINCE2pracWeb.doc Page 8
  • 9. PRINCE21. PRINCE2 TERMINOLOGYBusiness Case: Business Case is used to define the information that justifies the setting u, continuation ortermination of the project. It answers the question: ”Why should this project be done?” It is updated atkey points throughout the project.Customer: Customer is used to represent the person or group who has commissioned the work and willbe benefiting from the end results.Products: Product is used to describe everything that the project has to create or change, howeverphysical or otherwise this may be. Results of projects can vary enormously from physical items, such asbuildings and machinery, to intangible things such as culture change and public perception.Programme: Programme is a collection of projects that together achieve a beneficial change for anorganization.Supplier: Supplier is used to mean the group that is providing specialist resources and skills to the projector is provisioning goods and services to create the project outcome required by the customer and user.User: User is defined as the person or group who will use or operate the final product. In some situationsthe customer and user may be the same group.PRINCE2pracWeb.doc Page 9
  • 10. PRINCE22. AN INTRODUCTION TO PRINCE2Prince2 defines a project as: A management environment that is created for the purpose of delivering oneor more business products according to a specified Business Case.A Prince2 project has the following characteristics:  A finite and a defined lifecycle  Defined and measurable business products  A corresponding set of activities to achieve the business products  Defined amount of resources  An organization structure, with defined responsibilities to manage the project.Prince2 covers the management of the project and the management of resources involved in carrying outthe activities of the project. It does not cover the specialists techniques involved in the creation of theproducts. Directing a project DP4 DP1 DP2 DP3 DP5 Starting up a Initiating a project Managing stage boundaries project Controlling a Closing a project stage Planning Managing product delivery2.1. Starting up a Project (SU)It is a pre-project process, designed to ensure that the prerequisites for initiating the project are in place.The process expects the existence of a Project Mandate that defines in high level terms the reason for theproject and what product is required. The work of the process is built around the establishment of seventhings:  The design and, as far as possible, appointment of the project management team.  The project brief  The project approach (in general terms how a solution will be provided)  The customer‟s quality‟s expectations  A risk logPRINCE2pracWeb.doc Page 10
  • 11. PRINCE2  An outline Business Case  The initiation stage planThe Daily Log is opened here for the Project Manager‟s use throughout the project.2.2. Directing a project (DP)Directing a Project runs from Starting up a Project (SU) until the project‟s closure.This process is aimed at the Project Board. The Project Board manages by exception, monitors viareports and controls through a number of decision points.The key processes for the Project Board break into five main areas:  Authorizing initiation  Authorizing a project  Stage boundaries  Ad hoc direction  Project closure2.3. Initiating a project (IP)The objectives of Initiating a Project are to:  Define how the required product quality will be achieved  Plan and cost the project  Revise the Business Case and confirm that an acceptable Business Case exists for the project  Ensure that the investment of time and effort required by the project is justified, taking account of the risks to the project  Enable and encourage the Project Board to take ownership of the project and agree to the commitment of the resources for the next stage  Provide the baseline for the decision-making processes required during the project‟s life.2.4. Managing stage boundaries (SB)The objectives of this process are to:  Assure the Project Board that all products planned in the current Stage Plan have been completed as defined  Provide the information needed for the Project Board to assess the continuing viability of the project  Provide the Project Board with any other information needed to approve the current stage‟s completion and authorize the start of the next stage, together with its delegated tolerance level  Record any measurements or lessons that can help later stages of this project and/or other projects.2.5. Controlling a stage (CS)A project may have many stages. This process describes the monitoring and control activities of theProject Manager involved in allocating work, ensuring that a stage stays on course and reacting tounexpected events. The process forms the core of the Project Manager‟s effort on the project, being theprocess that handles day-to-day management of the project.2.6. Managing product delivery (MP)The objective of this process is to ensure that planned products are created and delivered by the projectby:  The team manager negotiating details of Work Packages with the project managerPRINCE2pracWeb.doc Page 11
  • 12. PRINCE2  Making certain that work on products allocated to the team is effectively authorized and agreed  Ensuring that work conforms to the requirements of interfaces identified in the Work Package  Ensuring that the work is done  Assessing work progress and forecasts regularly  Ensuring that completed products meet quality criteria  Obtaining approval for the completed products2.7. Closing a project (CP)The purpose of this process is to execute a controlled close to the project. The objectives of closing aproject are to:  Check the extent to which the objectives or aims set out in the Project Initiation Document have been met  Assess to what extent all expected products have been handed over and accepted by the customer  Confirm that maintenance and operation arrangements are in place including relevant training  Capture lessons resulting from the project and complete the lessons learned report  Prepare an End Project Report  Archive the project files  Produce a Post-Project Review Plan  Prepare a recommendation to the Project Board to notify the host organization of the intention to disband the project organization and release the resources2.8. PlanningPlanning is a repeatable process and plays an important role in other processes, the main ones being:  Planning an Initiation Stage (SU6)  Planning a Project (IP2)  Planning a Stage (SB1)  Updating a Project Plan (SB2)  Accepting a Work Package (MP1)  Producing an Exception Plan (SB6)Apart from a plan the process produces:  A product checklist, which is a table of the products to be produced by the work planned, with space for planned and actual dates for the delivery of draft, quality-checked and approved products.  The risk log, updated with any risk situation changes made as a result of the planning activity.2.9. The components2.9.1. Business CaseThe existence of a viable Business Case is the main control condition of a Prince2 project. The BusinessCase is verified by the Project Board before a Project begins and at every major decision point throughoutthe project. The project should be stopped if the viability of the Business Case disappears for any reasons.2.9.2. OrganizationPrince2 provides a structure of a project management team and a definition of the responsibilities andrelationships of all roles involved in the project. According to the size and complexity of a project., theseroles can be combined or shared.PRINCE2pracWeb.doc Page 12
  • 13. PRINCE22.9.3. PlansPrince2 offers a series of plan levels that can be tailored to the size of a project and an approach toplanning based on products rather than activities.2.9.4. ControlsPrince2 provides a set of controls which facilitate the provision of key decision-making information,allowing an organization o pre-empt problems and make decisions on problem resolution. For seniormanagement Prince2 controls are based on the concept of management by exception. In order topromote sound management control, a project is split into stages as an approach to defining the reviewand commitment point of a project.2.9.5. Management of RiskRisk is a major factor to be considered during the life of a project. Prince2 efines the key moments whenrisks should be reviewed, outlines an approach to the analysis and management of risk, and tracks thesethrough all processes.2.9.6. Quality in a project environmentPrince2 recognizes the importance of quality and incorporates a quality approach to the management andtechnical processes. It begins by establishing the customers quality expectations and follows these up bylaying down standards and quality inspection methods to be used and by checking that these being used.2.9.7. Configuration ManagementTracking the components of a final product and their versions for release is called ConfigurationManagement. There are many methods of Configuration Management available. Prince2 defines theessential facilities and information requirements for a configuration management method and how itshould link with other Prince2 components.2.9.8. Change controlPrince2 emphasis the need for change control, and this is enforced with a change control technique plusidentification of the processes that capture, analyze and progress the change control.2.10. The techniquesIn support of the method the manual does contain details of these techniques: product based planning,change control and quality review.PRINCE2pracWeb.doc Page 13
  • 14. PRINCE23. STARTING UP A PROJECT (SU) SU Starting up a project SU1 SU2 SU3 Appointing an Executive Designing a Project Appointing a Project and a Project Manager Management Team Management Team DP1 Authorizing initiation SU4 SU5 SU6 PL Preparing a Project Brief Defining a Project Approach Planning an initiation stage PLANNINGThe work of the process is built around the production of seven elements:  Designing and appointing the project management team  Ensuring that the information required for the Project Brief is available  Establishing the Project Approach  Establishing the customer‟s quality expectations  Creating an outline Business Case  Setting up a Risk Log  Creating the Initiation Stage PlanThe objective of the process is to enable a controlled start to the project by ensuring that:  All the necessary project management authorities exists for undertaking the project  Sufficient information is available to formalize the terms of reference for the project  Individuals are appointed who will undertake the work required in project initiation and/or will take significant project management roles in the project.  The work required for the project initiation is planned  The organization that will host the project team is informed of the existence and implications of the new project.3.1. Appointing an Executive and a Project Manager (SU1)3.1.1. ObjectiveThe objectives of this sub-process are to:  Identify the Executive from the project‟s stakeholders  Identify the most appropriate Project Manager for the project  Confirm the selected people‟s availability, their acceptance of those roles and their commitment to carry them out.  Appoint them to their respective roles3.1.2. ResponsibilitiesResponsibility for this sub-process lies with corporate or programme management.3.2. Designing a project management team (SU2)PRINCE2pracWeb.doc Page 14
  • 15. PRINCE23.2.1. ObjectiveThe objectives of this sub-process are to:  Design the project management team structure appropriate to the size and nature of the project and the groups involved  Identify candidates for each role in order to produce a recommended project management team  Determine the responsibilities and requisite skills for each position  Where the project is part of a programme, programme management has responsibility for ensuring the establishment of an appropriate Project Board. If this is done, most of this sub- process is not required. The programme may, however, leave the appointment of the remainder of the Project Board to the Executive.3.2.2. ResponsibilitiesThe Excecutive and the Project Manager are jointly responsible for the design. The Executive will takespecific responsibility for the Project Board design.3.3. Appointing a Project Management Team (SU3)3.3.1. ObjectiveThe objectives of this sub-process are to:  Appoint people to: o The Project Board o Project Assurance (where appropriate) o Project Support (where appropriate) o Team Management  Ensure that these individuals understand their roles and responsibilities in the management and support of the project  Ensure that the individuals are actively committed o carrying out their roles and responsibilities  Confirm the reporting and communication lines, and include in management information as this will impact on the Communication Plan3.3.2. ResponsibilitiesThe Executive is responsible for appointments, assisted and advised by the Project Manager. TheExecutive will have to liaise with corporate or programme management to identify the appropriatepersonnel and negotiate for their availability.3.4. Preparing a Project Brief (SU4)3.4.1. ObjectiveThe objectives of this sub-process are to:  Prepare the formal terms of reference for the project  Establish the customer‟s quality expectations  Establish the Acceptance Criteria for the project  Begin a record of any risks facing the project  Ensure there is an outline Business Case based on information provided in the Project Mandate3.4.2. ResponsibilitiesPRINCE2pracWeb.doc Page 15
  • 16. PRINCE2The Executive is ultimately responsible for the production of the Project Brief. In practice, the ProjectManager and any appointed Project Support will do much of the actual work. The Executive‟s ProjectAssurance role should review the outline Business Case and Risk Log.3.5. Defining a Project Approach (SU5)3.5.1. ObjectiveThe objectives of this sub-process are to:  Decide how the work of the project should be approached  Identify any constraints on the way that the work of the project must be carried out or on the timing of certain product deliveries  Identify the skills required to conduct the work of the project3.5.2. ResponsibilitiesThe Project Manager is responsible for carrying out this sub-process. However, the work will need to bedone by people skilled in the specialist areas involved, with input from Project Support and ProjectAssurance roles, under the overall direction of the Senior Supplier.3.6. Planning an Initiation Stage (SU6)3.6.1. ObjectiveThe objectives of this sub-process are to:  Produce a plan (the Initiation Stage plan) that covers the production of two management products: o The Project Initiation Document (which includes the Project Plan) o The Stage Plan for the next Stage  Define the reporting and control arrangements for the initiation stage3.6.2. ResponsibilitiesThe Project Manager is responsible for planning the initiation stage. The appointed Project Assuranceand Project Support roles will assist. In particular whoever is responsible for business assurance needs toidentify in the Initiation Stage Plan how the Business Case and risk assessment will be checked.PRINCE2pracWeb.doc Page 16
  • 17. PRINCE23.7. Input and output Input Sub-process Ouput · Projectmandate SU1 · Projectmandate (update) Appointing an Executive · Role description Executive + and a Project Manager Project manager · Appointed Executive + Project manager SU2 · Project management team · Projectmandate structure · Role description Executive + Designing a project Management team · Conceptual role description other Project manager members of the project management team · Project management team SU3 structure Appointing a project · Appointed Project management · Conceptual role description other Management team team members of the project · Definitive role descriptions management team · Projectmandate SU4 · Project Brief Preparing a Project Brief · Risk Log SU5 · Project Brief Definining a Project · Project Approach · Risk Log Approach · Project Brief SU6 · Stage paln for the Initiation stage · Project Approach Planning an Initiation · Risk Log (update) · Risk Log StagePRINCE2pracWeb.doc Page 17
  • 18. PRINCE24. INITIATING A PROJECT (IP) IP Initiating a project IP3 IP1 IP2 Refining the Business Case Planning Quality Planning a Project and Risks DP1 PL Authorizing PLANNING initiation DP2 IP6 Authorising IP4 IP5 Assembling a Project a Project Setting up Project Controls Setting up Project Files Initiation DocumentIn formal terms the objectives of Initiating a Project are to:  Document and confirm that and acceptable Business Case exists for the project  Ensure a firm and accepted foundation to the project, prior to commencements of the work, via the creation of the Project Initiation Document  Enable and encourage the Project Board to take ownership of the project  Enable and encourage the Project Board to: o Make a decision on whether the project is viable o Agree to the commitment of resources to the next stage of the project  Provide the benchmark for the decision-making processes required during the project‟s life  Ensure that by carrying our initiation in an organized manner, the investment of time and effort required by the project is made wisely, taking account of the risks to the project.4.1. Planning quality (IP1)4.1.1. ObjectiveThe objective of this sub-process are to determine the quality required for products of the project, and toplan the project‟s approach to quality (the Project Quality Plan) by:  Establishing the quality regime that will apply to the project and what Project Assurance arrangements will be employed  Agreeing the customer‟s quality expectations  Refining the project‟s acceptance criteria  Establishing the approach to be used within the project for the control of changes4.1.2. ResponsibilitiesThe project manager is responsible for this sub-process, assisted by those with Project Assuranceresponsibilities, particularly those connected to business assurance. Where a separate quality assurancefunction exists within a corporate body, the work of this sub-process must be done in close co-ordinationwith that function.PRINCE2pracWeb.doc Page 18
  • 19. PRINCE24.2. Planning a project (IP2)4.2.1. ObjectiveThe objectives of this sub-process are to:  Understand at a high level the totality of the work that is about to be undertaken y: o Identifying and, where possible, defining the major products of the project o Identifying the major activities to be performed to deliver products o Assessing the major risks of the project and putting in place countermeasures o Estimating the effort needed o Identifying what timescales are achievable, given that project constraints and any key milestones o Identifying the overall resource requirements and costs  Identify the key decision and review points for the project, and any implications on these from the Project Approach. From these decide where the management stage divisions should be  Use the Planning process to produce the Project Plan  Use the Panning process to produce the Next Stage Plan4.2.2. ResponsibilitiesThe Project Manager is responsible for this sub-process, assisted where appropriate by Project Supportroles and other members of the project management team, and guided by those with Project Assuranceresponsibilities, who also check the results.4.3. Refining the Business Case and risks (IP3)4.3.1. ObjectiveThis sub-process refines the Business Case and may reveal extra risks. The objectives of this sub-processare to:  Refine the Business Case in the light of what is now known about the project  Identify how the achievement of each benefit is to measured  Add to the Risk Log any extra problems or threats identified during this process  Modify the Project Plan in the light of any risk management activities4.3.2. ResponsibilitiesThe project manager is responsible for this sub-process, assisted, where appropriate by Project Supportroles and advised by those with Project Assurance responsibilities. The project manager should discussthe Business Case and risks with the Project Board informally before presentation in the Project InitiationDocument.4.4. Setting up Project Control (IP4)4.4.1. ObjectiveThe objectives of this sub-process are to:  Establish the level of control and reporting required by the project board for the project after initiation  Develop controls that are consistent with the risk and complexity of the project  Establish the day-to-day monitoring required to ensure that the project will be controlled in an effective and efficient manner.  Identify all interested parties and agree their communications needsPRINCE2pracWeb.doc Page 19
  • 20. PRINCE24.4.2. ResponsibilitiesThe project manager is responsible, assisted by project supported and advised by those with projectassurance responsibilities.4.5. Setting up the Project Files (IP5)4.5.1. ObjectiveThe objectives of this sub-process are to:  Institute a system of storing and retrieving all information relevant to the management of the project, the quality checking work done and the products themselves, which will provide appropriate support to the project team and to the implementation of change management.  Assign responsibility for managing this filing system.4.5.2. ResponsibilitiesThe Project Manager is responsible for this sub-process, assisted by any project support roles and advisedby those with project assurance responsibilities.Wher the project is part of a programme, the project-level filing structure must be consistent with that atprogramme level.4.6. Assembling a Project Initiation Document (IP6)4.6.1. ObjectiveThe objectives of this sub-process are to:  Provide a basis for the decisions to be made in Authorizing a Project (DP2)  Provide a benchmark for all the other management decisions that need to be made during the life of the project  Provide an information base for everyone who need to know about the project4.6.2. ResponsibilitiesThe Project Manager is responsible for the production of the document, assisted by project support.There should be close consultation with Project Assurance on the content as it is developed.PRINCE2pracWeb.doc Page 20
  • 21. PRINCE24.7. Input and output Input Sub-process Ouput · Project Brief IP1 · Quality Plan · Project Approach Planning Quality · Quality Log · Quality Standards · Project Approach IP2 · Project Brief Planning a Project · Project plan · Quality Plan · Risk Log (update) · Risk Log · Project approach IP3 · Business Case · Project Brief Refining a Business Case · Project plan (update) · Risk Log and risks · Risk Log (update) · Project plan · Quality Plan IP4 · Communication plan · Project plan Setting up project controls · Project controls · Risk Log · Project plan (update) · Risk Log (update) · Projectplan IP5 · Issue log · Quality plan Setting up project files · Lessons Learned Log · Daily log · Quality Plan (update) · Project Brief IP6 · Concept Project Initiation · Project management team Assembling a Project Document structure & role descriptions Initiation Document · Stage plan for the 1st Stage · Project Approach · Quality plan · Project plan · Business Case · Risk log · Project controls · Communication planPRINCE2pracWeb.doc Page 21
  • 22. PRINCE25. DIRECTING A PROJECT (DP) DP Directing a project DP4 Giving Ad Hoc Direction DP1 DP2 DP3 DP5 Authorizing Authorizing a Authorizing a Stage or Confirming Initiation project Exception plan Project Closure Managing stage Starting up a Controlling a boundaries Initiating a project Closing a project project stageSenior management who have the authority and responsibility for:  Defining what is required form the project  Authorizing the funds for the project  Committing the resources  Communicating with external partiesDirecting a Project (DP) runs from Starting up a project (SU) until project closure and includes the workto:  Authorize the initiation of the project  Provide management direction and control through its life  Liaise with corporate or programme management  Confirm project closure5.1. Authorizing Initiation (DP1)5.1.1. ObjectiveThe objective of this sub-process is to ensure that the project is properly initiated by:  Formally confirming the appointments to the project management team  Ratifying the Project Brief  Approving a plan to develop the Project Initiation Document  Obtaining or committing the resources needed by the initiation stage plan  Requesting the necessary support via the project start-up notification to the host organization (the location where the work is to be done)5.1.2. ResponsibilitiesResponsibility for this sub-process rests with the Project Board, based on input provided by the ProjectManager and those with Project Assurance responsibilities. Corporate or programme management isresponsible for ratifying the Project Brief for the Project Board.5.2. Authorizing a project (DP2)PRINCE2pracWeb.doc Page 22
  • 23. PRINCE25.2.1. ObjectiveThe objective of this sub-process is to decide whether to proceed with the project. This is based onapproval or rejection of the Project Initiation Document.5.2.2. ResponsibilitiesThe Project Board is responsible for this sub-process. Most of the input will come from the ProjectManager.5.3. Authorizing a Stage or Exception Plan (DP3)5.3.1. ObjectiveThe objective of this sub-process is to decide whether to authorize the next of work and hence committhe required resources, based on:  A view of the current status of the project  A detailed forecast of the commitment of resources required by and the products to be created from the next stage of the project  A reassessment of the likely project end date  A reassessment of the Risk situation  A reassessment of the Business Case and the chances of achieving the expected benefits.5.3.2. ResponsibilitiesThe Project Board has full responsibilities for this sub-process, based on information provided by theProject Manager. Advice would be given by any allocated Project Assurance roles.5.4. Giving ad hoc direction (DP4)5.4.1. ObjectiveThe objectives are for the Project Board to:  Ensure that the project remains focused on the business objectives set and remains justified in business terms  Ensure that the stage is progressing according to plan  Ensure that the project manager is notified of any changes in the corporate or programme environment that may impact on the project and that appropriate action is taken  Ensure that project is kept informed of external events that may affect it  Make decisions on Project Issues or Exception Reports that are beyond the Project Manager‟s authority  Advise the Project Manager of any change to Project Board personnel  Keep corporate or programme management and other interested parties informed about the project progress5.4.2. ResponsibilitiesThis sub-process is a Project Board responsibility. It may look to share some of the activities with thosewith Project Assurance responsibilities.5.5. Confirming Project Closure (DP5)5.5.1. ObjectiveThe project needs to be closed down in an orderly manner.PRINCE2pracWeb.doc Page 23
  • 24. PRINCE2The objectives of this sub-process are to:  Ensure that the project has a clearly defined end and an organized handover of responsibility to the group(s), who will use, support and sustain the products  Release the resources provided to the project  Gain formal acceptance from the customer that the Acceptance Criteria set down at the outset have been met adequately  Direct any change that have not been implemented to an appropriate authority for attention and any lessons learned to people who best benefit from them  Establish a future method for verifying that the project has produced the desired benefits  Notify all interested parties of the closure of the project5.5.2. ResponsibilitiesThis sub-process is the responsibility of the Project Board, supported by those with Project Assuranceresponsibilities.It is the responsibility of the Executive to ensure that the person who will conduct the post-projectreview is properly briefed and that accountability is passed to that person.PRINCE2pracWeb.doc Page 24
  • 25. PRINCE25.6. Input and output Input Sub-process Ouput · Project management team DP1 · Project Brief structure & role descriptions Authorizing Inititation · Initiation stage Plan · Project Brief · Announcement project start · Risk Log · Authorization Initiation · Project approach · Initiation Stage Plan · Draft Project Initiation DP2 · Project Initiation Document document Authorising a Project · Accepted stage plan · Nect Stage plan · Authorization project · End Stage Report · Next Stage Plan or exception Plan DP3 · Trigger for premature close · Request for authorization to Authorizing a Stage or · Authorization to proceed proceed Exception Plan · Progress Information · Project Plan · Approved Stage Plan or · Business Case Exception Plan · Project Initiation Document · Project Management Team changes · Highlight Report · Management reports DP4 · Exception report · Project Board Guidance Giving ad hoc direction · Requests for advice · Trigger for premature close · Information from external sources · Exception Plan request · Communication plan · New project issues DP5 · Project closure notification · Operational, maintenance and Confirming project · Follow-on Action customer acceptance closure recommendations · Project closure recommendation · Post-Project Review plan · Follow-on Actions · Lessons learned report recommendations · End project Report · Post-Project Review plan · Lessons learned report · End project report · Project Initiation Document · Communication planPRINCE2pracWeb.doc Page 25
  • 26. PRINCE26. CONTROLLING A STAGE (CS) DP MP CP Directing a Managing Closing a project project Product delivery CS Controlling a Stage CS9 CS7 CS1 CS2 Receiving Taking corrective Authorizing Work Assessing Completed Work action Package Progress Package CS8 CS6 CS5 CS4 CS3 Escalating Reporting Reviewing Stage Examining project Capturing Project Project Issues Highlights Status Issues Issues DP SB Directing a Managing Stage project BoundariesOnce a decision has been taken to proceed with work and resources have been committed, the projectmanagement team must focus on delivery within the tolerance laid down.This means controlled production of the agreed products:  To stated quality standards  Within cost, effort and time agreed  Ultimately to achieve defined benefitsThe objectives of Controlling a Stage (CS) are to:  Deliver the right products  Ensure that quality is achieved as planned  Deliver products on time and to costs within agreed tolerances  Correctly direct and conduct work on products  Keep control of products via configuration management  Properly direct and utilize resources  Update plans with actuals, enabling progress to be checked against the plan  Correctly cost resource usage  Correctly manage deviations from Stage or Project Plans  Inform all interested parties about project progress in a timely manner  Ensure that projects are stopped or redirected if the reasons for setting them up have been invalidated by internal or external events6.1. Authorizing Work Package (CS1)6.1.1. ObjectiveThe objective of this sub-process is to keep control over the work of the team(s) by:  Issuing work instructions (work triggers) to the team manager(s) to commence work  Revising the instructions as required following management decisionsPRINCE2pracWeb.doc Page 26
  • 27. PRINCE26.1.2. ResponsibilitiesThe Project Manager is responsible for this sub-process, assisted by any Project Support Roles, and inagreement with the relevant Team Manager. The Configuration Librarian will update the ConfigurationItem Records. Project Assurance might wish to confirm that suitable quality checking arrangements havebeen planned.6.2. Assessing progress (CS2)6.2.1. ObjectiveThe objective of this sub-process is to maintain an accurate and current picture of:  Progress on the work being carried out  The status of resources6.2.2. ResponsibilitiesThe project manager is responsible for this sub-process, assisted by any project support roles. TheConfiguration Librarian would provide any product status account required. If the team manager worksfor a supplier who does not use Prince2, the work package will still contain a requirement for checkpointreports to be submitted. Project assurance may review the updated Quality Log.6.3. Capturing Project Issues (CS3)6.3.1. ObjectiveThe objectives of this sub-process are to capture, log and categorize all Project Issues. The steps involvedin achieving this are:  Enter all project issues in the Issue Log as soon as they are identified  Assess whether the Project Issue is: o A Request for change o An Off-Specification o A new risk o A general issue6.3.2. ResponsibilitiesThe project manager is responsible for this sub-process, although a Project Support Role (ConfigurationLibrarian) may be nominated to act as the central focus for receiving and documenting Project Issues.6.4. Examining Project issues (CS4)6.4.1. ObjectiveAll open Project Issues should be reviewed and courses of action recommended for consideration duringReviewing Stage Status (CS5). An initial examination of a Project Issue should be performed as soon as itis logged. On a regular basis all open Project Issues should be reviewed.6.4.2. ResponsibilitiesThe project manager is responsible for this sub-process. Member of the teams may be required to assessthe impact of project issues on products, workload, cost, schedule and risk, and devise alternative coursesof action.PRINCE2pracWeb.doc Page 27
  • 28. PRINCE26.5. Reviewing stage status (CS5)6.5.1. ObjectiveThis sub-process provides the means for a regular assessment of the stage status. The process decideswhether:  Further work packages should be proposed  Any plan modifications are requiredThe first objective of this sub-process is to check periodically that the current stage is kept within thetolerance set down by the Project Board by:  Reviewing progress against the Stage Plan and Product Checklist (if used)  Checking the Quality Log to see the state of quality checking  Checking the Configuration Item Records to ensure that all products have been completed as stated and anticipated  Reviewing resource utilization and future availability  Reviewing the effect of Project Issues on any change budget and stage and Project Plans  Establishing whether or not the stage will go outside the tolerances  Passing project issues likely to cause tolerance to be exceeded to the Project board for consideration via Escalating Project Issues (CS8)  If corrective action is needed, but the stage is forecast to stay within tolerance, the action can be taken by the project manager, as described in Taking Corrective Action (CS7).The second objective if this sub-process is to review project status, specifically:  Checking that the Business Case is still valid  Reviewing the Risk Log for possible changes  Establishing whether or not the project will go outside the tolerances  Ensuring that there are no quality problems6.5.2. ResponsibilitiesThe Project Manager is responsible for this sub-process, supported by any Project Support roles includingthe Configuration Librarian and those with Project Assurance responsibilities.6.6. Reporting Highlights (CS6)6.6.1. ObjectiveThe objectives if this sub-process are to:  Provide the Project Board with summary information about the status of the stage and project at the frequency defined by the Project Board  Pass out any other information required by the Communication Plan6.6.2. ResponsibilitiesThe Project manager is responsible for this sub-process, assisted by any Project Support roles. ProjectAssurance may wish to assess what is being reported to the Project Board.6.7. Taking corrective action (CS7)6.7.1. ObjectiveThe objective of this sub-process is to select and (within the limits of the stage and project tolerances)implement actions that will resolve deviations from the plan. Decisions may be required from the ProjectPRINCE2pracWeb.doc Page 28
  • 29. PRINCE2Board via Giving ad Hoc Direction (DP4). The Project Manager has to decide when to seek advice of theProject Board.6.7.2. ResponsibilitiesThe Project Manager is responsible for this sub-process, supported by Project Assurance and ProjectSupport roles and in consultation with Team Members if appropriate. The Configuration Librarian, whereappointed, will update the Configurations Item Records and make any necessary products available.6.8. Escalating project issues (CS8)6.8.1. ObjectiveIf the stage is forecast to go outside the tolerance margins (possibly as a result of a corrective action), theproject manager must bring the situation to the attention of the Project board.6.8.2. ResponsibilitiesThe project manager is responsible for escalating project issues. Those with project assuranceresponsibilities should also be monitoring any situation that could cause a deviation and should bring thematter to the project manager‟s attention. The Configuration Librarian will update Configuration ItemRecords where necessary.6.9. Receiving completed work package (CS9)6.9.1. ObjectiveConfirmation is sought that the Work Package has been completed satisfactorily. This includes checkingthat:  The recipient of the products has accepted them  The Quality Log entries are complete  The appropriate records have been punt in the quality file  The products have been transferred to configuration management6.9.2. ResponsibilitiesThe project manager is responsible for this sub-process, assisted by any appointed Project Support staff.The team member or Team Manager responsible for completion of the Work Package will provideinformation. The Configuration Librarian will update all affected Configuration Item Records.PRINCE2pracWeb.doc Page 29
  • 30. PRINCE26.10. Input and output Input Sub-process Ouput · Product description · Work trigger · Work Package · Authorisation to proceed CS1 · Product checklist · Product chekclist Authorizing Work · Configuration Item Records · Configuration Item Records Package · Stage or Exception Plan · Stage or Exception plan · Risk Log · Risk Log · Issue Log · Issue Log · Quality Log · Quality Log · Checkpoint Report · Checkpoint report · Stage Plan · Team plan CS2 · Product Checklist · Stage Plan Assessing Progress · Issue log · Product Checklist · Configuration Item Records · Issue Log · Stage status information · Configuration Item Records · Product Status Account · Work Package status · New project Issues CS3 · Updated Issue Log · Issue Log Capturing Project Issues · Updated Issue Log · Risk Log · Issue Log CS4 · Risk Log (Update) · Business Case Examining Project Issues · Issue Log (update) · Project Plan · Stage Plan · Stage status information · Daily Log · Issue Log · Daily Log · Risk Log · Tolerance Threat CS5 · Stage Plan · Plan deviation Reviewing Stage Status · Project Plan · Work trigger · Quality Log · Stage status information · Business Case · Trigger for project end · Product checklist · Configuration item records · Concession · Stage Status information · Highlight report · Issue Log · Stage status Information · Risk Log BF6 Hoofdpunten · Communication to interested · Quality Log parties · Communication Plan rapporteren · Product Checklist · Previous Highlight report · Checkpoint reports · Plan deviation · Issue Log · Issue Log CS7 · Risk log · Risk Log Taking corrective action · Project Board Guidance · Request for Advice · Stage Plan · Work trigger · Product checklist · Tolerance threat · Business Case · Concession · Project plan · Exception Report · Risk Log CS8 · Trigger for premature closure · Project Initiation Document Escalating Project Issues · Exception Plan request · Stage Plan · Approved Exception report · Configuration Item Records · Configuration Item Records · Issue Log · Issue Log · Project Board Decision · Approved Exception report · Configuration Item Records CS9 · Approved Work Package · Quality Log Receiving Completed · Work package Status · Work Package Work Package · Configurations Item RecordsPRINCE2pracWeb.doc Page 30
  • 31. PRINCE2PRINCE2pracWeb.doc Page 31
  • 32. PRINCE27. MANAGING PRODUCT DELIVERY (MP) MP Managing Product Delivery PL MP1 MP2 MP3 Planning Accepting a Work Package Executing a Work Package Delivering a work Package CS1 CS9 CS2 Authorizing a Work Receiving Completed Work Assessing progress Package PackageThe objectives of this process are to allow a Team Manager to:  Agree work with the Project Manager  Get it done  Hand it back to the Project Manager7.1. Accepting a Work Package (MP1)7.1.1. ObjectiveThe Team Manager has to agree the Work Package with the project Manager. The steps for this are:  Make a clear agreement with the Project manager on what is to be delivered  Negotiate with the Project Manager on behalf of the team the constraints within which the work is to be done  Agree tolerance margins for the Work Package  Understand the reporting requirements  Understand how and from whom approval for the products is obtained  Confirm how the Project Manager is to be informed of completion of the Work Package  Produce or amend a Team Plan to show that the Work Package can be completed within the constraints. The common Planning (PL) process will be used to modify or create Team Plans.  Perform risk analysis, planning and resourcing  Make any necessary updates to the Quality Log, for example, extra reviewers identified in decisions with Project Assurance.7.1.2. ResponsibilitiesThe Team Manager is responsible for the agreement with the Project Manager. Project Assurance willwant to confirm that suitable quality checking arrangements and personnel are included in any TeamPlans.7.2. Executing a Work Package (MP2)7.2.1. ObjectiveThe work on an authorized Work Package has to be monitored at the depth required to provide feedbackto the Project Manager as defined in the authorized Work Package. The necessary steps are to:  Manage the development of the required products/servicesPRINCE2pracWeb.doc Page 32
  • 33. PRINCE2  Capture and record the effort expended  Determine the status of each product in the Work Package  Evaluate with the creator(s) the effort still required  Feed the progress and status information back to the Project Manager in Checkpoint Reports, in the manner and at the frequency defined in the Work Package  Update the Quality Log with details of all quality checks carried out  Advise the Project manager of any problems that might impact the agreed tolerance levels for the Work Package7.2.2. ResponsibilitiesThe Team Manager is responsible for this sub-process. Project Assurance or their representatives will beinvolved in much of the quality checking.7.3. Delivering a Work Package (MP3)7.3.1. ObjectiveThis sub-process has three elements:  Obtain acceptance for the products developed  Hand over the completed products  Advise the Project Manager of completion of the Work Package7.3.2. ResponsibilitiesThe Team Manager is responsible for this sub-process, liaising with the Configuration Librarian.7.4. Input and output Input Sub-process Ouput · Work Package · Authorized Work Package MP1 · Team Plan · Team Plan Accepting a Work · Risk Log · Risk Log Package · Quality Log · Quality Log MP2 · Checkpoint Report · Authorized Work Package Executing a Work · Completed Work Package · Team Plan Package · Team Plan · Quality Plan · Quality Log · Completed Work Package MP3 · Work Package · Quality Log Delivering a Work PackagePRINCE2pracWeb.doc Page 33
  • 34. PRINCE28. MANAGING STAGE BOUNDARIES (SB) SB Managing Stage Boundaries DP3 SB5 Authorizing a Reporting Stage Stage or End Exception Plan SB3 CS5 SB2 SB1 Updating a Reviewing Stage Updating a Planning a Stage Project Business Status Project Plan Case CS8 SB6 SB4 Escalating Producing an Updating the Risk Project Issues Exception Plan Log PL PlanningThe objectives of the process are to:  Assure the Project Board that all products in the current Stage Plan have been completed as defined  Prepare the next Stage Plan  Provide the information needed for the project Board to assess the continuing viability of the project  Obtain authorization for the start of the next stage together with its tolerance margins  Record any information or lessons that can help later stages of this project and/or other projects.8.1. Planning a Stage (SB1)8.1.1. ObjectiveThe main objective of this sub-process is to prepare a plan for the next stage of the project. The high-level summary of the next stage is expanded from the Project Plan into sufficient detail that the ProjectManager will be able to control progress against it on a day-to-day basis. The plan should include allproducts – not only the specialist ones but management products as well.8.1.2. ResponsibilitiesThe Project Manager is responsible for this sub-process, assisted by Project Support. Those with ProjectAssurance responsibilities should check out the plan, with respect to it continuing to meet customer andbusiness expectations. Any Team Manager who will be providing products in the stage will normallydevelop the relevant Team Plans at this time and assist the Project Manager in creating the Stage Plan.8.2. Updating a Project Plan (SB2)8.2.1. ObjectivePRINCE2pracWeb.doc Page 34
  • 35. PRINCE2The Project Quality Plan and the Project Approach are reassessed and refined to reflect the currentunderstanding of the project an to form a basis for updating the Project Plan.The Project Plan is updated based on the actual costs and schedule from a completed Stage Plan orException Plan, the new detail of activities and costs from the next Stage Plan and any acquiredknowledge about the project. The last might be information about changes that have been agreed by theProject Board and that can cause activities in the next Stage Plan.The Project Manager should describe in the End Stage Report why any change to the Project planoccurred.8.2.2. ResponsibilitiesThe Project Manager is responsible for this sub-process, assisted by Project Support, and the workchecked out by those with Project Assurance roles.8.3. Updating a Project Business Case (SB3)8.3.1. ObjectivesThe objective of this sub-process is to revisit and revise, where necessary, the costs, benefits, risks andtimings stated in the Business Case. These may have been affected by internal or external events.8.3.2. ResponsibilitiesThe project Manager is responsible for this sub-process, assisted by Project Support. Those with ProjectAssurance responsibilities should check out the work. The project‟s benefits are a prime responsibility ofthe customer.8.4. Updating the Risk Log (SB4)8.4.1. ObjectivesThe objective of this sub-process is to revisit and revise, where necessary, the risks in the Risk Log. Thesemay have been affected by internal or external events.8.4.2. ResponsibilitiesThe Project Manager is responsible for this sub-process, assisted by Project Support. Those with ProjectAssurance responsibilities should check out the work8.5. Reporting Stage End (SB5)8.5.1. ObjectiveThis sub-process should happen as close as possible to the actual end of a stage. The results of a stage arepresented in an End Stage Report. The report compares the actual results of the stage in term of costs,target dates achieved and products produced with the original Stage Plan.A summary is given of all Project Issues received during the stage and what has happened to them. AConfiguration audit is performed to check the information in the Configuration Item Record against theactual status of all products and to rectify any discrepancies.The report is modified if an Exception Plan has triggered it, but it is still needed.8.5.2. ResponsibilitiesThe Project Manager has the responsibility for this sub-process with assistance from the Project Support.Informal agreement to the report‟s data and conclusions should be obtained from those responsible forPRINCE2pracWeb.doc Page 35
  • 36. PRINCE2Project Assurance. The Configuration Librarian will assist Project Assurance in performing theConfiguration Audit.8.6. Producing an Exception Plan (SB6)8.6.1. ObjectiveIf a Stage on the project s forecast to go outside the tolerances agreed with the Project Board when theplan was approved and the situation cannot be rectified, the Project Manager has no further mandate tocarry on with the work.The exception Plan will have the same structure as other Prince2 plans. It should run from the presenttime to the end of the plan that it replaces. If it is the Project Plan that is in exception, revised ProjectPlan should be created, taking into account the actuals to date.The Configuration Item Records of all products included in the plan being replaced must be checked.Where the status shows that work is outstanding, the Exception Plan should include this work.8.6.2. ResponsibilitiesThe Configuration Librarian will provide a Product Stats Account of the products in the plan that is to bereplaced. The Project Manager is responsible for producing Exception Plans with the help of ProjectSupport. Those responsible for Project Assurance should check the plan.PRINCE2pracWeb.doc Page 36
  • 37. PRINCE28.7. Input and output Input Sub-process Ouput · Stage End notification · Next Stage Plan · Project Management Team structure SB1 · Project Management Team Structure · Quality Log Planning a Stage · Quality Log · Risk Log · Risk Log · Current Stage Plan · Project Initiation Document · Project Plan · Quality Plan · Next stage Plan · Exception Plan SB2 · Project Plan · Current Stage Plan Updating a Project Plan · Project Approach · Project plan · Quality Plan · Project Approach · Risk Log · Quality Plan · Issue Log · Risk Log · Issue Log SB3 · Business Case · Business Case Updating a Project · Issue Log · Issue Log Business Case · Risk Log · Risk Log · Project Plan SB4 · Business Case Updating the Risk Log · Risk Log · Risk log · Issue Log · Issue Log · Project Plan · Project Plan · Next Stage Plan or Exception Plan · Current Stage Plan · Lessons Learned Log SB5 · Issue Log · Configuration Item Records Reporting Stage End · Business Case · Communication Plan · Risk Log · Current Stage Plan · Quality Log · Next Stage Plan · Lessons Learned Log · End Stage Report · Configuration Item Records · Request for authorization to proceed · Communication Plan · Exception plan request · Exception Plan request · Exception plan · Issue Log SB6 · Issue Log · Risk Log Producing an Exception · Risk log · Current Stage Plan Plan · Current Stage Plan · Project Plan · Project Plan · Project Initiation Document · Project Initiation document · Project team management structure · Project management structure · Quality Log · Quality LogPRINCE2pracWeb.doc Page 37
  • 38. PRINCE29. CLOSING A PROJECT (CP) CP Closing a Project DP3 CP1 Authorizing a Decommissioning Stage or a Project Exception Plan DP4 CP2 Giving ad hoc Identifying DP5 direction Follow-on Actions Confirming Project Closure CS5 CP3 Reviewing Stage Evaluating a Status ProjectOne of the defining features of a project is that it is finite- it has a start and an end. If the project losesthis distinctiveness, it loses some of its advantages over purely operational management approaches.A clear end to the project:  Is always more successful than the natural tendency to drift into use and subsequent modification of the product. It is a recognition by all concerned that: o The original objectives have been met o The current project has run its course o Either the operational regime must now take over or the products from this project become inputs into some subsequent project or into some larger programme.  Helps to achieve business objectives by avoiding wasted time and by providing a useful opportunity to take stock of achievements and experience  Provide an opportunity to ensure that all unachieved goals and objectives are identified so that they can be addressed in the future9.1. Decommissioning a Project (CP1)9.1.1. ObjectiveThe objectives of this sub-process are to:  Ensure that all project‟s products have been approved and handed over to the customer or user  Confirm that the delivered products meet any needs defined in the customer‟s specification for operation and support (where applicable)  Confirm that the correct operational and maintenance environment is in place (where applicable)  Confirm that all Acceptance Criteria have been met  Complete and store all project information  Prepare a recommendation to all involved organizations and interested parties that the project is to be closed and facilities and resources disbandedPRINCE2pracWeb.doc Page 38
  • 39. PRINCE29.1.2. ResponsibilitiesThe Project Manager has responsibility for this sub-process, but may need assistance from ProjectSupport (including the Configuration Librarian) to gather the necessary input. The Project Managershould have informal contact with the Project Assurance during this time for their views on thecompleteness of work to ensure that there will be no problems with the Project Board confirmation ofthe project closure in Confirming Project Closure (DP5)9.2. Identifying Follow-on Actions (CP2)9.2.1. ObjectivesThe aims of this sub-process are to:  Check that all project Issues and risks are closed or transferred to follow-on action recommendations. Establish actions required following the project  Document any follow-on actions recommendation  Recommend a date and produce a plan for any post project review(s) considered necessary9.2.2. ResponsibilitiesThe Project Manager has responsibility for this sub-process9.3. Evaluating a Project (CP3)9.3.1. ObjectiveThe objectives of this sub-process are to:  Update the Project Plan with actuals from the final Stage  Assess the results of the project against what is intended to achieve  Examine the records of the completed project to assess the quality of its management, especially quality and risk management  Identify lessons to be learned from the project and applied on future projects9.3.2. ResponsibilitiesThe Project Manager bears overall responsibility for this sub-process, but additional information couldcome from anyone involved in the project.PRINCE2pracWeb.doc Page 39
  • 40. PRINCE29.4. Input and output Input Sub-process Ouput · Trigger for premature closure · Notifications of project end · Project Closure recommendation CP1 · Project Initiation Document · Operational and maintenance Decommissioning a · Communication Plan Project acceptance · Issue log · Customer acceptance · Configuration Item Records · Management information · Configuration Management Plan · Project Status Account · Business Case · Post-Project review plan CP2 · Issue Log Identifying follow-on · Follow-on Action · Risk log actions Recommendation · Business Case · Project Initiation Document · End Project Report CP3 · Project quality Plan · Lessons Learned Report Evaluating a Project · Lessons Learned Log · Project Plan · Risk Log · Quality log · Issue Log · Daily Log · Configuration Item Records · Project PlanPRINCE2pracWeb.doc Page 40
  • 41. PRINCE210. PLANNING PL Planning SB6 Planning an PL2 PL3 Initiation Stage PL1 Defining and Identifying Designing a Plan Analyzing Activities and Products Dependencies PL4 IP2 Estimating Planning a Project PL7 SB1 PL6 PL5 Completing a Planning a Stage Analysing Risks Scheduling Plan MP1 SB2 SB6 Accepting a Work Updating a Producing an Package Project Plan Exception PlanPlanning is a repeatable process and plays an important role in other sub-processes, the main ones being:  Planning an Initiation Stage (SU6)  Planning a Project (IP2)  Planning a Stage (SB1)  Accepting a Work Package (MP1)  Updating a Project Plan(SB2)  Producing an Exception Plan (SB6)The philosophy behind producing plans in PRINCE2 is that:  Plans are constructed by identifying the products required, and then the activities and appropriate resources necessary to deliver them  Plans should cover management needs as well as the customer‟s products  There should be assurance that all activities are thought through in advance and to a level consistent with the control requirements identified in the Project Initiation DocumentThe product based planning technique provides a start to the planning activity and a planning framework.It involves:  Establishing what products are needed for the plan  Describing those products and their quality criteria  Determining the sequence in which each of the products should be produced and any dependencies10.1. Designing a Plan (PL1)10.1.1. ObjectiveChoices need to be made for presentation and layout of the plan, planning tools, estimating methods,level of plan and monitoring methods to be used for the project.10.1.2. ResponsibilitiesPRINCE2pracWeb.doc Page 41
  • 42. PRINCE2Ultimately, the responsibility for the decisions in designing a plan rests with the Project Board, but inpractice the Project Manager would produce recommendations for informal Project Board approval.10.2. Defining and Analyzing Products (PL2)10.2.1. ObjectiveThis sub-process is divided into three steps:  Identify the specialist products and the management products to be produced  Describe each of them in terms of their quality requirements and ensure that they are fully understood and agreed by everyone involved (this requires the creation of the necessary Configuration Item Records)  Sequence them in their logical order of creation.10.2.2. ResponsibilitiesThe project Manager is responsible for the sub-process for Project and Stage Plans. Team Plans may wellbe produced by Team Managers for agreement by the Project Manager. There should be consultationwith the customer, user(s) and specialist to ensure that all the required products are covered. Those withProject Assurance responsibilities should vet the results. The Configuration Librarian is responsible forthe creation of Configuration Item Records for all necessary products, as specified in the ConfigurationManagement Plan.10.3. Identifying Activities and Dependencies (PL3)10.3.1. ObjectiveThis sub-process is divided into three steps:  Identify all activities necessary to deliver the products  Establish the interdependencies both internal and external to the project are covered10.3.2. ResponsibilitiesThe Project Manager is responsible for this sub-process for Project and Stage Plans. Team Plans are theresponsibility of Team Manager(s). There should be support from any Team Manager whose teamcontributes to execution of the plan in question. Help should also be found from any Project Assuranceor Project Support staff allocated to the project. The checking of the work is part of the responsibility ofthe Project Assurance roles.10.4. Estimating (PL4)10.4.1. ObjectiveThis is an iterative sub-process. The objective is to identify the resources and time required to completeeach activity. This will include not only people but also all other resources that will be required.The two major steps in a typical estimating process are:  Identify resource types required  Estimate effort required for each activity by resource type10.4.2. ResponsibilitiesThe Project Manager is responsible for estimation on Project and Stage Plan. The Team Manager will beresponsible for Team plan estimates. It is a difficult job and, wherever possible, extra help should besought. It requires experience in the subject matter of the plan as well as training in the job of estimation.This is where expertise from Project Support can help greatly.PRINCE2pracWeb.doc Page 42
  • 43. PRINCE210.5. Scheduling (PL5)10.5.1. ObjectivesThe objectives of scheduling are to:  Match available resources to the identified activities  Schedule work according to the defined sequence and dependencies  Smooth resource usage within the bounds of the identified dependencies and may overall time constraints.  Identify surplus resource effort or additional resource effort needed and negotiate with the Project board to resolve these  Calculate total requirements for human and other resources and produce a cost for these.10.5.2. ResponsibilitiesThe Project Manager is responsible for this sub-process. For Team Plans, the Project Manager wouldinvolve the person responsible for the work contained in the plan, for example, a Team Manager. Helpmay be provided by Project Support staff allocated to the project.10.6. Analyze Risks (PL6)10.6.1. ObjectiveRisks should be considered and modifications to the course of action in order to remove or lessen theimpact of those risks. Analyzing Risks (PL6) runs parallel to all other planning work. It is an iterativeprocess and the results of analyzing risks may result in returning to previous steps and repeating the sub-process as necessary.10.6.2. ResponsibilitiesThe Project Manager is responsible for the analysis and monitoring of risks, with assistance from thosewith Project Assurance responsibilities. There may be risks outside the control of the Project Manager.These fall within the responsibilities of the Project Board. The Project Manager should discuss any suchrisks with the Project Board to ensure that the risks are being adequately monitored. They should alsodiscuss risks with Team Managers and subject experts.10.7. Completing a Plan (PL)10.7.1. ObjectiveNarrative needs to be added to explain the plan, any constraints on it, external dependencies, assumptionsmade, the risks identified and their required countermeasures.The relevant management products should now be added to the plan:  Plan narrative  Plan controls10.7.2. ResponsibilitiesThe Project Manager is responsible for completing each plan, assisted by Team Managers whereappropriate, and by Project Support staff where available. Those with Project Assurance responsibilitymay wish to review that plan(s) and narrative.PRINCE2pracWeb.doc Page 43
  • 44. PRINCE210.8. Input and output Input Sub-process Ouput PL1 · Plan design · Project Approach Designing a Plan · Project Quality Plan · Corporate or programme stanndards · Project Brief (or Project Initiation Document) PL2 · Product breakdown structure · Plan design · Product Descriptions/ Defining and Analyzing · Project Quality Plan Configuration Item records products · Product Checklist · Product Flow Diagram · Product Flow Diagram PL3 · List of Activities · Product Descriptions Identifying Activities and · Activity depencies · Risk Log Dependencies · All planning information so far PL4 Estimaiting · Activity estimates (effort and duration) PL5 · Schedule Scheduling · Activity Estimates · Activity dependencies · Resource availability PL6 · Risk Log (update) · All planning information so far Analyzing Risks · Assessed plan PL7 · Product checklist (update) · Product checklist Completing a plan · Completed plan for approvalPRINCE2pracWeb.doc Page 44
  • 45. PRINCE211. THE COMPONENTSPrince2 has a number of components that are used by the processes:  Business Case  Organization  Plans  Controls  Management of Risk  Quality in a project environment  Configuration Management  Change Control11.1. Business CaseThe Business Case is a description of the reasons for the project and the justification for undertaking theproject, based on the estimated costs of the project, the risks and the expected benefits and savings.The Business Case covers the entire scope of change to the business that is affected by the project.The Business Case is the most important set of information for the project. It drives the decision-makingprocesses and is used continually to align the project‟s progress to the business objectives/benefits thatare defined within the Business Case.Business Cases need to be developed according to any organizational standard that might exist and thenature of the project. Some Business Cases will require significant effort their development and approvalbecause the project will have a major impact on the organization. Others will require less effort andinvolvement as the project is self-contained and has minimal impact on other parts of the organization.Also, the level of investment required will influence the rigour with which the Business Case is developed.The Executive is the “owner” of the project‟s Business Case. It is the Executive‟s responsibility to ensurethe project‟s objectives, costs, benefits, etc are correctly aligned with the business strategy or programmeobjectives.11.2. OrganizationA fundamental principal is that the project management structure has four layers: 1. Corporate or programme management 2. Direction of the project (Project Board) 3. Day-to-day management of the project (Project Manager) 4. Team management and product delivery (Team Managers)Prince2 provides a structure for a project management team that supports:  Roles for decision makers  Management by exception for the decision makers  Full- or part-time project management  Controlled delegation of some day-to-day management responsibilities, where required, to Team Managers  Roles for independent inspection of all aspects of project performance  Administrative support, as required, to Project Managers and Team Managers  Agreement by all concerned on what the various roles and responsibilities are  Lines of communication between the project management team membersPRINCE2pracWeb.doc Page 45
  • 46. PRINCE2 Corporate or programme management Project Board Senior User Executive Senior Supplier Project Assurance Project Manager Project Support Team Manager11.2.1. BusinessThe product(s) of the project should meet a business need. The project should give value for money.11.2.2. UserThere will be an individual, group or groups for whom or all of the following will apply:  They will use the final product  The product will achieve an objective for them  They will use the end result to deliver benefits  They will be impacted by the project outcomeThe user presence is needed to specify the desired outcome and ensure that the project delivers it.11.2.3. SupplierThe creation of the end product will need resources with certain skills. Representation is need from thesupplier who will provide the necessary skills.11.2.4. The project boardThe project board consists of three roles:  Executive  Senior User  Senior SupplierPRINCE2pracWeb.doc Page 46
  • 47. PRINCE2The Project Board is not a democracy controlled by votes. The Executive is the key decision makerbecause he/she is ultimately responsible to the business. He/she is supported by the Senior User andSenior Supplier.11.2.4.1. ExecutiveThe Executive is ultimately accountable for the project. The Executive is responsible for the followingkey aspects of the project:  Development and continuation of the project Business Case  Project organization structure and plans  Monitoring and control of progress  Problem referral  Formal closure  Post-project review11.2.4.2. Senior UserThe senior user is accountable for any products supplied by the user(s), such as making sure thatrequirements have been clearly defined and that what is produced is fit for its purpose, as well as formonitoring that the solution will meet user needs.The Senior User role is responsible for:  Providing user resources  Ensuring that the project procedures that meet user requirements  Ensuring that the products provide the expected user benefits.11.2.4.3. Senior SupplierThe Senior Supplier needs to achieve the results required by the Senior User. The Senior Supplier isaccountable for the quality of all products delivered by the supplier(s).11.2.5. Project ManagerThe Project manager is given the authority to run the project on a day-to-day basis on behalf of theProject Board within the constraints laid down by the board.The Project Manager‟s prime responsibility is to ensure that project produces the required products, tothe required standard of quality and within the specified constraints of time and cost. The ProjectManager is also responsible for the project delivering an outcome that is capable of achieving the benefitsdefined in the Project Initiation Document.11.2.6. Team ManagerThe Team Manager‟s prime responsibility is to ensure production of those products defined by theProject Manager to an appropriate quality in a timescale and at a cost acceptable to the Project Board.11.2.7. Project AssuranceAll of these points mean that there is a need in the project organization for monitoring all aspects of theproject‟s performance and products independently of the Project Manager. This is the role of ProjectAssurance.PRINCE2pracWeb.doc Page 47
  • 48. PRINCE211.2.8. Project SupportThe Project manager may need administrative help. This may stem from the sheer volume of work to bedone or mandated use of certain tools where the Project Manager has insufficient expertise, such as insupporting the use of specific panning and control software or configuration management. One specificProject Support role that must be considered is Configuration Librarian.11.3. PlansEffective planning identifies:  Whether the target are achievable  The resources needed to achieve the targets within a time frame  The activities needed to ensure that quality can be built into the products  The problems and risks associated with trying to achieve and stay within the constraintsA plan is a document, framed in accordance with a predefined scheme or method, describing how, whenand by whom a specific target or a set of targets is to be achieved.A Prince2 plan should contain the following elements:  The products to be produced  The activities needed to create those products  The activities needed to validate the quality of the products  The resources and time needed for all relevant activities (including project management and quality control) and any need for people with specific skills  The dependencies between activities  External dependencies for the delivery of information, products or services  When the activities occur  The point at which progress will be monitored and controlled  Agreed tolerances Programme Plan Project Plan Stage Plan Exception Plan Team Plan11.3.1. Project PlanAn overview of the total project is needed. The Project Plan is a mandatory Prince2 Plan. It provides theBusiness Case with project costs and is used by the Project Board as a basis against which to monitoractual costs and project progress stage by stage. The Project Plan identifies key products, resourcerequirements and the total costs. It also identifies major control points within the project, such as stageboundaries.PRINCE2pracWeb.doc Page 48
  • 49. PRINCE211.3.2. Stage PlanFor each stage identified in the Project plan, a Stage plan is required. Each Stage plan is produced near theend of the previous stage It will be the basis of the Project Managers day-to-day control.Each Stage Plan is finalized near the end of a previous stage as part of Managing Stage Boundaries (SB).This approach should give confidence in the plan because:  The Stage Plan is produced close to the time when the planned events will take place  The Stage Plan is for a much shorter duration than the Project Plan  After the first stage, the Stage is developed with knowledge of performance of earlier stages11.3.3. Team PlanTeam Plans are optional and the need fro them will be determined by the size and complexity of theproject and the number of people involved.The plans are prepared in parallel with the Stage Plan, either by subdividing the activities of the stage intotasks for which the team are responsible or by taking the plans prepared by each of the teams andassembling a Stage Plan from them.11.3.4. Stage and team quality plansStage and team quality plans should contain a quality plan which will identify the method to be used tocheck the quality of each product created/updated during the activities covered by the plan and theresources to be used for the checks.11.3.5. Exception planWhen it is predicted that a plan will no longer finish within agreed tolerances, an Exception Plan isnormally produced to replace that plan.An Exception Plan to replace a Team Plan needs the approval of the Project Manager. If a Stage Plan isbeing replaced, this needs the approval of the Project Board. Replacement of the Project Plan because ofdeviation beyond project tolerances must be referred by the Project Board to corporate or programmemanagement.11.4. ControlsThe purpose of control is to ensure that the project:  Remains viable against its Business Case  Is providing the required products, which meet the defined quality criteria  Is being carried out to schedule and in accordance with its resource and cost plansControls ensure that, for each level of the project management team, the next level up of managementcan:  Monitor progress  Compare achievement with plan  Review plans and options against future situations  Detect problems and identify risks  Initiate corrective actions  Authorize further workPRINCE2pracWeb.doc Page 49
  • 50. PRINCE2 Plan Control MonitorThe major controls for the Project Board are:  Authorizing Initiation (DP1)  Authorizing a Project (DP2)  End Stage assessment (Authorizing a Stage or Exception Plan (DP3))  Highlight Reports  Exception Reports  Exception Assessment (Authorizing a Stage or Exception Plan (DP3))  Project closure (Confirming Project closure (DP5))Project Start-up is an important prerequisite of project control. Project Start-up contains the work thatPrince2 requires to be done before the project can begin. Its functions are to:  Set up the project management team so that he Project Board and Project Manager can make the necessary initial decisions about the project.  Develop what may be a rudimentary Project Mandate into the Project Brief  Confirm the project approach  Plan the initiation stageThe purpose of project initiation is to ensure that before significant resource on the project, everyoneinvolved in the project agrees:  The project objectives  What products will be delivered  The reasons for the project  Who the customer is  Who has which responsibilities and authorities  Project boundaries and interfaces to outside world  How the objectives will be met  What assumptions have been or can be made  What major risks exists that prevent the project from achieving its objectives  When the major products will be delivered  How much the project will cost  How the project will be controlled  The division of the project into stages  How the acceptability of its products will be assertedThe most volatile parts of the Project Initiation Document are:  The Project Plan  The Business Case  The Risk LogTo summarize, the main purpose of the Project Initiation Document is to pull together information toanswer the questions: “What?, Why?, Who?, When?, Where?, How? and How much?PRINCE2pracWeb.doc Page 50
  • 51. PRINCE211.4.1. ToleranceTolerance is the permissible deviation from a plan without bringing the deviation to the attention of thenext higher authority. Corporate or Programma Management Project tolerances Project Plan deviation Project Board Stage tolerances Stage Plan deviation Project Manager Work Package tolerances Work Package deviation Team ManagerThe two standard elements to tolerance are:  Time  CostOther normal tolerance elements are:  Scope tolerance  Risk tolerance  Benefits tolerance  Quality tolerance11.4.2. Product descriptionA description of each product is written down before that product is developed or obtained, even beforeif it is planned, to ensure tat the individual people know:  Why it is needed  What it will look like  Where will it come from  The quality specification to which it must be builtIt defines the product, the standard to be used in its creation and the quality criteria to be applied to besure it is fit for its purpose.11.4.3. Work PackageA work Package is authorized by the Project Manager to trigger an individual or group to undertake apiece of work during a stage.The work package will contain the Product Description(s), constraints such as time, cost and interfaces,reporting and product handover requirements and any other documentation or products necessary forunderstanding and implementing the Work Package.11.4.4. Quality LogPRINCE2pracWeb.doc Page 51
  • 52. PRINCE2This is a record of all planned and implemented quality checks.11.4.5. Project issues and change controlEvery project must have a procedure to handle change. Without change control there is no projectcontrol.11.4.6. Risk LogA risk Log is kept of all identified risks, their analysis, countermeasures and status.11.4.7. CheckpointA checkpoint is a time-driven control when the status of work in a team is ascertained. It involves thepeople doing the work and is carried out by the Team Manager.11.4.8. Highlight ReportA Highlight Report is a time-driven report on the status of a stage‟s progress from the Project Manager tothe Project board. Minimally, it should contain statements about:  Achievements in the current period  Achievements expected in the next period  Issues and new risks and suggestions concerning their resolution11.4.9. Exception reportAn Exception Report is a warning from the one level of the project management to the next higher levelthat a serious problem exists that needs a decision such as Team, Stage or Project Plan will deviate outsideits margins.An exception reports describes a forecast deviation provides an analysis of both the exception and theoptions for the way forward and identifies the recommended option.11.4.10. End stage assessmentThe specific objectives of an end stage assessment are to:  Review the project against its Business Case and ensure that the project is still viable  Review the results of the stage against plan  Satisfy the Project Board about the quality of the products delivered  Establish that the current stage has been completed satisfactorily  Check whether any external event has changed the project‟s assumptions  Perform a risk analysis and management review of the project and the next Stage Plan and incorporate the results into the next Stage Plan and Project Plan  Review overall project status against the Project Plan (which may now have been revised)  Review the next Stage Plan against the Project Plan  Ensure that a complete and consistent baseline is established for the next stage  Ensure that the specialist aspect of the project are still sound  Authorize the passage of the project into the next stage (if the Business Case continues to be viable)11.4.11. End Stage reportThe end stage report is the vehicle through which the Project Manager informs the Project Board of theresult of a stage.The End Stage Report contains all the information to enable the Project Board to achieve the objectivesdescribed for an end stage assessment.PRINCE2pracWeb.doc Page 52
  • 53. PRINCE211.4.12. Daily LogA daily log can help a Project Manager in controlling a project.11.4.13. Lessons Learned LogIt should record any lessons, good or bad, that are learned as the project progresses. It aims to:  Provide lessons and advice that can be used to improve future planning and performance o In a later stage of this project o In future project  Improve general company standards11.4.14. Controlled CloseBefore the Project Board allows the project to close (unless the project has been prematurely terminated).It has the control that:  All agreed products have been delivered and accepted  Arrangements are in place, where appropriate, to support and maintain the products in its useful life  Any useful statistics or lessons for later projects are passed to the relevant body  A plan has been made to enable a check on the achievement of the benefit claimed in the project‟s Business Case11.4.15. Project closure notificationThe project closure notification advises all those who have provided resources, facilities or services to theproject that the project is coming to an end.11.4.16. Lesson Learned reportThe lessons learned report is created at the end of the project from the lessons learned log to disseminateuseful lessons learned during the project for the benefit of other projects.11.4.17. Follow on Action recommendationsThe follow on recommendations document any “unfinished business” and allow the Project Board todirect them to the person or group whose job it will be to have the recommendations considered foraction after the current project has ended.11.4.18. End project reportThe end project report reviews the achievement of the objectives of the Project Initiation Document.11.4.19. Post Project Review planThe pos-project review occurs outside the project, i.e. after Project Closure. Its main aim is to review thebenefits achieved by the projects products.11.4.20. StagesStages are partitions of the project with management decision points. A stage is a collection of activitiesand products whose delivery is managed as a unit.11.4.21. Review and decision pointsPRINCE2pracWeb.doc Page 53
  • 54. PRINCE2Within any project there will be key decisions, the results of which will have effects on the direction anddetailed content of the project.11.4.22. Planning horizonsUncertainty can often mean that it is only possible to plan in detail the activities and products of a limitedamount of work of the project.11.4.23. Management versus technical stagesTechnical stages are typified by the use of a particular set of specialist skills. Management stages equate tocommitment of resources and authority to spend.The Prince2 approach is to concentrate the management of the project on the management stages sincethese will from the basis of the planning and control processes described throughout the method.11.4.23.1. How to define stagesThe process of defining stage is fundamentally a process of balancing:  How far ahead in the project it is sensible to plan  Where the key decision need to be on the project  The amount of risk within a project  Too many small stages versus too few big ones11.4.23.2. How to use stagesThe primary use of stages is a basis for dictating the timing of the stage boundary processes covered byManaging Stage Boundaries (SB) and by the associated Authorizing a Stage or Exception Plan (DP3).11.5. Management of riskThe task of risk management is to manage a project‟s exposure to risk (that‟s the probability of specificrisks occurring and the potential impact if they did occur). The aim is to manage that exposure by takingaction to keep exposure to an acceptable level in a cost effective way.Risk management involves having:  Access to reliable, up to date information about risks  Decision-making processes supported by a framework of risk analysis and evaluation  Processes in place to monitor risks  The right balance of control in place to deal with those risksRisk management at the project level focuses on keeping unwanted outcomes to an acceptable minimum.11.5.1. Risk toleranceAnother name for this is „risk appetite‟. Before determining what to do about risks, the Project Board andProject Manager must consider the amount of risk they are prepared to tolerate.11.5.2. Risk responsibilitiesThe management of risk is one of the most important parts of the job done by the Project Board and theProject Manager. The Project Manager is responsible for ensuring that risks are identified, recorded andregularly reviewed. The Project Board has four responsibilities:  Notifying the Project Manager of any external risk exposure to the project  Making decisions on the Project Manager‟s recommended reactions to risk  Striking a balance between the level of risk and the potential benefits that the project may achievePRINCE2pracWeb.doc Page 54
  • 55. PRINCE2  Notifying corporate or programme management of any risks that affect the project‟s ability to meet corporate or programme objectives11.5.3. Risk ownershipAn „owner‟ should be identified for each risk; this should be the person best situated to keep on eye on it.11.5.4. The risk management cycle Risk Analysis Risk Management Identify the risks Evaluate the risks Monitor and report Identify suitable responses to Plan and resource risk Select11.5.4.1. Identify the risksThis step identifies the potential risks (or opportunities) facing the project. It is important mot to judgethe likelihood of a risk at this early time. This is done in a controlled manner in a later step. Attempting toform judgments while identifying a list of potential risks may lead to hurried and incorrect decisions toexclude some risks.PRINCE2pracWeb.doc Page 55
  • 56. PRINCE211.5.4.2. Evaluate the risksRisk evaluation is concerned with addressing probability and impact of individual risks, taking intoaccount any interdependencies or other factors outside the immediate scope under investigation:  Probability is the evaluated likelihood of a particular outcome actually happening  Impact is the evaluated effect or result of a particular outcome actually happening  Impact should be ideally considered under the elements of: o Time o Cost o Quality o Scope o Benefit o People/resources11.5.4.3. Identify suitable responses to riskPrevention: Terminate the risk - by doing things differently and thus removing the risk, where it is feasible to do so. Countermeasures are put in place that either stop the threat or problem from occurring or prevent it having any impact on the project or business.Reduction: Treat the risk – take action to control it in some way where the actions either reduce the likelihood of the risk developing or limit the impact on the project to acceptable levels.Transference: This is a specialist form of risk reduction, where the management of the risk is passed to a third party via, for this instance, an insurance policy or penalty clause, such that the impact of the risk is no longer an issue for the health of the project. Not all risks can be transferred in this way.Acceptance: Tolerate the risk – perhaps because nothing can be done at a reasonable cost to mitigate it or the likelihood and impact of the risk are at an acceptable level.Contingency: These are actions planned and organized to come into force as and when the risk occurs.11.5.4.4. Select Possibility and impact Cost of action of risk occuring11.5.4.5. Plan and ResourcePlanning for the countermeasure actions itemized during the risk evaluation activities.Resourcing which will identify and assign the actual resources to be used to conduct the work involved incarrying through the actions.PRINCE2pracWeb.doc Page 56
  • 57. PRINCE211.5.4.6. Monitor and reportThere must be mechanisms in place for monitoring and reporting n the actions selected to address risks. Input from corporate or programme management Project SU4 SU5 approach Project Mandate Preparing a Project Defining a project Project Brief Brief Approach DP1 Authorising initaition IP3 Project Plan Refining the Project Initiation document Business case and risks DP2 Authorising a Project SB4 Stage Plan DP4 PL6 Updating the Risk Giving ad hoc Analysing risks Direction Log DP3 Exception Authorising a report Stage or CS6 Exception plan Reporting Highlights CS8 CS1 Escalating project text Authorising a work issues package CS4 Examining Project issues CS5 MP1 Reviewing Stage Risk Log Accepting a Team plan Issue Log Status workpackage Risk Log CP2 Identifying Follow on actionsPRINCE2pracWeb.doc Page 57
  • 58. PRINCE211.6. Quality in a project environmentWithin project quality is a question of identifying what it is about the project‟s products or services thatmakes them fit for their purpose of satisfying stated needs.Quality management is the process of ensuring that the quality expected by the customer is achieved.Project quality planning should cover the following aspects to ensure that the project delivers to anacceptable level of quality:  How each product will be tested against its quality criteria  When each product will be tested against its quality criteria  By whom each product will be tested against its quality criteria  How acceptance will be notified11.7. Configuration ManagementNo organization can be fully efficient or effective unless it manages its assets, particularly if the assets arevital to the running of the organization‟s business. The assets of the project are the products that itdevelops and these also have to be managed.Configuration management is a discipline that gives control over the project‟s products by allowingmanagement to:  Specify the versions of the products in use and in existence and hold information on: o Their status o Who own each product o The relationship between products  Maintain up-to-date records containing these pieces of information  Control changes to the products by ensuring that changes are only made with the agreement of appropriate authorities  Audit the records to ensure that they contain authorized products and only these productsWithin a project the job of configuration management is to provide:  The mechanism for managing, tracking and keeping control of all the project‟s products once they have been quality controlled, controlling access to them and maintaining records of their status.  Safe and secure storage of each product in the way most appropriate for that product  The ability to select and package the various components that comprise the final working product  A system for logging, tracking and filling all Project issues.Configuration Management contributes to the economic provision of quality products:  By making the management of changes and upgrades to a product cheaper and less error prone  By helping to identify products that may be affected by problems in related products  By checking which versions of products the user is using or connected to, whether products in use are authorized, whether products have been affected by changes and which other related products might be the cause of any problems.A baseline is a snapshot of a product and any component products, frozen at a point in time for aparticular purpose.A release is a complete and consistent set of products that forms a fixed reference point in thedevelopment of the end outcome.PRINCE2pracWeb.doc Page 58
  • 59. PRINCE2Configuration management consists of five basic functions: 1. Planning: deciding what level of configuration management will be required by the project and planning how this level is to be achieved. 2. Identification: specifying and identifying all components of the final product 3. Control: the ability to agree and baseline products and then to make changes only with the agreement of appropriate named authorities 4. Status accounting: the recording and reporting of all current and historical data concerning each product 5. Verification: a series of reviews and configuration audits to ensure that the actual status of all products matches the authorized state of products as registered in the configuration management records.The configuration management plan defines:  How and where the products will be stored  What filling and retrieval security will be  How the products and various versions of these will be identified  Where the responsibilities for Configuration Management lieConfiguration control is concerned with physically controlling receipt and issue of products, keeping trackof product status, protecting finished products and controlling any changes to them.11.8. Change controlThe control of change means the assessment of the impact of potential changes, their importance, theircost and a judgmental decision by management on whether to include them or not. Any approvedchanges must be reflected in any necessary corresponding change to schedule and budget.A request for change, which, for whatever reason, will cause a change to the specification or acceptancecriteria of the Project or one of the Project‟s products. Any additional cost to carry out the change willnormally have to be funded by the customer.An Off-specification, covering errors or omissions found in work already conducted or planned for thefuture, which will result in agreed specification or acceptance criteria not being met. Additional cost tocarry out his work fall on any suppliers involved.PRINCE2pracWeb.doc Page 59