PRINCE2 Foundation Booklet - mplaza.pm · PRINCE2® Foundation Booklet By Frank Turley PRINCE2...

PRINCE2®FoundationBooklet

ByFrankTurley

PRINCE2 Foundation online course booklet

Ver 0.5

PRINCE2® 2017 Foundation Booklet ii

Colophon Title: PRINCE2® Foundation Booklet Authors: Frank Turley Expert reviewers: Nader K. Rad, Eralp Tezcan, Rouzbeh Kotobzadeh Edition: First edition, first impression, December 2017 Copyright: © Professional Training Centre of Excellence N.V. (PTCoE) ITIL®, PRINCE2®, PRINCE2 Agile®, MSP®, M_o_R®, P3O®, MoP® and MoV® are registered trademarks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved. The Swirl logo is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved. Although this publication has been composed with most care, neither Author nor Editor nor Publisher can accept any liability for damage caused by possible errors and/or incompleteness in this publication.

Thank you for reading this PRINCE2 Foundation Booklet. The main objective of this booklet is to provide an easy-to-read overview of the PRINCE2 Foundation online training. This booklet should not be used on its own, it is just meat to provide a summary of PRINCE2 and supports the PRINCE2 online training.

The online PRINCE2 course cover the full PRINCE2 Foundation syllabus

While most people will just use the online training, some people like to have summary document to read over, so this booklet is for you.

PRINCE2® 2017 Foundation Booklet iii

Table of Contents 1 Introduction – PRINCE2 ...................................................................................................... 12 PRINCE2 and project management .................................................................................... 3

2.1 Five characteristics of a project ............................................................................... 32.2 PRINCE2 project variables ...................................................................................... 3

2.3 Projects in context .................................................................................................... 42.4 Projects in a commercial environment ..................................................................... 42.5 PRINCE2 Foundation exam and syllabus ................................................................ 5

2.6 What you need to know ........................................................................................... 53 Principles ............................................................................................................................. 64 Themes introduction ............................................................................................................ 9

4.1 Introduction to themes ............................................................................................. 94.2 List of themes ........................................................................................................... 9

5 Business case theme ......................................................................................................... 10

5.1 Introduction ............................................................................................................ 105.2 Output, outcomes, and benefits ............................................................................. 105.3 Minimum requirements for the business case ....................................................... 105.4 The business case path ......................................................................................... 125.5 Business case example: ........................................................................................ 145.6 Roles and responsibilities ...................................................................................... 145.7 What you need to know ......................................................................................... 14

6 Organization ...................................................................................................................... 156.1 Introduction ............................................................................................................ 15

6.2 Three project interests / three stakeholder categories ........................................... 156.3 The four levels of a project organization ................................................................ 166.4 PRINCE2 minimum requirements for organization ................................................ 17

6.5 Project roles and responsibilities ........................................................................... 176.6 The communication management approach (CMA) document ............................. 206.7 Roles and responsibilities ...................................................................................... 21

6.8 What you need to know ......................................................................................... 217 Quality ................................................................................................................................ 22

7.1 The quality knowledge provided by PRINCE2 ....................................................... 227.2 Quality definitions ................................................................................................... 227.3 Introduction to the PRINCE2 approach to quality .................................................. 227.4 Part 1: Quality planning introduction ...................................................................... 23

7.5 Part 2: Quality control ............................................................................................ 24

PRINCE2® 2017 Foundation Booklet iv

7.6 Quality documents ................................................................................................. 24

7.7 PRINCE2 minimum requirements for quality ......................................................... 267.8 Project assurance vs quality assurance ................................................................. 267.9 Roles and responsibilities ...................................................................................... 27

7.10 What you need to know ......................................................................................... 278 Plans .................................................................................................................................. 28

8.1 Introduction ............................................................................................................ 28

8.2 Plans definitions ..................................................................................................... 288.3 Three levels of a plan ............................................................................................. 288.4 Planning overview .................................................................................................. 298.5 Exception plan – if out of tolerance ........................................................................ 308.6 Product-based planning steps ............................................................................... 308.7 Product-based planning steps 1 to 7 ..................................................................... 31

8.8 Number and length of management stages ........................................................... 328.9 Delivery steps vs management stages? ................................................................ 328.10 PRINCE2’s requirements for the plans theme ....................................................... 338.11 Roles and responsibilities ...................................................................................... 348.12 What you need to know ......................................................................................... 34

9 Risk Theme ........................................................................................................................ 359.1 Purpose of the risk theme ...................................................................................... 359.2 Risk definitions ....................................................................................................... 359.3 Risk management products ................................................................................... 359.4 The recommended PRINCE2 risk management procedure .................................. 369.5 Step 1: Identify ....................................................................................................... 369.6 Step 2: Assess risk ................................................................................................ 37

9.7 Step 3: Plan the responses .................................................................................... 389.8 Step 4: Implement the responses .......................................................................... 399.9 Step 5: Communicate ............................................................................................ 39

9.10 What is a risk budget? ........................................................................................... 399.11 PRINCE2 requirements for risk management ........................................................ 409.12 Roles and responsibilities ...................................................................................... 409.13 What you need to know ......................................................................................... 40

10 Change .............................................................................................................................. 4110.1 Purpose of the change theme ................................................................................ 4110.2 Change definitions ................................................................................................. 4110.3 Types of issues ...................................................................................................... 4110.4 The PRINCE2 approach to change ....................................................................... 42

PRINCE2® 2017 Foundation Booklet v

10.5 How to prioritize issues and track severity ............................................................. 42

10.6 Change authority and change budget .................................................................... 4210.7 Management products used by the change theme ................................................ 4210.8 Issue and change control procedure ...................................................................... 44

10.9 PRINCE2 minimum requirements for change control ............................................ 4610.10 Roles and responsibilities ...................................................................................... 4710.11 What you need to know ......................................................................................... 47

11 Progress ............................................................................................................................ 4811.1 Purpose of the progress theme .............................................................................. 4811.2 Progress definitions ............................................................................................... 4811.3 PRINCE2 requirements for approach to progress ................................................. 4811.4 Types of control ..................................................................................................... 5011.5 How does the project manager review progress? .................................................. 50

11.6 Raising exceptions ................................................................................................. 5211.7 Using stages to control the project ......................................................................... 5211.8 Roles and responsibilities ...................................................................................... 5211.9 What you need to know ......................................................................................... 52

12 Starting up a project ........................................................................................................... 5312.1 Purpose of the SU process .................................................................................... 5312.2 Objectives of the SU process ................................................................................. 5312.3 Project mandate ..................................................................................................... 5312.4 SU activities ........................................................................................................... 5312.5 SU input / output diagram ...................................................................................... 5412.6 Roles and responsibilities ...................................................................................... 5512.7 What you need to know ......................................................................................... 55

13 Initiating a project ............................................................................................................... 5613.1 Purpose of the IP process ...................................................................................... 5613.2 Objectives of the IP process .................................................................................. 56

13.3 IP activities ............................................................................................................. 5613.4 IP inputs and outputs ............................................................................................. 5713.5 Roles and responsibilities ...................................................................................... 5813.6 What you need to know ......................................................................................... 58

14 Directing a project .............................................................................................................. 5914.1 Purpose and objectives of directing a project ........................................................ 5914.2 DP activities ........................................................................................................... 5914.3 DP inputs and outputs ............................................................................................ 5914.4 Roles and responsibilities ...................................................................................... 60

PRINCE2® 2017 Foundation Booklet vi

14.5 What you need to know ......................................................................................... 60

15 Controlling a stage ............................................................................................................. 6115.1 Purpose and objectives of controlling a stage ....................................................... 6115.2 CS activities ........................................................................................................... 61

15.3 CS inputs and outputs ............................................................................................ 6215.4 Roles and responsibilities ...................................................................................... 6215.5 What you need to know ......................................................................................... 62

16 Managing product delivery ................................................................................................. 6316.1 Purpose and objectives of the MP process ............................................................ 6316.2 Managing product delivery activities ...................................................................... 6316.3 MP inputs / outputs ................................................................................................ 6316.4 Roles and responsibilities ...................................................................................... 6416.5 What you need to know ......................................................................................... 64

17 Managing a stage boundary .............................................................................................. 6517.1 Purpose and objectives .......................................................................................... 6517.2 SB activities ........................................................................................................... 6517.1 SB inputs and outputs ............................................................................................ 6517.2 Roles and responsibilities ...................................................................................... 6617.3 What you need to know ......................................................................................... 66

18 Closing a project ................................................................................................................ 6718.1 Purpose and objectives .......................................................................................... 6718.2 Closing a project activities ..................................................................................... 6718.3 CP inputs and outputs ............................................................................................ 6718.4 Roles and responsibilities ...................................................................................... 6818.5 What you need to know ......................................................................................... 68

PRINCE2® 2017 Foundation Booklet 1

Based on AXELOS PRINCE2® material. Reproduced under license from AXELOS. All rights reserved. Some material in this document has been sourced from Managing Successful Projects with PRINCE2® 2017 Edition. No part of this document may be reproduced in any form without the written permission.

1 Introduction – PRINCE2

The PRINCE2 Foundation Booklet The objective of this official PRINCE2 foundation booklet is to support the PRINCE2 online foundation course and provide an overview of the PRINCE2 Foundation syllabus. The majority of people will not need to use this booklet after watching the online training, but some people like to have a blended approach to learning (watching, reading and quizzes).

What are projects?: Here are a definition from Wikipedia A project is a unique series of actions designed to accomplish a unique goal within specific

time and cost limitations.

PRIINCE2 definition: A project is a temporary organization that is created for the purpose of delivering one or more

business products according to an agreed business case.

• The word organization refers to the project team (people involved in the project) • The word temporary refers to the fact that each project as a definite start and end date. • The business case includes: reasons for the project, expected benefits, costs and time

What is PRINCE2? PRINCE2 is a project management method that can be used for any project, from running a 1 day event to interfering in the US elections to help elect an idiot J.

Benefits of using PRINCE2 There are numerous advantages to using PRINCE2 (like most methods).

1. Best practice: PRINCE2 has been around more than 40 years in many thousands of projects, and it learns from these projects.

2. PRINCE2 can be used for all kinds of projects

3. PRINCE2 provides a structure for roles and accountability meaning that all should know what is expected of them and what they can expect from others.

4. PRINCE2 is product-focused, meaning that products are well-defined before work begins.

5. PRINCE2 uses Management by Exception. This allows each layer to get on with their work and only escalate if needed. More on this later.

6. PRINCE2 assess the viability of the project from a business case from start to finish.

PRINCE2 structure (elements) PRINCE2 consists of 4 main parts, (also referred to as elements or integrated elements). These elements are: Principles, Themes, Processes, and Tailoring.



• Principles: Each project should consist of all 7 PRINCE2 principles

• Themes: Themes are knowledge areas: e.g., business case, organization, quality…

• Processes: Processes provide information on the activities that are carried out during the project and by whom. There are seven processes

• Project environment: All projects need to be tailored to suit the project environment.

What you need to know • Recognize the PRINCE2 definition of a project • List the 4 integrated PRINCE2 elements (integrated elements) • Recognize the benefits of using PRINCE2 (and how wonderful you are to be studying it J)

You don’t need to be able to remember all the information in this book, you just need to be able to recognize it in the multiple questions.

Principles

Procesess

Themes

Projectenvironment



2 PRINCE2 and project management 2.1 Five characteristics of a project

Projects have a number of characteristics, which is how projects differ from business as usual or a repeating process. You should be able to see these characteristics in all projects.

Change: Projects are a way to introduce change. Example: A new service

Temporary: A project should have a definite start and end.

Ongoing maintenance of a product is after the project

Cross- Functional:

A project teams includes people from different silos (departments) and level of seniority that work together for the duration of the project.

Unique: All projects are unique. There is always something note done before

Uncertainty: As parts of the project are unique, you can never 100% sure how it is going to work out useless you have a glass ball.

2.2 PRINCE2 project variables The two most common variables to control in a project are time and cost. There are 6 variables (performance targets) to control in a project and these are: Timescales, Costs, Quality, Scope, Benefits, and Risk. Also known as: 6 aspects of project performance.

Tip to remember them: Use TeCQuila SoBeR. This will give you Timescales, Costs, Quality, Scope, Benefits, and Risk. Or you can use: “BC QRST.”

The above image shows a dial for each of the 6 performance targets, and the project manager will keep monitoring these during the project. In fact, the PM can just present this diagram (project cockpit) to anybody who wants to know how the project is going.

Time Cost Benefits

Scope Quality Risk

ProjectCockpit



Timescales “When will the project be finished?”

Cost Projects need to give a return on investment and costs need to be controlled.

Quality Are products passing their quality checks and will users be able to use the project product as expected when delivered

Scope Is the scope clear to all stakeholders? First scope document is the PPD

Benefits Excepted benefits must be known, agreed and measurable.

Risk All projects have risk, so risk needs to be managed so the project has a better chance to succeed.

2.3 Projects in context PRINCE2 assumes that each project will have a customer and a supplier.

- The customer specifies the desired result (requirements) and perhaps pay for and use the business products delivered by the project.

- The supplier will provide resources, knowledge and skills to deliver the desired products.

The requests for projects come from somewhere outside the project. e.g.: 1) a programme, 2) upper management (corporate), or 3) a customer. PRINCE2 refers to the level in the organization that commissions a project as “corporate, programme management, or the customer” (CPC).

2.4 Projects in a commercial environment Contracts between Customer / Supplier Some projects can use a formal contract which will detail the customer’s requirements (product descriptions) and what the supplier must deliver to satisfy the contract. This contract can include the following information:

• Overview of the project approach (or product approach) • How progress reporting will be done and frequency • Roles and responsibility of the customer (customer must be involved) • Procedure for dealing with change requests • Procedure for reporting issues to the project manager • How products will be tested and accepted and role of quality register, etc.

In larger projects, there may be many subcontract supplier and therefore many contracts. • Contracts between the customer and all suppliers directly OR • Between the customer and a prime supplier which will have contracts with all subcontractors

Each supplier may have their own way of viewing the project and they will have their own: • reasons for doing the project (so their own business case)

Portfolio

Projects

ProjectsStandaloneprojects

ProgrammeXY

Projects

ProgrammeERP



• procedures for running projects (they don’t have to use PRINCE2) • procedures for making decisions (governance) and organization structure • project management culture (e.g., behaviors, cultures, risk appetite)

2.5 PRINCE2 Foundation exam and syllabus Here is some information on the PRINCE2 Foundation exam: (AXELSOS)

Time: 1 hour (Extra time is available who have English as a 2nd language) Questions: 60 questions Type: Multiple choice (A, B, C, D) Pass Rate: 55% pass mark (33 questions)

The PRINCE2 Foundation level aims to measure whether a candidate can participate in a PRINCE2 project. Therefore, the candidate must show they understand the following:

• The seven PRINCE2 principles and how they are applied • The characteristics and context of a project and the benefits of using PRINCE2 • The purpose of the PRINCE2 roles, management products, and themes • The purpose, objectives, and context of the seven PRINCE2 processes

2.6 What you need to know • Recognize the 5 characteristics of a typical project and understand them • Recognize the 6 aspects of project performance (Tip: TeCQuila SoBeR or BC QRST) • Recognize that PRINCE2 projects happen in a customer/supplier context • Be aware of the type of information that may be included in a contract between a customer

and supplier. (eg: roles and responsibilities, reporting, acceptance procedure). • Be aware that each supplier can have their own view on the project (their own business

case)



3 Principles Introduction to principles

Each PRINCE2 project should include the 7 principles and you can also use the principles to do a quick health check on your project e.g. 1) Does the project have a business case? 2) Is the project learning from experience?

What is a principle? A principle is a core value that must always exist in a PRINCE2 project.

Continued business justification Must be a business reason for doing the project

Learn from experience Learn from other projects, people and stages

Define roles and responsibilities Everybody needs to know what is expected of them

Manage by stages Break projects up into stages (chunks)

Manage by exception Give people some tolerance to work within

Focus on products Create the product descriptions before starting work

Tailor to suit the project environment Make PRINCE2 fir your project size and type of project. Use only parts of PRINCE2 that bring value.

Principle: Continued business justification A PRINCE2 project must have business justification; therefore, each project should have a business case and must be value for money. So there must be a business reason to start and continue with a project and there must be a clear Return on Investment.

“Does the project have business justification?” = “Does the project have a valid business case?”

If at any time during the project, the expected Return on Investment falls (for example, by about 80%), then the project will most likely be stopped.

The business case document details the full business case, showing why the project should be done, the costs, the expected benefits, and timescales. This information is also referred to as the business justification information. The business justification is checked throughout the lifetime of the project. E.g., at the end of each stage.

Principle: Learn from experience PRINCE2 projects should learn from previous projects and should take the necessary initiative to uncover lessons from previous projects and experience and take these into. It is the responsibility of everyone involved with the project to seek lessons and the PM should remind everyone.

Projects are unique, meaning that there is always something new and therefore all project can learn from other people. “Learn from experience” covers the full lifetime of the project, from the SU to the CP process. All lessons learned during the project should be documented and these should be passed on so they are available for future projects. The project board should also have for proof that the project is learning from lessons.

Principle: Defined roles and responsibilities In any project, people need to know what is expected from them and what they can expect from others. A PRINCE2 project should have defined and agreed roles and responsibilities. Each project should have a clear team structure and this needs to be known and accepted.

A PRINCE2 project has 3 primary stakeholders:

• Business sponsors: They mace sure that the project delivers value for money (Executive)



• Users: They will use the project products and receive the benefits. • Suppliers: They provide the resources and expertise to produce the products.

These 3 primary stakeholders must be represented in the project management team description and in the project board. So this principle answers the questions “What is expected of me?”, “What can I expect from others?” and “Who makes what decisions?”

Principle: Manage by stages How do you eat an elephant? one bite at a time (this is just an expression). How do you do a large project? one stage (chunk) at a time. PRINCE2 refers to these chunks as stages (management stages). A PRINCE2 project should be planned, monitored, and controlled on a stage-by-stage basis and each stage is separated by a project board decision.

At the end of each stage, the project board should assesse the performance of the last stage by reading the end project reports and checking the business case and stage plan for the next stage. They will then decide to proceed to the next stage or stop the project.

If the project board wish to have more control over the project, the increase the number of stages so they have more control points and more work. Some advantages of stages are:

1. Allow the project to be divided into pieces which are easier to manage

2. Have a very detailed stage plan and a high-level project plan for the whole project 3. Use lessons from previous stages in future stages

Principle: Manage by exception Each layer (CPC, direction, management) wish to manage the level below them but still give them some room to work and make decisions and manage by exception is use for this. The layer below gets on with their work and notifies the above layer if there is a big issue (exception) that is outside their tolerance. So an Exception is a big issue that takes a level out of their agreed tolerance.

Imagine you are sitting on the project board and of all is going OK with the PM you will just get normal reports. If the PM hits a big issue, then they will contact the project board immediately as this big issue is an exception. The definition for Manage by Exception is: A PRINCE2 project has defined tolerances for each project objective to establish limits of delegated authority.

PRINCE2 lists 6 tolerances that can be set. Time, Cost, Quality, Scope, Risk, and Benefits. Both time and cost are easy to understand so I will just comment on the other four.

• Tolerance quality: e.g. Power button on smartphone to work for 10 with a tolerance of ±5%. • Tolerance scope: Projects can use MoSCoW to decide on scope • Tolerance benefits: These are benefits for the project stakeholders. • Tolerance risk: Risks can be assigned values and can be escalated if > a certain value.

Mange by Exception provides the above management layer with a system to manage and control the lower management layer.

Principle: Focus on products If a product requirements are not correctly defined, then all project stakeholders can have a different idea on what the product should be. This will cause a lot of issues during the project and most likely produce an end product that cannot be used.

Detailed product descriptions of the products will help build correct expectations and make life easy for the teams who deliver the products. A PRINCE2 project should focus on the definition and delivery of products, in particular, their quality requirements.



A detailed product description also makes it easier for the team managers to determine resource requirements, dependencies, and activities. The focus on products principle states that a product description with quality requirements should be written as soon and as clearly as possible.

Principle: Tailoring or tailor to suit the project environment No projects are 100% the same and each PRINCE2 project should be tailored to suit the project’s size, environment, complexity, importance, capability, and risk.

The purpose of tailoring is to:

• Ensure that the project method is project’s environment into account. (i.e., if working in a financial environment, then align it with the existing management structure).

• Ensure with the project board that the project’s controls are based on the project’s scale, complexity, importance, capability, and risk.

What you need to know Expect 2 to 3 questions on principles. So, make sure you have an understanding of each principle, so that you will:

• Be able to recognize the principle names if mentioned • Have a basic understanding of each principle • Know how many principles each PRINCE2 project should have



4 Themes introduction 4.1 Introduction to themes

Themes are knowledge areas; they are the parts of the project that need to be continually addressed throughout the project lifecycle. Each theme provides knowledge (how to go about) on a specific area of project management, such as the business case, planning, quality, risk, etc.

Themes should also be tailored to suit the project and only use what is required to do the project. This will of course depend on the project and the environment you are working in. For example, if you are building a lunar module, then quality and risks themes would be used in detail.

The PRINCE2 processes address the flow of the project, in other words, the processes guide you through the typical activities that you need to do to run a project.

4.2 List of themes Theme Question Answered Business case Why? ROI? Benefits? Organization Who? Responsibilities? Quality Level of quality for each product characteristic? Plans How? How much? When? What (Product description)? Risk What if X happens? Change How to deal with changes requests and issues? Progress Where are we now compared to the plan, show progress

Tailoring the themes All 7 themes should be tailored according to the risk, scale, nature, complexity, or simplicity of the project so. Each PRINCE2 theme specifies minimum requirements for each theme.

Note: Tailoring is covered in the PRINCE2 Practitioner syllabus so you don’t need to know much (this is all) any more about tailoring the themes for the Foundation syllabus



5 Business case theme

5.1 Introduction The business case theme provides information to help the project make better decisions regarding the business case. The purpose of the business case theme is “to provide a structure to judge whether the business case is desirable, viable, and achievable.”

• Desirable: Determine if the output is really required by the users • Viable: Is it technically possible to deliver this product? • Achievable: Is it possible to deliver the future benefits?

Business justification means that there should be valid business reason for doing the project and this reason remains valid throughout the project. If the business case becomes, then the project should be shut down. The business case is used to document the business justification.

5.2 Output, outcomes, and benefits PRINCE2 introduces the terms: “Output, Outcome, and Benefits.” which help to describe what we get from a project. I will use a question to help explain what these mean.

Output question What product that will be delivered by the project?

Outcome question What can the users do better when using this product (features)?

Benefits question What are the measurable improvements of using this product?

Output: These are the products that the users will use and why the project was started.

Outcome: An outcome is the result of the change derived from using the project's outputs. Outcomes describe what users can do better; e.g., faster reporting or better-looking reports.

Benefits: Benefits are the measurable improvements resulting from an outcome that is perceived as an advantage by one of the stakeholders.

Dis-benefit: A dis-benefit is an outcome that is seen as negative by one or more stakeholders.

• One admin person will lose their job due to the new sales system. • 1% of clients may not like the new way of working automation and stop their contract.

5.3 Minimum requirements for the business case PRINCE2 has the following minimum requirements for the business case: • Document the business justification (business case) for the project • Keep the business justification updated during the project as the following may change:

o Desirability: Check if output is still required o Viability: Check if still technically possible to create the output

Outputs(akaProducts)

Benefits(anddis-benefits)

Outcomes(akaResults)

Sales SystemEasier to create reportsQuicker searchersEasier to import data

30% reduction in sales costs15% increase in sales20% reduction in admin costs



o Achievability: Check if benefits are still possible to realize

• Define the follow up actions in the benefits approach document that will ensure the following: o The project outcomes will be achieved (meet expectations) o The benefits will be realized

• Define the business case roles and responsibilities and benefits management. The two required business case released documents are:

1. Business case

2. Benefits management approach

The business case The business case document contains the information to allow the management to judge if a project is desirable, viable, and achievable. The business case is normally developed at the start of the project (SU process) by the executive unless it is provided by corporate, programme, or customer. Once created, it is then updated throughout the project.

The benefits management approach The purpose of the benefits management approach is to define benefits actions and benefits reviews that will take place to ensure that the project’s outcomes are achieved and to confirm that the project’s benefits are realized.

The typical contents of a business management approach document are:

• Persons who are accountable for the expected benefits (e.g., senior user) • The required actions to ensure that the project’s outcomes are achieved • How to measure expected benefits (benefits must be measurable) • Timeline of when benefits can be measured • Resources that are needed to check benefits (e.g., a person from the finance department) • Baseline measures from the start of the project so they can be compared in the future.

o e.g., support costs are €65,000 o e.g., average sales increase per year for 5 years: 4%

Business case: develop, maintain, and verify The steps for creating and keeping the business case updated are:

1. Develop business case (SU & IP process) o The outline business case is created in the starting up a project process o This is expanded into the business case in the IP process

2. Maintain business case o Keep the business case up to date (each SB process)

• Executivesummary• Reasonsfortheproject• Expectedbenefits&dis-benefits• Timescale• Costs• Options(approach)• Investappraisal(ROI)• Majorrisks

BusinessCase



3. Verify business case o Check and verify that the business case makes good business sense o The business case is verified throughout the project by the project board.

Confirm benefits Confirm the benefits is checking that the intended benefits have been realized. Confirming benefits will mostly happen after the project, but in some projects benefits may be realized during the project.

5.4 The business case path Pre-project: Project mandate

- The project brief may already contain some business case information - E.g., if the project is triggered from a programme or portfolio

SU process: Outline business case - The executive is responsible for creating the outline business case - The project manager may provide the executive with assistance. - This does not have to be a very detailed document (just an estimate).

IP process: business case - The outline business case is expanded into a more detailed business case document. - Some important inputs for the business case are:

1. The project time and costs estimates are taken from the project plan 2. A summary of the benefits from the benefits management approach (BMA)

IP process: benefits management approach (BMA) - The project manager will document the benefits (plus current status) and the actions that

will be put in place that will help to ensure that benefits will be realized. - The expected benefits information will be provided by the senior user. - A summary of the expected benefits will be copied to the business case document.

Pre-Project Initiation Delivery Stages Final Stage

Verify outline Business Case

Verify updated Business Case

Maintain business case

Verify detailed Business Case

OutlineBusinessCase

BusinessCase

Develop business case

BusinessCaseBusinessCase

UpdatedinSB

Pre-Project Initiation Final Stage Post-Project

BMABMA BMA BMA

ConfirmBenefits

Delivery Stages

Create BenefitsReview Plan Confirm

BenefitsIf realized during the

project

Confirm Benefits

If realized during the project



SB process: Update the business case - After each stage, the business case is updated to reflect changes. E.g.:

o The costs of the project may decrease or increase. o The forecasted estimated time to complete the project may be lengthened.

- The project board will then review the business case at the end of each stage.

SB process: Update the benefits management approach - Some products have already been made available to users, and then we can already check

if users are able to benefit from using the product so far.

CP process: Final update the business case - We only know the true cost of a project at the end of the project. - The business case at the end of the project can also be compared to business case at the

start of the project to judge the performance of the project.

CP process: Update the benefits management approach - Some projects may deliver products during the project, so expected benefits can be realized

and these can be confirmed. - The PM will also plan the benefits review meetings that will take place after the project is

complete and project board will check that this is done.

ProjectBoard

ProjectManager

SU

OutlineBusinessCase

StagePlan

DP?

IP

ProjectPlan

Business Case

BenefitsM.A.

Registers

StagePlan

SB

??

MP

CS

StagePlan

SB

EndStageReport

Business Case

ProjectPlan

?

MP

SB

Business Case

ProjectPlan

ExceptionPlan

ExceptionReport

CS

?

CP

EndProj Report

BenefitsM.A.

Business Case

ProjectPlan

?

Etc.Etc.

BenefitsM.A

BenefitsM.A



5.5 Business case example: This example is from the sample PRINCE2 project: “U2 Driving School.”

5.6 Roles and responsibilities Role Responsibilities CPC • Project mandate is provided by CPC (contain reasons…)

• They are interested in the expected benefits Project board • Verifies the business case (at each decision point) Executive • Responsible for the business case and securing funding for the project

• Responsible for the benefits management approach the project • Ensures the project is value for money and remains value for money

Senior user • Specifies the benefits and ensures the benefits will be realized Project manager • Creates the business case and keeps it updated (maintains it)

• Examines the effect of issues and risks on the business case • Keeps the benefits management approach up to date

5.7 What you need to know • Recognize the purpose of the business case theme and the purpose of the business case

and benefits management approach • Recognize the difference between an Output, Outcome & Benefit • Describe the minimum requirements for the business case theme • Describe what is meant by “maintain and develop the business case” • Describe what is meant by “confirm the benefits” • Be aware of the roles and responsibilities (mainly, PM, senior user and project board)

- Salesarefalling4%eachyear- CreatefreeonlineDrivingTestExamSimulator- Increasesocialmediaexposure- Needtoincreasesales

2. Reasons

- Increasesalesby10%forthreeyears- Increasesocialmediapostsby100%

4. Expected Benefits

- Donothing:Andcontinuetoloose4%eachyear- Bigmarketingcampaign:Toocostly- Createonlinedrivingtestexamsimulator*

3. Options

6. Costs

Otherdrivingschoolsmaydothesame8. Major risks

- CreatefreeonlineDrivingTestExamSimulator- Increasesalesby10%forthreeyears

1. Executive Summary

YearlyCosts Year1 Year2 Year3Cost:Hosting&Software €420 €420 €420WebsiteSetup(48hours) €6,700 €0 €0WebsiteSupport(yearly) €950 €950 €950TotalCosts €8,070 €1,370 €1,370

Project- ROI Year1 Year2 Year3

10%increasepermonth €1,512 €1,663 €1,82910%increaseperyear €18,144 €19,956 €21,948Totalcostsperyear €8,070 €1,370 €1,370ExpectedBenefits €10,074 €18,586 €20,578

7. ROI / Investment appraisal

BusinessCase Date:Document: Author: Executive Jan4th



6 Organization

6.1 Introduction The purpose of the organization theme is to help define and establish the project's structure of accountability and responsibilities. PRINCE2 states that a project is based on a customer/supplier environment where one party is the customer, who will specify the results and most likely pay for the project (and use the products), and the other party is the supplier, who will provide the resources, do the work, and deliver the required products.

PRINCE2 states that a project team should:

1. Have correct business, user, and supplier representation 2. Have defined responsibilities for directing, managing, and delivering the project 3. Have regular reviews (end of each stage) of the project to check that all is on track 4. Have a good communication flow to and from stakeholders

So each project needs to have direction, management, control, and communication.

Stakeholder: A stakeholder is any person or group that can be affected by the project or can affect the project. This includes the project team, potential users and other persons external to the project as well as those who may be negatively affected.

Note: A stakeholder may be internal or external to the corporate organization.

6.2 Three project interests / three stakeholder categories A PRINCE2 project has 3 primary categories of stakeholders (3 primary stakeholders) which should also be represented in the project board. These are business, user, and supplier.

Business interests: The executive role on the project board looks after the business interests. There must be a business case; otherwise, the project should not start. The executive should keep asking: “Is this project value for money?”

User interests: Users must be represented in the project as they: - benefit from the delivered products as they will use the products - can also operate, maintain, or support the project outputs

The users help to describe their requirements and they are represented in the project board by the senior user role which can be one or more persons.

Supplier interests: The supplier provides the skills and resources to create the products. The supplier wishes to make sure they can deliver the products as requested and get paid.

User Supplier

Business



6.3 The four levels of a project organization The PRINCE2 project management structure has 4 levels, and the project management team has 3 levels. The 4 levels of a project management structure / project organization are as follows:

The corporate, programme management, or customer (CPC) level sits above the project management team. The 3 levels of the project management team are:

Level: Corporate, programme management, or customer • This CPC level is responsible for commissioning the project and identifying the executive. • The CPC decide the project tolerances that the project board will work within.

Directing level: Project board They directing the project and are accountable for the success of the project. They,

1. Approve all project resources and plans, e.g., project plan, stage plans 2. Authorize any deviation if stage tolerances are forecast to or have exceeded 3. Approve the completion of each stage and authorize each new stage (after SB process) 4. Communicate with stakeholders outside the project which includes the CPC.

Managing level: Project manager (PM) The PM is responsible for the day-to-day management of the project and to ensure that the project produces the required products in accordance with the project objectives, which are time, cost, quality, scope, risk, and benefits.

Delivery level: Team manager The Team manager is responsible for delivering the project’s products at a certain quality and within a specific timescale and cost. A team manager can have the authority and responsibility of creating plans and managing a team to create and deliver the required products.

The process managing product delivery is where the teams produce the specialists' products.

DirectionLevel

ManagementLevel

DeliveryLevel

Corporate, programme management or customer

Project Board(they make decisions)

Project Manager(day to day runs the project)

Team Manager(creates the products)

1

2

3

4

DirectionLevel

ManagementLevel

DeliveryLevel

Project Board(they make decisions)

Project Manager(day to day runs the project)

Team Manager(creates the products)

1

2

3



6.4 PRINCE2 minimum requirements for organization A PRINCE2 project must do the following:

- define its organization structure - define the PRINCE2 responsibilities (use the ones provided by PRINCE2) - agree on the rules for delegating change authority responsibilities - define approach to communicating and engaging with stakeholders

PRINCE2 requires that 2 organization related products (documents) are produced and maintained and both these documents should be created during the initiating a project process:

- PID: The PID sets out the project management team structure and roles and includes information on how the project is to be managed.

- Communication management approach (CMA): The CMA provides an overview of all identified stakeholders and how the how and frequency of communication to these internal and external stakeholders during the project.

A project management team should have: - business, user, and supplier representation - governance overview (how decisions are made) - project role review at the end of stage and take action if needed - an approach to manage communication during the project (CMA)

6.5 Project roles and responsibilities Project roles are documented in the PID (section: project management team) and this if first created in the SU process.

Project board The project board has three roles: executive, the senior user, and the senior supplier. Only one person can be the executive while the senior user and senior supplier roles may be assigned to one or more persons. The executive has the final word on decisions that are taken (no democracy)

The project board has the following duties: 1. Accountable for the success or failure of the project 2. Provide unified direction to the project and project manager 3. Provide the resources and authorize the funds for the project 4. Provide visible and sustained support for the project manager 5. Ensure effective communication within the project team and with external stakeholders

Delivery

Management

DirectionSeniorUser Executive Senior

Supplier

ProjectManager

Optional RoleTeamManager

P2FMT



The project board roles The executive: is appointed by the CPC (first activity in the project). The executive is responsible for the project and is supported by the senior user and senior supplier roles.

The executive is the single point of accountability for the project. Normally the executive will be responsible for designing and appointing the project management team which includes the rest of the project board and the project manager.

The executive is responsible for developing the business case during the SU process and they keep asking “Is the project still value for money?” during the project.

The senior user: has the following responsibilities: • Specify the needs of the users that will use the project products • Liaise between the project and the users • Make sure the solution will meet the needs of the users (quality and ease of use) • Supply the benefits information for the benefits management approach (BMA)

The senior supplier: this role represents the interests of the persons designing, developing and implementing the project’s products. The senior supplier role provides supplier resources to the project and ensure that the right people, tools, equipment, and knowledge are in place, and that the products meet the expected criteria, including quality criteria.

The senior suppler can come from the customer organization (e.g., purchasing manager) or they can come from a supplier (e.g. account manager) and can be one or more persons.

Project assurance: user, business, and supplier Business assurance (the executive) wishes to ensure that the business aspects of the project are correct and that they have the correct financial and business information.

User assurance wish to ensure that the project will deliver the correct products and that these products will meet the expected requirements. So they will be asking for proof of quality testing and proof that products have been accepted. The senior user is responsible for user assurance.

Supplier assurance wish to ensure that the products will be delivered as expected and that the right materials and people are in place to do the work. The senior supplier is responsible for supplier assurance.

The project board can decide to do this assurance (business, user and supplier) or they can assign these assurance tasks. Project assurance persons should support the project manager and make them aware of standards which they should use in the project.

Delivery

Management

DirectionSeniorUser Executive Senior

Supplier

ProjectManager

Optional Role

Project AssuranceBusinessAssuranceUserAssuranceSupplierAssurance

TeamManager



The change authority role Change authority is a person or group decide on requests for change or off-specifications, and this role is part of the PMT. The change authority may be given a change budget and can approve changes within that budget.

Change authority may be delegated to a number of levels including (project board, project manager) depending on the severity of the change. Different roles can have change authority responsibilities:

Severity - Change request Who decides? Level 5 Corp / programme management Level 4 Project board Level 3 Change authority Level 2 Project manager Level 1 Project support / Help desk

?

If very few changes are expected, then the project board can do this. If many changes are expected, then it is better to use a separate change authority group as this is more efficient and less time is demanded from the project board, as they are busy people.

The project manager role The project manager manages a project on a day-to-day basis and this role can never be shared. They run the project on behalf of the project board within specified constraints.

The project manager normally (preferred by PRINCE2) comes from the customer. They are also responsible for project support and team manager roles. In smaller projects the project manager can manage the Team Members directly so there is no need for a team manager

Note: If there is person of take on the project support tasks, then the project manager must do them.

Team manager role The role of the team manager is optional in a PRINCE2 project. This role can be used:

• If the project is large and there are many team members • If there is a need for specialized skills or knowledge of the products to be produced • For geographic reasons, where some team members are situated at another site and the

PM wishes to talk with one person instead of each team member • If you are using an external company and it is easier and more efficient to coordinate with a

team manager rather than all the team members directly

Delivery

Management

Direction

Corp..

SeniorUser Executive Senior

Supplier

Corporate,programmemanagementorcustomer

ProjectManager

ChangeAuthority

ProjectSupport

TeamManager



The team manager has the responsibility to produce the products that were assigned in work packages (contains product descriptions) and to provide regular status reports.

Project support role This role provides a number of services to the project:

• Administrative services and advice or guidance on the use of project management tools or planning or risk management services

• The most common responsibility of project support is configuration management and, therefore, follows the guidelines in the change control approach document

Combining PRINCE2 project roles PRINCE2 does allow some of the roles to be combined except for the following situations:

• The executive and project manager roles cannot be combined. • The senior user, senior suppler, or project manager should not be combined. • There can only be one project manager and one executive in a project • The PM, team manager, or project support should not have project assurance roles.

When combining roles, you should check if there are any conflicts of responsibilities. It is not recommended to combine the roles of senior user and senior supplier as this will create conflicts of interest. Each of the roles can be tailored to suit the project.

Stakeholder engagement Stakeholder engagement is where the PM identifies and communicates effectively with those people or groups who have an interest in the project’s outcome. Stakeholders in a project can

- Support or oppose the project and become very active - Gain or lose as a result of project delivery - See the project as threat or opportunity to their position (e.g., career can grow)

Communication with stakeholders is the key to the project’s success and this is something that the project manager and executive should keep in mind during the project. Communication with stakeholders during the project is defined in the CMA.

6.6 The communication management approach (CMA) document The purpose of this document is to define how communication will be done during the project (e.g., what type of info to communicate, to whom it is being communicated, and how often). It contains a description of the means (how) and the frequency of communication to internal and external parties.

The PM is responsible for creating the CMA during the IP process (planning stage) and this document should be reviewed during the managing a stage boundary process to ensure that key stakeholders are receiving the required communication.

The CMA contains the following information: 1. An introduction to the purpose of the CMA document 2. The communication procedure: Communications methods that will be used 3. The tools and techniques, such as e-mail, intranet, newsletter 4. Types of reports and the information they should contain 5. Timing of communication activities 6. Roles and responsibilities: Who will handle the communication? 7. Stakeholder analysis: Type of stakeholder and desired relationship



6.7 Roles and responsibilities Role Responsibilities CPC • Appoint the executive in the SU process

• They can also suggest a project manager • Can provide CMA template which make it easy for the PM

Executive • Appoint project manager if not done by CPC. • Chooses project board and confirms project management team • Approves CMA document

Senior user • Provides user resources (e.g. to help with requirements) Senior supplier • Provides supplier resources Project manager • Prepares CMA document in the IP process

• Checks role descriptions for project management team Team manager • Manages team members

6.8 What you need to know

You should know: 1. The purpose of the organization theme 2. How to describe the minimum requirements for applying the organization theme 3. How to describe the roles and responsibilities of the main project team members 4. Understand which roles can be combined in a PRINCE2 project 5. How to explain the concept of stakeholder and stakeholder engagement 6. How to explain the 3 project interests (the 3 primary stakeholders) 7. The 4 levels in a project and 3 levels in a project management team 8. The purpose of the communication management approach (CMA)



7 Quality 7.1 The quality knowledge provided by PRINCE2

The purpose of the quality theme is to setup and implement a system that will create and verify that products are fit for use and meet user requirements. The quality theme defines the PRINCE2 approach to ensure that products created during the project meet the users expectations and that the end product can be used as intended, so users can realize the expected benefits

Product focus is one of the seven principles of PRINCE2, which states that products should be clearly defined (including detailed quality requirements) and signed off before development is allowed to start. Product descriptions must include the quality criteria information so that all project stakeholders have a common understanding of the products that will be created.

For example, if you are creating a new can opener, some of the quality criteria might be:

• Rust free • Easy to clean • Plastic handle should keep its color for 30 years • Dishwasher-proof • Mechanical parts must open 35,000 cans • Easy to use (8 years to 90 years)

7.2 Quality definitions Quality can be defined as the total amount of features or characteristics of a product, so that it meets expectations and satisfies the stated needs. This is the same as saying that all features of the product have to work as expected for the user. Think of all the features or characteristics of the above can opener, they are all expected to work.

Quality management is the activities to direct and control an organization or project with regard to quality. Some of these activities are: defining quality, quality control, and quality assurance.

Quality Management Systems (QMS) is the complete set of quality standards, procedures, and responsibilities for a site or organization. The vast majority of large manufacturing companies have a Quality Management System in place.

Customer’s quality expectation is captured in the project product description; it lists the expected quality from the main product to be produced by the project.

Acceptance criteria is a prioritized (MoSCoW) list of criteria that the main output must meet before the customer will accept it. These criteria are gathered in the document project product description.

7.3 Introduction to the PRINCE2 approach to quality The following activities have to be done on each project:

• agree on the customer’s quality expectations and acceptance criteria • identify the project’s products (sub-products) that need to be created • create product descriptions for each product (user requirements) • include the quality criteria, the quality methods, and the quality responsibilities

The PRINCE2 approach to quality has two parts: Quality Planning and Quality Control.

Quality planning Quality is about identifying all the products that the project wants to control. Then write a product description for each product, which will include quality criteria, how the products will be assessed, developed, accepted and the responsibilities of the people involved.



Quality control Quality control focuses on the techniques and activities to inspect and test (control) products. This would also include looking for ways to constantly improve overall quality.

7.4 Part 1: Quality planning introduction The purpose of quality planning is to:

1. Agree on the overall quality expectations and acceptance criteria of the main product: 2. Communicate these agreements with all stakeholders (project product description): 3. Establish how quality can be controlled by the PM during the project:

The following questions should be asked in quality planning: 1. What are the customer’s quality expectations? 2. How to prove that we meet each of the product specifications? 3. What is the acceptance criteria (check list) that the customer will use to accept products

during or at the end of the project?

Quality planning steps 1. Gather the customer’s quality expectations: high-level requirements

• These are the key requirements for the main product to be produced • The measurements that can be used to assess quality (speed, size, noise, etc.)

2. Gather acceptance criteria senior user and add to the project product description. 3. Write the project product description (PPD): This document contains:

• Customer’s quality expectations + acceptance criteria • Tolerances for the main product • Acceptance method: how the project product will be accepted • Acceptance responsibilities – who will be responsible for accepting

4. Create the quality management approach (QMA): the approach for quality in the project.

5. Write product descriptions: for each of the products (sub-products) and include the quality

information, such as: • Quality criteria for each product and quality tolerances • Quality method (i.e., how to carry out quality checks after product is created) • Quality responsibilities for creating, quality checking, and approving the product

6. Set up the quality register. Most of the data will come from the plans

Pre-Project – SU Initiation – 1st Stage

ProjectBriefPPD

QMA

ProjectPlanProduct

Descriptions

Acceptancecriteria

ProjectProductDescription

Quality requirements

from Customer

Customerqualityexpectations

Qualityresponsibilities

Quality information in Product Descriptions

Qualitycriteriaandtolerances

Qualitymethods

QualityRegister

1

2

3

4

5

6



7.5 Part 2: Quality control Quality control is carrying out the activities to control quality. There are 3 parts to quality control:

1. Carry out the quality methods 2. Maintaining quality and approval records 3. Get acceptance and passing the acceptance records to the customer

The quality register will be updated with the result of the quality tests. The configuration item record is updated to show the product is now delivered and handed over.

7.6 Quality documents Project product description

This is a project product description from the sample project: U2 Driving School. The sections customer quality expectations and acceptance criteria document the quality requirements.

The quality management approach A quality management approach describes how quality will be done during the project and this includes the specific processes, procedures, techniques, standards, and responsibilities to be applied. A QMA template is usually provided by the organization and only needs minor changes.

Deliv

ery

Team

Man

ager

by Frank Turley

Closing a Project

Man

agem

ent

Proj

ect M

anag

er

Work Packages

CS:CIR

QualityRegister

Updateproductstatus

Delivery Stages : Controlling a Stage & Stage Boundary

ProjectManagerassignsworktoteam&includesqualitycriteria

Quality Check

ResultsinQualityRegister

Product (s)

QualityReview

Technique

Acceptance Records

Products are created by the teams

Givetoclient



The quality management approach can contain the following: 1. The quality management system to use, i.e., from customer, supplier, or a mixture? 2. The standards will be used? 3. The tools and techniques will be used? 4. How quality assurance be carried out? 5. The responsible for documenting the quality expectations and acceptance criteria? 7. The records will be required and where will they be stored? 8. The timing of quality activities be executed?

Product descriptions The product descriptions should be created for all the products before the plan can be completed.

Sections Product description content Identifier Unique identifier for each product Title Product name: e.g., Casing Purpose Who needs the product, why they need it, and what it will do Composition List the parts that the product will be made up of Quality Criteria E.g., color, noise, size, durability, lifetime Quality Tolerance E.g., color cannot fade in 10 years +-10% Quality Method E.g., use machine to test color fading; use inspection Quality Skills required E.g., what knowledge is required to be able to test Quality Responsibilities E.g., responsible for producing, reviewing, and approving

Quality register The quality register is a list of the quality events that take place during the project, such as delivery dates, quality reviews, and acceptance. See the example of a quality register, and as you can see, you have columns for Producer, Quality Reviewer, and Approver.

1. Product ID: Unique identifier 2. Product name: A common name to refer to the product (ex: “Elevator”) 3. Quality method: Describes how testing will be done 4. Producer: Name of producer 5. Reviews: The product review(s) after its delivered? 6. Approver: The approves of the product (ex: “John from Safety Company”)

PurposeCompositionQualityCriteriaQualityTestingEtc.

ProductDescription



7. Target review date: Date the product should be reviewed (ex: “June 20”) 8. Actual review date: Actual date that review happened 9. Target approval date: Date project manager will get approval (ex: 1 week later) 10. Actual approval date: Actual date when project manager received approval 11. Result: Result of check: Pass or Fail

The PM can check whether the Actual Target Review date and Actual Approval date columns are filled in or not. This allows the project manager to control quality. The quality register is updated by the project manager and project support.

7.7 PRINCE2 minimum requirements for quality A PRINCE2 project should be doing the following at a minimum:

• The project product description should contain: o Customer’s quality expectations (requirements) o Acceptance criteria (quality checklist)

• Define the quality management approach. • Create product descriptions (also part of planning) which include quality criteria • Maintain quality records • Use lessons to keep learning and improving how quality is done

PRINCE2 also requires that 2 products are produced and maintained: • 1) Quality management approach (QMA) and 2) quality register

Note: Any approach that meets the requirements described will satisfy PRINCE2.

7.8 Project assurance vs quality assurance Quality assurance provides a check that services and products in an organization are meeting the organizational standards and policies. Quality assurance only checks that a project is following an agreed project process (e.g. business case must be prepared for each project) and has nothing to do with checking the quality of the products produced by the project.

The CPC is responsible for quality assurance and this role is outside the project management team, while project assurance is within.

11 WallInsulation

Inspection JV WP RT 2/10 10/10 10/10 11/10 Pass links

12 HeatingFurnace

Inspection TM TL RT 21/10 21/10 27/10 30/10 Fail links

12 HeatingFurnace

Performance test

MP TL RT 21/10 21/10 27/10 30/10 Pass links

13 KitchenFittings

Inspection AM OH BD 5/11 7/11 14/11 18/11 Pass links

.. … ….. .. .. .. … …. …. …. … ….

Prod

uctID

Review

ers

Quality

Method

Prod

uct

Nam

e

Prod

ucer

Approver

TargetReview

Date

ActualReview

Date

Actual

App

rovalDate

Target

App

rovalDate

Result

Records



Project assurance: The project board is responsible for monitoring the project’s performance in the user, supplier, and business areas.

7.9 Roles and responsibilities Role Responsibilities CPC • Provide QMS and quality assurance to the project Executive • Approve the PPD (SU process) & QMA Senior user • Provide quality expectations and acceptance criteria for project product

• Approve the project product description • Acceptance of the project product (end of project)

Senior supplier • Provide resources to undertake supplier quality activities Project manager • Document customer’s quality expectations and acceptance criteria

• Prepare the PPD and PD’s • Prepare the quality management approach

Team manager • Produce products consistent with product descriptions Project support • Admin support and maintain quality register and records

7.10 What you need to know • The purpose of the quality theme • Be aware of the quality definitions • Explain concept of quality planning and quality control • Explain customer quality expectations and acceptance criteria (PPD) • Understand the purpose of the following documents:

- Project product description (PPD: main product produced by the project) - Quality management approach (QMA) - Product description (requirements documents) - Quality register

• Describe the minimum requirements for managing quality • Explain project assurance and quality assurance (know the difference) • Aware of the roles and responsibilities (PM, senior users and project board)

CorporateProgramme

Customer(CPC)

Executive

ProjectManager

SeniorUser(s) SeniorSupplier(s)

ProjectBoard

ChangeAuthority

ProjectSupport

Managing

Direction

ProjectAssurance

QualityAssurance

ResponsibilityoftheProjectBoard

ResponsibilityoftheCPC



8 Plans 8.1 Introduction

The purpose of the plans theme is to provide a framework to design, develop, and maintain the project plans to help plan, facilitate communication and control the project.

This theme helps to answer the following questions:

• What is required to be delivered? • How will it be delivered and by whom? • What is the best approach to creating the products? • What will the execution steps be? • How can product-based planning be done? • What quality has to be reached and how to define this? • How much will it cos to deliver the products and the project? • The level of detail required for each plan?

The plans provide the backbone of information used to manage the project. Without a plan, there can be no control as you have no baseline to compare your progress to. The act of planning helps the project PM and the rest of the project management team think ahead and avoid duplication, omissions, threats and other planning issues.

8.2 Plans definitions Plan: A plan can be a document that describes how, when, and by whom a specific target or set of targets is to be achieved. A plan should also to show that targets (for time, cost, quality, scope, risk, benefits, and of course, products) can be achievable. The plan is considered to be the plan for any project and it is created near the start of the project and continually updated during the project to show what has been realized and what is still left to do. The original plan could also be compared to the plan during the project or the plan at the end of the project to see how well the project is doing in relation to the original plan.

Planning: The term planning is used to describe the actions used to create the plans and associated documents and keep them updated during the project.

8.3 Three levels of a plan It is difficult to plan most project from the start in detail as you can only accurately plan in detail a short time in advance, so you are limited by what you can see clearly in the next days or weeks. This view of the future is known as the planning horizon. PRINCE2 recommends 3 levels of plan which are: 1) project plan, 2) stage plan, and 3) team plan.

Project plan • This is a high-level plan for the whole project and used at the direction level (project board) • Created during the IP process (planning process) and becomes part of the PID. • Shows the planning for products of the project and associated cost. • This plan is a major control document for the project board and therefore the project manager

keeps the project plan up to date during the project (SB process)

Stage plan • Stage plan is used at the Management Level (project manager) and required for each stage • It is similar to the project plan but is a lot more detailed (day to day plan for the stage) • It is produced close (SB process) to the time when the planned events will take place and

each new plan should learn from the previous stage.



Team plan • Team plans are used at the Delivering Level (produced by team manager) • The team manager plans the work (in work packages) that is assigned to them • They are optional, depending on the project’s size, complexity and number of resources • PRINCE2 does not provide a format for a team plan so they can use agile, scrum, etc…

The other plan created during the project is the exception plan and more about this later.

8.4 Planning overview Here is an overview of the planning steps in a typical project.

Description

SU Create the project product description (PPD) – document the project expectations

SU The initiation stage plan is the day-to-day plan for the initiation stage IP The planning step “define and analyse products” consists of 4 parts:

• Create PPD (from the SU process, see above). • Create product breakdown structure (PBS). • Create product descriptions (PDs) – requirements documents. • Create product flow diagram (PFD). - dependency diagram

IP The project plan is the plan for the project and is approved by the project board. It is then baselined (signed off) and used to check on progress

SB Stage plans are produced near the end of the current stage for the next stage SB Exception plans can be used to get the project or stage back on track if out of tolerance. SB The project plan is updated in SB process to what has been delivered, etc… CP The PM updates the project plan so show the full cost and timescale for the project, and what

has been delivered. The project board compares this plan the original baselined plan. MP Team plans are created by the team managers and they are optional.

CPC

ProjectBoard

SU

DP?

IP

SB

??

MP

CS

SB

?

MP

SB

CS

CP

?

TeamManager(s)

ProjectManager

ProjectPlan ProjectPlan ProjectPlan

StagePlan StagePlanStagePlan

TeamPlans TeamPlans TeamPlans

?

CS

ProjectPlan

StagePlan

PPDPDs

PBSPFD



Work Packages Work packages are a way for the PM to group work together and assign work to a team to produce one or more products. A work package can contain the following:

• product descriptions and a work package description • techniques to be used, tolerances (e.g. time and cost), date of agreement • how the team manager will report to the project manager (e.g. checkpoint reports)?

8.5 Exception plan – if out of tolerance An exception plan is used to recover if the project or stage has gone out of tolerance. An exception plan is created at the same level of detail as the plan it replaces and will pick up from where the current plan stopped until the work is done. Exception plans can be used to replace stage plans and project plans, but not team plans. The team manager will notify the project manager by raising an issue, therefore the team manager does not create an exception plan.

8.6 Product-based planning steps PRINCE2 has its own approach to planning, and this approach is called product-based planning. It uses the product breakdown structure to identify and analyze the products to be created.

Product-based planning is an iterative process and has a number of benefits:

• Identifies and documents the plan’s products and interdependencies • Shows what the project involves; this avoids setting the wrong expectations • Gets users to supply the product requirements and therefore increases their support • Improves communications, as it provides a simple overview of what needs to be done • Clarifies what is in and out of scope which helps to avoid “scope creep” • Makes it easier to gain a clear agreement on what needs to be produced

The PRINCE2 approach to plans has the following 7 steps that are easy to understand:

6

5

4

3

2

1

7

Designtheplan

Defineandanalyzetheproducts

Identifyactivitiesanddependencies

Prepareestimates

Preparetheschedule

Document theplan

Analyzetherisks

Project Product

Description

Product Breakdown

Structure

Product Descriptions

Product Flow Diagram

Choose plan format

Product breakdown structure e.g. during a workshop

Use product descriptions and PBS diagram during this step

Involve experts (experience)

Define activity sequence and add and assign resources

Assumptions, constraints, risks, external dependencies



1 Design the plan: Consider the style and format of plan Decide on number and length of stages

2 Define and analyze products: Create the product breakdown & product descriptions 3 Identify activities and dependencies: Activities to create the products (team manager)

4 Prepare estimates: Estimate time and resources for each product

5 Prepare the schedule: Schedule activities and show sequence

6 Document the plan: Add following text: assumptions, lessons used, prerequisites, plan introduction, monitoring, control, budgets, and tolerances

7 Analyze the risks: For each of the above steps, new information on new and existing risks can be uncovered

These steps are taken to create the project plan, stage plan and the team plan.

8.7 Product-based planning steps 1 to 7 Step 1: Design the plan

If the project is part of a program, then the programme will most likely have a common approach to planning, which could then be adopted by the project. Some tips to consider for this step:

• Think of your audience and how they might access the planning data. • Consider the tools to use for estimating, planning, and monitoring.

Step 2: Define and analyze products PRINCE2 uses the product breakdown structure (PBS) to identify and analyse the planned products.

The 4 steps in defining and analysing the products are:

1) Write the project product description: Describe the main product (SU process) 2) Create the product breakdown structure: List products that need to be created 3) Write the product description: Done for required products 4) Create the product flow diagram: Show product flow and interdependencies

Step3: Identify activities and dependencies Activities: Identify the activities that need to be done for each product Dependencies: Look for dependencies between the activities and note them.

Step 4: Prepare estimates Estimating is deciding how much time and how many resources are required to carry out a piece of work. The PM should facilitate a workshop and invite the necessary persons; this can be done in the same workshop as product-based planning.

2 Defineandanalyzetheproducts

Project Product

Description

Product Breakdown

Structure

Product Descriptions

Product Flow Diagram



Estimating involves: • Identifying the type of resource required, as specific skills are often crucial. Consider non-

human resources, such as equipment (e.g., testing equipment), travel, and money. • Approximating (estimating) the effort required for each activity.

Step 5: Prepare the schedule The PM must already have the list of all activities, their dependencies, and the duration of effort for activities before they can begin this task of scheduling.

Step 6: Document the plan The objective is to add text similar to the following to help explain them:

1. Plan description: Text to help introduce the plan 2. Plan prerequisites: Things that must be in place for the plan to succeed 3. External dependencies: Dependencies that will influence the plan 4. Planning assumptions: Assumptions upon which the plan is based 5. Lessons incorporated: Lessons from similar or previous projects, etc… 6. Monitoring and control: How the plan will be monitored and controlled 7. Budget information: Cost, time of project, risk and change budgets 8. Tolerances: Overview of tolerances for the 6 project variables

Step 7: Analyze the risks This is occurring all the time.

8.8 Number and length of management stages The number of management stages A small project may have 2 management stages (initiation and one delivery stage), and large projects can have many more. So to decide the number of management stages? Some factors to consider:

• How far ahead in the project it is safe and sensible to plan. • Key decision points need to be on the project • Risk in the project: The higher the risk the more stages. • How confident the project board are in the project manager? • How much control to the project boar want to have.

Note: More stages will increase the amount of work by the project.

The length of management stages The number of stages should increase if lots of uncertainty (risk) or complexity, and the number should decrease if risk, uncertainty, and complexity are lower. Here are some factors:

• How far you can plan ahead on a day-to-day basis (the planning horizon) • Aligning the delivery steps (work done by the teams) to the end of management stages. • Alignment to programme activities:

8.9 Delivery steps vs management stages? Delivery approaches are how most companies and teams work. The best way to understand this is to look at how they differ from management stages, and use the diagrams below.

1. Delivery steps can overlap, but management stages do not. 2. Delivery steps are usually linked to skills (e.g., Requirements Analyses, Design Product),

while management stages are focused on business justification and authority.



3. A delivery step can span a management stage boundary.

These 2 diagrams help explain the difference between delivery steps and management stages.

• These are the delivery steps (requirements, risks, testing, etc.) • The delivery steps overlap each other and there is are no management stages

This diagram shows that delivery steps appear to be broken up so they fit in the management stages. The project manager will have a product description for both version 1 and version 2 so they can check if the product was delivered as expected in the specific stage.

8.10 PRINCE2’s requirements for the plans theme PRINCE2 insists that each project must do the following as a minimum for plans:

• Ensure that plans support the business case and enable it to be realized. • Have at least 2 management stages • Produce a high-level project plan for the whole project and a stage plan for each stage. • Use a product-based planning approach for the project plan and stage plans. • Consider using the 4 recommended steps to define and analyse the products. • Produce specific plans for managing exceptions where needed. • Define the roles and responsibilities for planning. • Use lessons to improve planning.

PRINCE2 requires that 4 products are produced and maintained during the project:

1. Project product description: 2. Product description: 3. Product breakdown structure: 4. Plans:

RequirementsRisks

PrototypeTestPrototype

DevelopmentTesting

Training

Req.Draftv1 Req.Draftv2 Req.v1

Highlevel+Lessons DetailedRisksRegister

Version1 Version2

DocTests,TestReport

TestReport

Dev.Functionality1 Dev Rest+FinalRelease

DocTests(Plan) CreateEnd2EndtestsRequirementsv1 TrainingDocv1



8.11 Roles and responsibilities Role Responsibilities CPC • Set project tolerances (in the project plan)

• Approve project exception plans Executive • Approve project plan and can approve stage-level exceptions plans

• Define tolerances for each stage Senior user • Provide resources to assist with product-based planning Senior supplier • Provide resources to assist with product-based planning and planning Project manager • Facilitate complete product-based planning process

• Write product descriptions (share responsibility with team manager) • Create project and stage plans plus exception plans if necessary • Update project plan (during the SB process) to show actuals to date

Team manager • Assist project manager with planning and prepare team plans • Share responsibility for writing product descriptions and PFD

Project support • Assist with compilation of project plans and stage plans

8.12 What you need to know You should know:

• The purpose of the plans theme • Plan definitions • Three levels of plans • Purpose and overview of plans: project, stage, exception, and team • The minimum requirements for applying the plans theme • The product-based planning steps (the recommended approach to planning) • The recommended approach to defining and analyzing the products • Delivery steps versus management stages • Factors to consider for number and length of management stages • Be aware of the roles and responsibilities (PM and project board)



9 Risk Theme 9.1 Purpose of the risk theme

The purpose of the risk theme is to provide an approach to “identify, assess, and control uncertainty during a project, and as a result, improve the ability of the project to succeed.”

9.2 Risk definitions The PRINCE2 definition for risk is taken from the Management of Risk (MoR) method.

Risk is a set of events that, should they occur, will have an effect on achieving the project objectives.

Another popular definition: Risk is an uncertain event that, if it occurs, will have a positive or negative effect on a project objective.

PRINCE2 states that the project’s objectives which are the 6 performance targets of time, cost, quality, scope, benefits, and risk.

Risk management activities Risk management is about actions you take to enable you to enable you to identify, assess, and control risk. The PRINCE2 risk theme provides an approach to manage risk in a project. There are 3 steps to risk management, which are Identification, Assessment, and Control:

• Identification: Identify, capture, and describe the risk • Assess the risk: Likelihood of the risk and impact on objectives • Respond: How best to respond to a risk and responsibilities

9.3 Risk management products Product: Risk management approach (RMA)

This document defines the project procedures for risk management in terms of how risk will be identified, assessed, controlled, and communicated in the project. It describes the specific risk management techniques and standards to be applied and the responsibilities.

Product: Risk register The risk register captures and maintains the information (threats and opportunities) on all risks that were identified and relate to the project. It provides a record of all risks, including status and history.

ID RiskAuthor Date Risk

Category RiskDescription ProbabilityxImpact Proximity Response

Category Status Owner Actionee

9 P.Smith 6/3/ Ordering

Ariskthatpens willbedelivered2-4weeks laterwhichwillimpactthetimeoftheproject

€550 Stage2 Reduce Active PSmith JBell

10 S.Kelly 7/3/ Product

Users maynotlikethepensandthereforenotkeepusingthemwhichresultin90%- 100%reductioninbenefits

€11,200 Year 1 Reduce Active S.Kelly RClark

11 S.Kelly 9/3 Product

Somesalespeoplemaynotdistributethepensasintended,thereforethebenefitswillnotberealizedfortheseusers

€5,600 Year 1 Reduce Active S.Kelly S.Kelly

ProjectName PenProject Risk/Impact

ProjectNo 008 HighRisk>€7,500

ProjectManager RoseCarr Medium>€1000

ProjectExecutive JohnKing LowRisk< €1000



A risk register can have the following columns:

1. Risk identifier: Unique number (ex: 042) 2. Risk author: Person who suggested the risk (can also be the risk owner) 3. Date registered: Date the risk was registered 4. Risk category: A project can have its own categories. 5. Risk description: Can write this in a specific way (e.g., cause, event, and effect). 6. Probability impact: Choose from agreed scale (very low, low, normal, etc.). 7. Proximity: How soon (when) the risk is likely to happen 8. Response category: Avoid, Exploit, Reduce, Transfer, … 9. Risk response: Description of how best to respond to risk 10. Risk status: Status of the risk: active or closed or to investigate. 11. Risk owner: Mention one person who is responsible for managing the risk 12. Risk actionee: Person who carries out the actions described in the response

The PM creates the risk register and they are responsible for it and project support maintains it.

9.4 The recommended PRINCE2 risk management procedure The PRINCE2 risk management procedure is a set of 5 steps. The first 4 steps are sequential, while Communicate will always be done to give and get feedback to stakeholders.

Steps Risk Management Procedure Descriptions Identify Complete the RMA, then identify the risks (threats and opportunities) that could

affect the project. Assess Assess the risks (probability and impact) on the project objectives. Plan Plan steps to prepare the specific response to the risks Implement Carry out planned responses mentioned from step 3 (plan) if risk occurs. Communicate Keep communicating to stakeholders using existing management reports that

are created during the project (e.g., end stage report).

9.5 Step 1: Identify The identify step can be divided into a number of smaller steps.

1. Identify the context of the project (risk appetite) 2. Complete the risk management approach document (RMA) 3. Identify the risks using a number of techniques: 4. Describe the risks in terms of cause, event, and effect. See the next topic.

Identify

Assess

Plan

Implem

ent

Communicate



How to express risk PRINCE2 recommends to described risks clearly. e.g. We cannot say that the risk to an international medical conference in Berlin is “An active volcano” as it does not tell us very much in terms of how the volcano would affect the project. Describe this risk in terms of the cause, event, and effect.

Example 1: Project is to organize a European conference on solar energy in London and we invite the top 300 persons from around Europe to this event who would mostly fly in. Now describe this volcano risk in terms of cause, event, and effect.

Due to an active volcano in Iceland that is releasing ash, there is a threat that the winds could bring this ash into UK airspace, thus grounding planes, which would cause 80% of the people to miss the event, and the event would lose €22,000.

Now let us look at the cause, event, and effect: 1. Cause is the active volcano in Iceland that is releasing ash (source of the risk). 2. Event is a threat that the winds might bring the ash into UK airspace (ground planes) 3. Impact: 80% of the people to miss the event and lose money.

Example 2: A farmer’s crops might get damaged due to heavy rain, as fields will get flooded. • Original cause? The cause is heavy rain, the source of the risk.

• What is the threat? The threat is that fields might get flooded. • What is the risk? The crops will get damaged if the risk occurs.

“Due to the heavy rain, there is a threat that the fields mat be flooded, which would damage the crops.”

Due to (cause)… there is the risk of (event)… that could result in (effect)….

Techniques to identify risk PRINCE2 recommends a number of techniques to help identify risks: • Review lessons: Review lessons from similar and previous projects • Risk checklists: These are in-house checklists that may exist. • Brainstorming: Invite different types of stakeholders to a brainstorming-type • Risk breakdown structure: Hierarchical decomposition of risk sources and each level.

9.6 Step 2: Assess risk Assess risk covers two actions: Estimate and Evaluate risk and these go together.

Estimate is about assessing the probability, the impact, and the proximity for each threat or opportunity. These are 3 of the columns in the risk register.

Evaluate is to group all the risks together get an overall risk value for the whole project.

Estimate There are a number of techniques for estimating risk and one example is the Expected value technique. In other words, it combines the cost of impact with the probability.

Example: A high-tech instrument is in transit and it may be damage or stolen.

1. Impact would be €80,000 (cost to replace) 2. Probability (likelihood) of damage is 1%. 3. Expected value is impact by probability (€80,000 by 1%) is € 800.

You can use the technique shown in the above table and place a value on each risk.



PRINCE2 recommends to find out the following for each: 1. The probability of the risk (likelihood of the risk happening) 2. The impact (quantify in terms of any of six project objectives) 3. The proximity of these threats, i.e., when this is likely to happen 4. How the impact of the risk may change over the life of the project?

The PM provide risk information to the executive and project board e.g., at the end of each stage.

Evaluate (combined effect) Evaluate is the second part of the assess step in the PRINCE2 risk management procedure. The objective of Evaluate is to assess all the risks combined (both threats and opportunities) and get an overall risk value for the whole project. Such a figure for each project is useful as the organization can choose to select less risky projects.

Risk appetite is an organization’s attitude towards risk-taking. E.g., a company that builds rockets to carry astronauts into space will have a small appetite for risk.

9.7 Step 3: Plan the responses Planning the responses is about planning specific responses to the threats and opportunities:

1) Avoid a threat or Exploit an opportunity This option is about removing the uncertainty.

• This can often be achieved by removing the cause of a threat (e.g. cancel event) • Or by implementing the cause of an opportunity.

This option may be adopted for no extra cost by changing the way the work is planned. More often though, it is a costly option to completely avoid/exploit a risk.

2) Reduce a threat or Enhance an opportunity

Threat: • Reduce the probability of the risk or reduce the impact if the risk does occur • Take definite action now to change the probability and/or the impact of the risk. • The term ‘mitigate’ is relevant when discussing reduction of a threat

Opportunity: • Enhancing an opportunity is the reverse process to reducing a threat • Enhance is where you take actions to improve the likelihood of the event occurring and/or

enhance the impact if the opportunity does occur.

3) Transfer the risk Threat:

• Transfer is an option that aims to pass part of the risk to a third party. • Insurance is the classic form of transfer, where the insurer picks up the risk cost

RiskID Probability Impact Expected value(likelihood *Impact)

04 2% €80,000 €1,600

05 4% €10,000 €400

06 10% €15,000 €1,500



Opportunity: • Transfer can apply to opportunities, where a third party gains a cost benefit but the primary

risk taker gains another benefit, • This is not a commonly used option whereas transfer of threats is commonly used.

4) Share the risk Threat:

• Share is an option that is different in nature from the transfer response. • It seeks multiple parties to share the risk on a pain/gain share basis.

Opportunity: • Rarely can risks be entirely shared in this way

5) Accept the risk Threat and opportunity

• The organization ‘takes the chance’ that the risk will occur, • There is no change to residual risk with the accept option • They are no costs incurred now to manage the risk or to prepare to manage the risk in future

6) Prepare contingent plans Threat and opportunity

• Also referred to the fall-back option • This option involves preparing plans now, but not taking action now. • This is like saying, we will accept the risk for now, but we’ll make a plan for what we’ll do if

the situation changes.

9.8 Step 4: Implement the responses The main thing to decide in this step is:

1. Who is going to monitor these risks? (risk owner) 2. Who is going to carry out the planned risk responses? (risk actionee)

The risk owner is responsible for managing and monitoring risk aspects and the risk actionee is someone who is assigned to carry out a particular action. They can be the same person.

9.9 Step 5: Communicate Communicate is done throughout the whole risk management procedure. The existing management report products are used to communicate risk information, such as:

• Checkpoint reports, Highlight reports, End stage reports • End project report, Lessons reports

The guidelines for reporting come from the communication management approach document.

9.10 What is a risk budget? This a sum of money that is put aside just to deal with specific responses to threats or opportunities and it cannot be used for anything else. Certain responses to risk (e.g. contingency plans) will require certain actions to be done that cost money; this will be budgeted in the risk budget.



9.11 PRINCE2 requirements for risk management The PRINCE2 minimum requirements for risk management are:

1. Have a risk management approach document (RMA) that provides: • Steps to identify and assess risks, plan and implement responses, and communicate • An assessment of whether the risk has an impact on the business justification • An overview of the roles and responsibilities

2. Maintain a risk register to keep records of risk management (document risks) 3. Ensure that risk management is done throughout the project 4. Use lessons from previous projects to help identify and manage risk

PRINCE2 uses two management products which are created by the PM in the IP process. 1. Risk management approach (RMA) 2. Risk register (record of risk management activity during the project)

The risk management approach can be checked and reviewed by the PM at the end of each stage to see if any improvements can be made to any of the risk management activities. PRINCE2 does not insist on a particular approach to risk management for all projects.

9.12 Roles and responsibilities Role Responsibilities CPC • Provide the corporate risk management policy and information Executive • Accountable for risk management

• Ensure that a risk management approach exists Senior user • Ensure that risks to the users are identified, assessed, and controlled Senior supplier • Ensure that risks to supplier are identified, assessed, and controlled Project manager • Create the RMA and maintains the risk register

• Ensure that risks are continually identified, assessed, and controlled Team manager • Help with the identifying, assessing, and controlling risk Project support • Assist the project manager in maintaining the project’s risk register

9.13 What you need to know You will need to know the following for the exam:

• Explain the purpose of the managing risk theme • Aware of the risk definitions • Explain the purpose of the risk management products (RMA & risk register) • Describe the 5 steps of the risk management procedure • Understand the concepts:

• risk threat and risk opportunity, recommended risk response types • risk owner and risk actionee, risk probability, risk impact, and risk proximity

• Understand risk cause, event, and effect • Explain the purpose of the risk budget • Describe the PRINCE2 minimum requirements for applying the risk theme



10 Change

10.1 Purpose of the change theme The purpose of the change theme is to help you identify, assess, and control any potential changes to the products that have already been approved and baselined. Change is inevitable in any project, and all projects need a good approach to identify, assess, and control issues. This theme provides an approach to issue and change control.

Issue and change control happens during the full lifecycle of the project. Remember, the objective is not to prevent changes but to get changes agreed and approved before they are executed.

Each project requires a configuration management system that tracks products, records when products are approved and baselined, and helps to ensure that the correct versions are being used.

10.2 Change definitions Issues: PRINCE2 uses the term issue to cover any relevant event that has happened that was not planned and that requires some management action (for example, a question or a change request). Issues can be raised at any time during the project and by anyone.

Configuration management is the technical and administrative activity concerned with the creation, maintenance, and controlled change of the configuration of a product.

Configuration item: A configuration item is the name given to an entity (or item) that is managed by configuration management. E.g. Laptop PC, business case document, code, demo version… You could also say that a configuration item is anything that you want to track during the project.

Baseline: A point of time for a product against which the product is monitored and controlled. E.g., after a product description is agreed, we want no unauthorized changes so we lock (e.g., print to PDF) and date the document, which is the same as baselining the document. If the product description is updated, then a new baseline product description is created.

Release: A release is a complete and consistent set of products that are managed, tested, and deployed as a single entity. E.g. New OS & apps on your SmartPhone

Product status account: This is a simple report on the status of products. E.g., at the end of the stage, you query the CMDB and ask for a status of all products for stage 2.

10.3 Types of issues There are 3 types of issues: 1) Request for change, 2) Off-Specification, 3) Problem/Concern

Request for change: A proposal for a change to a baselined product, i.e., a product that has already been approved. This could be a product description document for one of the specialist’s products being created by the project. Example: A stakeholder requests to support a new language.

Off-Specification: This is something that was agreed to be done but is not provided by the supplier and/or not forecast to be provided, and therefore, is out of specification or off-specification. Example: The supplier could not complete the automated Forget Password feature; therefore, password will have to be manually reset by the central administrator.

Problem/Concern: Any other issue that the project manager needs to resolve or escalate; this could be positive or negative. Example: One member of the team was taken off the project for 2 days.



10.4 The PRINCE2 approach to change PRINCE2 has 6 management products that are used to control issues, changes, and configuration management. The change control approach document is used to establish the project controls and the rest of the documents help to maintain the project controls.

Here is a quick introduction to these 6 management products:

1. Change control approach: This document contains the approach on how issues and changes will be handled in the project (e.g., how to identify products, how to control products, and how to do status accounting and verification).

2. Configuration item records: They provide a set of data for each product used in the project 3. Product status account: This is a report on the status of products 4. Daily log: This log is used by the project manager as a diary for all informal information. 5. Issue register: Imagine a spreadsheet to capture and maintain issues (formal issues). 6. Issue report: This report describes an issue in detail.

10.5 How to prioritize issues and track severity There are many ways to prioritize a change request and PRINCE2 uses the MoSCoW technique. MoSCoW stands for Must have, Should have, Could have, and Won’t have for now.

Must have: The change is essential for the viability of the project. E.g., the end product may not work as required.

Should have: The change is important and its absence would weaken the business case; the project would still meet its objectives, however.

Could (nice to have): This is useful but its absence does not weaken the business case.

Won’t have for now: The change is not essential or important, so it can wait.

Rating the severity of an issue • Example: You can use a scale of 1-5 or words such as minor, significant, major, and critical. • You can link a severity level of an issue by linking a severity with a role.

Severity Minor Project support Severity Normal Project manager Severity Significant Change authority Severity Major Project board

Severity Critical Programme Management (e.g., project out of tolerance)

10.6 Change authority and change budget The change authority is a person or group who consider requests for change and off-specifications. It is the responsibility of the project board, so they can do it themselves. If a lot of changes are expected, then this will take up too much time from the project board and it is better to give the authority to another person or group of persons. The change authority will have a change budget, which is a sum of money that can be used to fund the cost of requests for change.

10.7 Management products used by the change theme For the purpose of the PRINCE2 Foundation exam, you just need to be aware of the purpose of each of the following documents. We have included other information only to provide more background and help your understanding.



Change control approach The change control approach document contains the approach of how issues and changes will be handled in the project. If there is a programme environment in place, there will usually be a change control approach template available. This document should answer the following questions:

• How should products be identified and controlled? (configuration management) • How are issues and changes handled? (CAPDI) • What tools will be used to help track issues and product information? • What data should be kept for each product? (e.g., configuration item record) • How often will the project manager consider issue and change control? • Who will be responsible for what? In other words, what will be the roles and responsibilities? • How are issues and changes prioritized? What scale will be used to prioritize issues? • What scale will be used for severity of issues? (e.g., 1 to 4, low-med-high) • Which management levels will deal with different severity issues?

Product status account The purpose is to provide information about the status of products and this can be a report on one product, a group of products, or all products created during a stage. For example, a report on the status of all products that were created by supplier X in stages 3.

Configuration item records (CIR) The purpose is to provide data for configuration items, see example below. A good example is a library index card that will provide data for a library book or the MP3 data for a song file in iTunes.

ID Productname Stage Produceby Qualitystatus

ProductStatus

122 Floor planv3 2 B.Hill Approved Complete

123 Camera installation 2 K.Kelly Approved Complete

124 Evaluator#3 2 OTEK Approved Complete

CIR Date:&Document: Project: Pen&Project Author: PM

Item%ID 14

Item%Name Logo

Current%version 4

Date%of%last%update 2012;06;27

Management%stage 2

Item Type Marketing

Status Approved%(ready for%use)

Source Internal%(Marketing%Department)

Owner Purchasing%Department

Users All%(Public)

Location Marketing%Pack

RelatedMarketing Guidelines%Doc%(MKT045)Marketing%Pack% Taken&from&“The&Pen”&sample&project

22/6



Daily log The daily log records informal issues, notes, etc., that are not captured in other documents. The project manager can use an office application with a number of columns such as Date, Comment, Person Responsible, and Date of Follow-Up if needed.

Issue register The purpose of the issue register is to capture and maintain issue info (formal issues). It is best to imagine this as a spreadsheet with a number of columns.

Issue reports This is a report (description) of one or more issues which contains an impact assessment of the issue(s). The report is usually created when the issue is first registered in the issue register. Basic information can be added like Identifier, Issue Type, Date on Which it was Raised, and Raised By.

10.8 Issue and change control procedure

Daily&Log Date:&Document: Project: Pen&Project Author: Project&Manager

ID Date& Description Responsible

TargetDate Result

01 17/6 One of+the+potential+ suppliers+is+an+old+friend+of+mine+(conflict+ of+interest) PM Closed We+have+dropped+ this+company+as+a+potential+

supplier

02 18/6A+sales+man+from one+of+the+potential+suppliers+ dropped+ off+a+gift.+This+can+be+considered+ a+bribe.+

PM 30/6 I+returned+ the+gift and+put+the+supplier+ in+the+company’s+black+list.

03 22/6 Daniel+Ross, who’s+responsible+ for+the+logo+has+issue+creating+a+vector+version.++

Josef+Stern 30/6 He’s+replaced+by+Julie+ Gates,+who’s+more+

expert+ on+graphic+design.+We’ve+lost+two+days.+

04 26/6The+communication+ between+Julie+ Gates+and+the+supplier needed+for+the+design+of+the+logo+is+not+ effective+enough.

PM 27/6Julie+Gates+is+asked to+have+a+face+to+face+meeting+with+supplier+ and+work+together+ to+work+out+and+present+ the+first+suggestions

Taken&from&“The&Pen”&sample&project

Issue%Register Date:&Document: Project: Pen&Project Author: Project&Manager

ID Description Type DateRaised

RaisedBy

ReportAuthor Priority Severity Status Closure

Date

01 Selected supplier.sent.the.catalog.three.days.later.than.expected

Problem/concern 29/6 R.Carr R Carr High Level 2 Closed 01/06

02 Five.evaluators.did.not.return.theforms.in.time

Problem/concern 18/7 R.Carr R.Carr High Level.2 Open

03 Evaluation.forms.of.four.evaluatorsdo.not.seem.precise

OffIspecification 18/7 R.Carr R.Carr High Level.0 Open

20/7


Capture Assess Propose Decide ImplementIssueLog(formalissues)

DailyLog(informal issues)

IssueReport(formalissues)



The Issue and change control procedure has 5 steps:

• Capture: Determine the type of issue, formal, informal and issue type • Assess: Assess the impact of the issue on the six project objectives • Propose: Propose actions to take (identify the options, evaluate, and recommend) • Decide: Decide whether to approve or reject the recommended solution • Implement: Put the recommended solution in action (known as taking corrective action)

Step 1: Capture The objective of this step (Capture) is to determine the type of issue and then determine how serious it is and if it needs to be treated formally (Issue Log) or informally (Daily Log).

Issue: Request for change • A form will be filled in which will document the request for change • The change authority will later decide on the change.

Issue: Off-specification • A form will be filled in detailing the off-specification. • The change authority will later decide on the change.

Issue: Problem / concern (other) • These are other issues, which can of course be positive or negative. • The project manager can handle these issues if within their tolerance.

Step 2: Assess This Assess step examines the issue by doing an impact analysis, i.e., looking at what effect the issue will have on the some or all of the six project objectives.

The impact analysis should consider the impact that the issue has on: • The performance targets (project variables): time, cost, quality, scope, benefits, and risk • Especially the business base, benefits and risk

Step 3: Propose The PM will consider different options and propose action to take. These options must take the cost and advantage into account.

Approve

Reject

Deferdecision

Requestmoreinfo

AskforExceptionPlan

Requestfor

ChangeProjectBoard(ChangeAuthority)

PMmaydecideonsmallchanges

SothePMhassomeChangeAuthority

Grantaconcession

Instructitberesolved

Deferdecision

Requestmoreinfo

AskforExceptionPlan

Off-

SpecificationProjectBoard(ChangeAuthority)

Out ofspecification with

Product Description

Problem/

ConcernProvideGuidance

AskforExceptionPlanProjectBoard

PMmaydecideifwith tolerance

PM mayalsobeable tohandleissue

New

issue

Issue

Report

Issue

Report

Issue

Report



Step 4: Decide Normally the project board or change authority decides if any action should be taken. Here is an overview of the different options available:

Issue Type Project board

(Change authority) Request for change • Approve the change

• Reject the change • Defer decision • Request more information • Ask for an exception plan

Off-specification

• Grant a concession • Instruct to be resolved • Defer decision • Request more information • Ask for an exception plan

Problem / concern • Provide guidance • Ask for an exception plan

Step 5: Implement The project manager will either:

• Take the corrective action (e.g. issuing a new work package) • Create an exception plan if the issue needs to be included in current stage.

10.9 PRINCE2 minimum requirements for change control The PRINCE2 minimum requirements for change control are: • Have an approach to handle issues.

o how issues are identified and managed (including change authority) o how to asses if issues might have an effect on the business justification o the roles and responsibilities for change control

• Define how baselined products are created, maintained, and controlled • Maintain some kind of issue register to keep track of issues and decisions for these issues • Ensure the PM spends an appropriate amount of time on issue and change control (e.g., 30

minutes every day) • Learn from experience and use these lessons.

PRINCE2 requires that these two products are created in the initiation and maintained:

• Issue register: Used to capture and maintain information on all formal issues • Change control approach: Identifies how, and by whom, the project’s products will be

controlled and protected



10.10 Roles and responsibilities Role Responsibilities CPC • Provide approach for change control (template) Executive • Determine the change authority and change budget

• Set scale for severity rating, issues, priority ratings • Respond to requests for advice from the PM during the project • Make decisions on issues that are escalated by the project manager

Senior user Senior supplier

• Respond to requests for advice from the project manager • Make decisions on escalated issues from the project manager

Project manager • Manage the configuration management procedure • Manage the issues and change control procedure • Create and maintain issue register and implement corrective actions

Team manager • Implement corrective actions that were assigned by the PM Project support • Do administrative tasks for the issue and change control procedures

10.11 What you need to know • The purpose of managing change (the change theme) • Change definitions and describe the 3types of issues • Purpose of a change budget • Purpose of these change management products

• Change control approach, Product status account • Configuration items records, Daily log • Issue register, Issue report

• Describe the recommended issue and change control procedure • Describe the PRINCE2 minimum requirements for applying the change theme • Be aware of the roles and responsibilities (PM and project board)



11 Progress 11.1 Purpose of the progress theme

The purpose of the progress theme is to:

1. establish how to monitor and compare actual achievements against those planned 2. provide a forecast for the project objectives and continued viability 3. be able to control any unacceptable deviations

Progress is about checking progress compared to the plans and controlling any deviations. Project control involves measuring actual progress against the 6 performance targets of time, costs, quality, scope, benefits, and risk. Progress can be monitored at 3 levels:

• Project level (project board) • Stage level (project manager) • Work package level (team manager)

11.2 Progress definitions Progress is checking and controlling where you are compared to the plan and this is done for the project level, stage level, and work package level.

Progress control involves the activities of measuring actual progress against the performance targets and each project layer wishes to monitor the layer below. The layer does the following:

• Monitor actual progress against the plan (review plans with forecast) • Detect problems and identify risks • Initiate corrective action to fix issues • Authorize further work to be done

An exception is a situation where it can be forecast that there will be a deviation beyond the agreed tolerance levels.

Tolerances are the deviation above and below a plan’s target. For example, the project should take 6 months, with a tolerance of ±1 month. Tolerance levels could also be set for all 6 tolerance areas,

11.3 PRINCE2 requirements for approach to progress To control the project, PRINCE2 has the following minimum requirements:

• Define its approach to controlling progress (documented in PID) • Manage by stages (and executive one stage at a time) • Set tolerance for each level and manage by exception • Review business case when exceptions arise • Learn lessons

PRINCE2 provides progress control through: 1. Delegating authority from one level to the next 2. Dividing the project into stages and authorizing one stage at a time 3. Time-driven and event-driven progress reports (e.g., highlight reports) 4. Raising exceptions: Use exceptions to alert above layer if a big issue occurs

How these controls will be used in the project is decided early in the project and documented in the PID. Progress is about checking actual progress against the six performance targets.

Defining tolerances for different levels This diagram shows how each level wishes to monitor and control the level below.



Corporate / programme management / customer • CPC is outside the project, they set the overall requirements and project tolerance levels. • If project tolerances are exceeded, the exception is escalated to the CPC. • Project tolerances are set in the initiation stage and are defined in the project plan.

The project board • They set the stage tolerances and PM will escalate issues to them if necessary. • If an issue affects the project’s tolerance, the project board has to escalate this issue up.

The project manager • The PM has day-to-day control over the stage and they work within the tolerances. • The PM sets and agrees to the tolerances in the work packages.

The team manager • They receive work packages from the PM and works within the agreed tolerances. • They raise an issue if they go out of tolerance and do not create an exception report.

Tolerances table Tolerances Description Time ± amounts of time Cost ± amounts of planned budget Quality Defines product quality targets in terms of ranges Scope Keeps scope creep under control (use MoSCoW) Benefits Defines measurable target benefits: e.g. cost savings 5% Risk Limit on the total value of threats

Where are tolerances described?

Corporate,Programme,orCustomer

ProjectBoard

ProjectManager

TeamManager

ProjectTolerances

StageTolerances

WPTolerances

Projectexception

Stageexception

Raiseissue

Tolerances Time Cost Scope Risk Quality Benefits

ProjectLevel

ProjectPlan

ProjectPlan

ProjectPlan RiskM.A. PPD,PD’s Business

Case

StageLevel StagePlan StagePlan StagePlan StagePlan --- ---

WorkPackageLevel

WorkPackage

WorkPackage

WorkPackage

WorkPackage --- ---



11.4 Types of control Event-driven and time-driven controls

PRINCE2 controls can be divided into 2 parts in PRINCE2: event-driven and time-driven. Event-driven controls take place when something happens, in other words when an event happens in the project: e.g. end of a stage, when a stage goes out of tolerance, new issue.

Time-driven controls take place at pre-defined periodic intervals. E.g. send a highlight report every 2 weeks to the project board.

Baseline for progress control These management products assist the project manager in controlling the project:

Project plan: Includes the project level performance targets and tolerances Stage plan: Day-to-day control of the stage and details stage-level tolerances Exception plan: May be requested by the project board after considering an exception report Work package: An agreement between the PM and TM as to the products to be completed

11.5 How does the project manager review progress? This diagram gives (product map) gives an overview of all documents that can be used to manage the project. This diagram shows when management products are created and updated.

Using the issue register The issue register contains all formal issues raised during the project, which could be:

1. Request for change: Clients wants to change a baselined product description 2. Off-specification: When supplier may not complete something as described. 3. Problems and concerns: Note any other comments, problems, and concerns.

Using the quality register The quality register is a record of all planned and executed quality activities during the project and the PM can see if planned quality activities are done and if results are as expected.

Using the reports Checkpoint reports: Team manager reports to the PM on progress of work package work.

End project report: Produced by the PM at the end of the project during the CP process and is used by the project board to evaluate the project before they make the decision to authorize closure.

Del

iver

yTe

am m

anag

erD

irect

ion

Proj

ect B

oard

CPC

Authorizeinitiation

Authorizethe project

Authorize a stage or exception plan

Give ad hoc direction

Auth. projectclosure

Checkpoint reports

Directing a project

Initiation – 1st Stage (Planning) Closingaproject

Projectmandate

Corporate, programme management, customer

End stage reportCS: Highlight report

Team plan

CS: Issue/exc. reportsNext stage plan IS plan

Communication M.A.Change control approachQuality M.A. Risk M.A.

Business case

Project plan

Benefits M.A.

or exception plan

Controlling a stage Created

Business case Stage Boundary: Updated

Stage Boundary: Created

Project plan

Product delivery: Created Updated

Man

agem

ent

Proj

ect m

anag

er

Work packages

-- Team manager is also responsible -- Created once during project (can be updated)-- Created or updated once per stage-- Created or updated many times during a stage -- Once per work package-- Many per work package

PIDProject controls

PMT – rolesProject approach

Pre-Project

End project report

Follow on actions

Lessons report

Draft closure not.

Benefits M.A.Updated

Created

Business case

Project plan

CS: Risk registerCS: Issue registerCS: Lessons logCS: Daily log CS: CIR

Project brief

CIR docs (cmdb)

LessonslogDailylog

Risk,Quality, Issueregisters

+ Acceptance Records

TM assists with planning

*

-- Outline BC-- PPD -- Approach-- PMT

PBSPDsPFD

**

Quality register

Controlling a stage Updated

Starting upa project

Closing a project

Deliverystages:Controllingastage&stageboundary

e.g.

80%

New requirements?Issue/Risk register

Conf. Item Records

PRINCE2®isa registered trademarkofAXELOSLimited.TheSwirl logo™ isatrademarkofAXELOSLimited.

Stage Boundary: Created

Product status account

Benefits M.A.



Exception report: This is an issue report that documents an issue that is out of tolerance. It is produced by the PM when a stage plan or project plan is forecast to exceed agreed tolerance levels.

Highlight report: This is created by PM to report on the status of the current stage compared to the stage plan. (1- to 2-page report). Tip: Think of the tip of an iceberg.

End stage report: This report is created by the PM towards the end of the stage and compares the performance of the stage to the stage plan. It is used by the project board to check the performance of the last stage and help with the next decision.

Lessons Log: A PRINCE2 principle is that the project team must learn from experience. Lessons have to be sought, recorded, and executed during the project. Any useful experiences are then recorded into a lessons log.

Lessons report: This is used to document lessons that might be of value to future projects. A lessons learned report should be created at the end of the project during the CP process and in larger projects, a lessons learned report might be created during the project.

Highlight'report'#'4

Time:"+5%,"this"is"inside"the"tolerances" set"for"the"Stage"Cost:" "�0%

End"of"the"second"week"of"Stage"2,"for"a"period" of"one"week.1.#Date#and#period#of#the#report

Time:"+5%""|""Cost:"�0""|""The"Project" is"going"well"so"far.2.#Status#summary

• Selected"supplier:" Completed• Catalogs"of"pens:" Completed"• Short"list"of"pens"to"be"evaluated:"Completed"• Purchase"order" for"evaluation"pens:"Not" finished"• Sample"evaluation"pens"arrived:"Not" started"• Logo:" Completed

3.#Work#Packages#in#this#period

Date:#Document: Project: Pen#Project Author: Project#Manager

We"fell"behind"schedule" because"the"supplier" sent"us"catalogs"three"days"later"than"we"expected."We"will"get"help"from"the"IT"department" for"two"of"our"future"Work"Packages.

6.#Change#requests

5.#Stage#tolerances

• Purchase"order" of"pens"to"be"evaluated"• Sample"pens"for"evaluation""• List"of"evaluators"• Evaluation"form"

4.#Work#Packages#for#the#next#period

We"might"have"more"delays"in"receiving"evaluation"pens"and"the"final"pens"from"the"supplier.

7.#Key#issues#and#risks

28/6


EndStageReport

• Supplier:Potentialsupplierswerereviewed,andthebestoptionselectedfortheproject.

• Evaluationpens:Fourofthepenswereselectedtobeevaluatedinthenextstage.

• InternalEvaluation:Evaluatorsare selected• Logo:Logowaspreparedtobeprintedonthepens.

Thisstagewentwell,wewere onscheduleandonbudget.Wehadsomeminordelaysinthemiddleofthestage,whichwecouldrecoverwiththehelpoftheITDepartment.

1. Project Manager’s report

Thebusinesscasestaysviableandunchanged.We’verealizedthatweare actuallyabletobuyqualitypensin6to8Eurosrange.

2. Review of the business case

• Time: 10days,onschedule• Cost: €560,onbudget• Scope: asdefined• Quality: asdefined• Risks: asdefined• Benefits: asdefined

3. Review of the objectives

Date:Document: Author: Project Manager

Time:0%|Weforecastthecompleteprojectwillbeontime.Cost:-17%|Weforecasttheprojecttobefinishedwithacost17%lessthantheplannedcost.

6. Forecasts

5. Review of the products

Allteammembersspentenoughtimeontheproject,andperformedasplanned.

4. Review of the team performance

Issue:Suppliersweretwoweekslatewithcatalogs.Risk: Suppliermayhaveadelayinpreparingthefinalpens.

7. Issues and risks

None

8. Lessons learned



11.6 Raising exceptions An exception is raised when an agreed tolerance is exceeded or is forecast to be exceeded.

• Team manager raises an issue if they forecast to go out of work package tolerance. • Project manager raises an exception if they forecast to go out of stage tolerance. • Project board raises an exception if they forecast to go out of project tolerance.

11.7 Using stages to control the project Management stages are partitions (chunks) of the project with decision points for the project board between each stage. Management stages are important to project board as stages:

• provide review points at the end of each stage and before the next. can check the viability of the project.

• can authorize one stage at a time • review the end stage report of the last stage and review the plan for the next stage. • can check project progress with the project plan at the end of each stage.

11.8 Roles and responsibilities Role Responsibilities CPC • Provide project tolerances Executive • Provides stage tolerances; makes decisions on the stage exception plans

• Business point of view for the project SU / SS • Ensures that progress remains consistent from their point of view Project manager • Authorizes work packages and monitors progress of stage plans

• Produces reports: highlight, end stage, lessons, end project … • Maintains the project registers and logs

Team manager • Produces checkpoint reports and escalates issues if necessary Project support • Assists with the compilation of reports and maintains registers

11.9 What you need to know • Explain the purpose of the progress theme and related definitions • Describe the minimum PRINCE2 requirement for this theme • Describe how tolerances are defined (levels) • Explain the concept of event-driven and time-driven controls • Explain how baselining documents support progress control • Explain the purpose of the progress management products. • Explain how exceptions are raised (e.g. TM raises an issue) • Aware of the progress roles and responsibilities (PM and project board)



12 Starting up a project

12.1 Purpose of the SU process The main purpose of this process is to ask the question: “Do we have a worthwhile and viable project?” and prevent poor projects from starting up. This question should be asked for each project idea and then briefly documented (project brief). Typical questions can be:

• How risky is this project compare to other projects? • What is the ROI on this project? • How does it support the organization strategy in the next years?

12.2 Objectives of the SU process • To ensure that: there is a business justification for initiating the project (outline business case) • What is the best way of doing this project? (known as project approach) • Who do we need in the project? (starting with executive and PM) • What is the project going to create (deliver)? Document in the PPD (1 to 3 pages) • Plan the next initiation stage where all the detailed planning will be done

12.3 Project mandate The trigger to start a project is the project mandate, which is provided by a high-level person (a person with authority) within the organization and this can be in any format: Email, document, slide, minutes of a meeting. The more information the better as there will be less work to create the project brief.

Typical contents of a project mandate? • Overview of why is there a need for this project? • Perhaps an overview of what should be delivered by the project? • Perhaps the potential cost and expected ROI and expected benefits? • Who will be the executive?

The SU process will answer these question if the information is not provided in the project mandate

12.4 SU activities

1. CPC appoints the executive and the executive can appoint the project manager. 2. Capture previous lessons. Every is encourages to gather lessons

mandate

DP?Appoint Executiveand

ProjectManager

Capturepreviouslessons

Designandappointtheprojectmanagement

team

Preparetheoutlinebusiness case

+createprojectproductdescription

Selecttheprojectapproachandassemble

theprojectbrief

Plantheinitiationstage

Requesttoinitiateaproject



3. Design and appoint the project management team start with project board and PM 4. Prepare the outline business case (and the PM creates the PPD) 5. Select the project approach and assemble the project brief 6. Create a plan for the initiation stage

The PM will then request the project board to initiate a project and include the project brief and plan for the initiation stage. It is now up to the project board and they will review the project product description and outline business case and then make their first project decision.

This is example of a project brief from the Pen project, it is made up of the following sections:

12.5 SU input / output diagram

SU inputs: • The project mandate is the trigger and PM should also seek lessons

SU outputs (main outputs) • Project product description: e.g. 1- to 3-page description of the main project product • Outline business case: Its objective is to provide some business justification for the project.

Project Brief Date:Document: Project: PenProject Author: Project Manager

Chooseaqualitypenandgiveto±400pensclients.ProjectObjectives• Chooseaqualitythatmeetsspecifications• ChooseapenthatuserswillperceiveasaqualitypenProjectScope:

1. Project DefinitionReasons:Buildabetterrelationshipwithclientsandreducelossintherenewalofmaintenancecontractsby50%.ExpectedBenefits• 50%reducelossofmaintenancecontracts:€42,000• Increasenewmachineordersby2%:€16,200(eachyear)Risks• Clientsmaynotholdontothepenanduseiteachday.Costs• Pencosts:€9by400pens=€3,600• Otherprojectcosts:€600

2. Outline Business Case

Attached:ProjectProductDescription(PPD)3. Project Product Description

Project Tolerances1. Time:3months +30%2. Cost:€9forapen:Estimate€4,200 fortheproject +- 10%3. Quality:Pensmustmeetqualityrequirements

Attached:ProjectManagementTeam(PMT)5. Project Management Team

Thecompanywillchooseapenfromanexistingbusinessgiftcompany.Projectwillberuninternally.

4. ApproachThisprojectusestherolesdescriptionasdefinedbyPRINCE2- Link totheRolesDescriptionsdocument

6. Role Descriptions

3.Client list4.Pensordered

1. Evaluationpensordered2. Penevaluated

CPC

ProjectBoard

ProjectManager

mandate

ProjectBrief

StagePlan

DP?

Requesttoinitiateaproject

Previous lessons

Inputs

Outputs



• Project Management Structure (PMT): Project board, assurance, change authority, PM • Project approach: The team managers will help with this • Initiation stage plan: This is a day-to-day plan for the initiation stage • The final output is to send a request to the project board to initiate the project

12.6 Roles and responsibilities Role Responsibilities CPC • Provides project mandate and appoints the executive Executive • Appoints the project manager (if not done already)

• Approves the PMT and creates the outline business case Senior user • Provides information for project product description Project manager • Facilitates the creation of most of the project brief

• Facilitates the project approach and gathers lessons • Creates the initiation stage plan

Team manager • May be asked to help with project approach and PPD

12.7 What you need to know • Explain the purpose of the SU process • Explain the objectives of the SU process • Explain the context of the SU process (what happens in the SU process and why) • Know the purpose of the project brief



13 Initiating a project

13.1 Purpose of the IP process The purpose of the IP process is to establish a solid foundation (documented in the PID) for the project so the organization can understand the work that needs to be done to deliver the required product.

13.2 Objectives of the IP process The objectives of the IP process are to ensure there is an shared understanding of:

• the reasons for doing the project • the scope: what is to be done and what will not be included (project plan) • how and when the products will be delivered (project plan) • how the required quality will be achieved? • how baselines will be established and controlled • how risks, issues, and changes will be identified and followed up • how project progress will be monitored and who needs to be informed and how often • how PRINCE2 will be tailored to suit the project

13.3 IP activities The SU process checks if the project is viable, the IP process is about building a correct foundation for the project so that all stakeholders are clear on what the project will achieve. The PM will create a collection of management products to show: how the project will be managed, the cost, how quality will be checked, planned, how communication will be done…



• Agree the tailoring requirements for the project • Prepare the risk management approach (how to manage the rules of engagement for risk). • Prepare the change control approach (how to manage changes and products) • Prepare the quality management approach (how to ensure quality) • Prepare the communication management approach, (how communication will be done). • Set up the project controls (how the project board and PM can control the project) • Create the project plan, which covers product descriptions, risks, timescales, and costs. • Refine the business case, which means to complete the business case. • Assemble all IP documentation into the project initiation documentation (PID)

The PM will normally begin with the 4 approach documents and then the project controls and project plan. The business case can then be completed by the PM after the project plan, as the project plan provides information required by the business case (time and cost information).

13.4 IP inputs and outputs IP inputs

• The trigger is the “Authority to initiate a project” which comes from the project board. • The project brief and initiation stage plan come from the SU process

IP outputs (main outputs)

• The 4 management approach documents (quality, risk, change control & communication) • The project management team structure and roles descriptions (part of PID) • The project plan is a plan for the whole project and includes all products descriptions. • The PM will refine (create) the business case in the IP process. • Project controls: An overview of how the project will be controlled (part of PID) • The benefits management approach is an overview of what and when benefits will be

realized, both during and after the project, and who is responsible for these benefits The PID forms a contract between the project manager and the project board.



Request to deliver a project • The final output of the IP process is a request to the project board to deliver the project, or

in other words, to sign off on the PID and allow the project to continue.

13.5 Roles and responsibilities Role Responsibilities Project board • Approve all parts of the PID Executive • Can assist the PM in creating business case

• Approve all parts of the PID Senior user • Provide information and resources for the product descriptions

• Provide information for the benefits management approach Senior supplier • Approve parts of the PID (e.g., project plan, PMT)

• Provide resources to help with planning Project manager • Create the business case and benefits management approach

• Create most of documents required for the PID Team manager • Assist with planning (PBP, Estimating, etc.)

13.6 What you need to know You just need to know the following:

• Explain the purpose of the initiating a project process. • Explain the objectives of the initiating a project process. • Explain the context of the IP process (what happens and why) • Know the purpose of the project initiation documentation (PID)



14 Directing a project

14.1 Purpose and objectives of directing a project Purpose The purpose of this process is to enable the project board to be accountable for the project. They will make key decisions, have overall control and to delegate day-to-day management to the PM.

Objectives The objectives of the directing a project process are to provide authority (project board):

1. To initiate the project (allow the initiation stage to start which is the first decision) 2. To deliver the project’s products (this is done in the delivery stages) 3. To close the project which is the last decision by the project board

Other objectives are to:

• Provide direction and control during the project and be interface to the CPC • Ensure that post-project benefits will be reviewed (see that meetings are planned)

14.2 DP activities There are 5 activities within the directing a project process:

1. Authorize initiation – Allow the initiation stage to start (planning stage) 2. Authorize the project – Allow the delivery stages to start (initiate the project)

3. Authorize a stage or exception plan – Review the existing stage and authorize the next stage or

authorize exception plan to complete the current stage 4. Give ad hoc direction – Project board provides guidance throughout the project 5. Authorize project closure – Shut down the project

14.3 DP inputs and outputs

NextStagePlan

EndStageReport

StagePlan

PID

HighlightReport

IssueReport

ExceptionReport

Authorizeprojectclosure

Giveadhocdirection

Authorizeastageor

exceptionplan

Authorizetheproject

Authorizeinitiation

PID

PIDCPdocs

BenefitsM.A.

ProjectBriefAuthorization

NotificationApprovedDocs

AuthorizationNotification

ApprovedDocs


ApprovedDocs


ApprovedDocs

PrematureCloseExceptionPlanReq

Advice

Inputs Outputs



This diagram gives an overview of the inputs and outputs for each DP activity.

As you read through the above diagram, remember the following: • The project manager provides most of the information to the project board. • Each activity is a decision for the project board. • The main outputs are approvals, authorizations, and notifications.

14.4 Roles and responsibilities Role Responsibilities Project board • All decisions

14.5 What you need to know • Explain the purpose of the DP process • Explain the objectives of the DP process • Explain the context of the DP process • Have a basic understanding of the DP process activities (decision points)



15 Controlling a stage

15.1 Purpose and objectives of controlling a stage Purpose The purpose of this CS process is for the PM to assign the work to be done, monitor this work, deal with issues, report progress to the project board, and take corrective action to ensure that the stage remains within tolerance.

Objectives The objectives of the controlling a stage process are to:

• Ensure that attention is focused on the delivery of the products • Keep risks and issues under control • Keep the business case under review (ask is the project still viable) • Deliver the products for the stage to the agreed quality within agreed cost and time.

15.2 CS activities There are 8 activities within the CS process and they are divided into 3 parts

Work package (WP) activities are: 1. Authorise a WP Assign (handout) and agree with the team manager 2. Review WP status Check on work package status 3. Receive completed WP Check quality and configuration management

Monitoring and reporting activities are: 4. Review the stage status Continually compare status to stage plan 5. Report Highlights Regular reports to the project board

Issues activities are: 1. Capture and assess issues and risks Categorize and assess impact 2. Escalate issues and risks Create exception report and send to the project board 3. Take corrective action Solve issues while keeping stage within tolerance



15.3 CS inputs and outputs The following diagram gives an overview of the main inputs and outputs for the CS process:

CS inputs • The authorization from the project board is the trigger for each stage. • The main inputs are the stage plan (product descriptions) and information in the PID.

CS outputs • Frequent highlight reports are used to keep the project board up to date. • PM constantly reviews issues, risk, quality and updates the issue, risk, and quality registers. • Issue reports (includes change requests) are used to escalate issues to the project board. • Exception reports are used to report if the stage is out of tolerance • The stage boundary process begins towards the end of the current stage.

15.4 Roles and responsibilities Role Responsibilities Project board • Give advice to project manager Project assurance • Give advice to project manager Project manager • All day-to-day activities are performed by the project manager

• Create or update all CS management documents Team manager • Send regular checkpoint reports to project manager (MP process)

15.5 What you need to know • Explain the purpose of the CS process • Explain the objectives of the CS process • Explain the context of the CS process • Have a basic understanding of the CS process activities

Authoritytoinitiate

ProjectBoard

ProjectManager

DP

IP

PID

StagePlan

SB

??

MP

?

Registers(Issue,risk,quality)

StageBoundary

Highlightreports

IssuereportsChangerequests

Exceptionreport

Inputs

Outputs



16 Managing product delivery

16.1 Purpose and objectives of the MP process Purpose The purpose of the MP process is to control the link between the project manager and the team manager(s) by agreeing on the requirements for acceptance, execution, and delivery.

Objectives • Products assigned to the team are authorized and agreed on (work packages) • The team is clear about what has to be produced and understands effort, time, and cost • Planned products are delivered to the quality expectations and within tolerance • Accurate progress information is provided by the team manager

16.2 Managing product delivery activities The managing product delivery process views the project from the team manager’s point of view:

1. Accepting a work package: The team manager accepts the work package 2. Executing a work package: The team produces the products, requests the quality checks,

obtains approval, and reports to the PM using regular checkpoint reports. 3. Delivering a work package: This is showing proof that the products are complete.

16.3 MP inputs / outputs MP inputs

• The PM authorizes the team manager to deliver a work package • The work package contains the information required by the team manager (product descriptions,

quality criteria, tolerances, description of work, frequency of checkpoint reports)

MP outputs • Checkpoint reports are created regularly by the team manager • Quality register is updated when products have passed or failed their quality tests. • Configuration item record (CIR) must be updated because the status of products will change • Accepted products are the products that have been created and delivered. • Completed work package is the notification sent by the team manager to the project manager.

ProjectBoard

ProjectManager

DP

IP

SB

?? ?

Authorizeaworkpackage

Reviewworkpackagestatus

ReceivecompletedWP

Acceptaworkpackage

Executeaworkpackage

Deliveraworkpackage

Controllingastageprocessactivities

Managingproductdelivery



The team manager can also create a team plan to execute the work package.

16.4 Roles and responsibilities Role Responsibilities Project manager • Authorizes work packages (CS process)

• Reviews checkpoint reports & quality register (CS process) • Accepts the completed work from the team manager (CS process)

Team manager • Manages the development of the products • Sends checkpoint reports and raises an issue if out of tolerance

16.5 What you need to know • Explain the purpose of the MP process • Explain the objectives of the MP process • Explain the context of the MP process • Have a basic understanding of the MP process activities

ProjectBoard

ProjectManager

DP

IP

SB

?? ?

Workpackage

Authorizeaworkpackage

Checkpointreports

ProductsQualityregister

Configurationitemrecord

Completedworkpackage

Inputs Outputs



17 Managing a stage boundary

17.1 Purpose and objectives Purpose The purpose of managing a stage boundary process has two parts:

1. The PM must provide the project board with an overview of the performance of the current stage, update the project plan, business case, and create a stage plan for the next stage.

2. The project board reviews these documents and decide to approve the next stage.

Objectives • Assure that all products in the current stage are produced and approved • Review and update the usual documents (business case, project plan) • Record lessons in the lessons log that can help in later stages or in future projects • Prepare the stage plan for the next stage and the request authorization to start the next stage

17.2 SB activities 1. Plan next stage: Create the next stage plan 2. Update the project plan: Confirm what has been done (actuals) 3. Update the business case: Update with the latest costs information 4. Report stage end: Create the end stage report 5. Option: If exception then produce an exception plan (to replace current plan)

17.1 SB inputs and outputs SB inputs

• Stage plan: Compare achievements with expectations • Project plan: This is required for the next stage plan • PID: Both the business case and project plan are updated • Benefits M.A. Benefits information may be updated • Exception report: (Optional) The exception plan will require information from this report

ProjectBoard

ProjectManager

DP?

CS

?

StagePlan

SB

EndStageReport

Business Case

ProjectPlanProducean

exceptionplan

ExceptionPlanrequest

Approachingendofstage

Planthenextstage Updatethe

projectplan

Updatethebusiness case

Requeststageend



SB outputs • The next stage plan or exception plan is created. • The end stage report gives an overview of how well the stage performed. • The business case and project plan are also updated. • Benefits M.A. may be updated The last thing the project manager will do is send a request to the project board to continue with the next stage or go back and complete the current stage.

17.2 Roles and responsibilities Role Responsibilities Project manager • Creates or updates all SB management documents Team manager • Can assist project manager in all planning activities

17.3 What you need to know • Explain the purpose of the SB process • Explain the objectives of the SB process • Explain the context of the SB process • Have a basic understanding of the SB process activities

ProjectBoard

ProjectManager

DP?

CS

?

StagePlan

Exceptionreport

BenefitsM.A.

PID

ExceptionPlanrequest

Approachingendofstage

RegistersLessons Log Endstagereport

Requesttoapprove

Registers

Nextstageplan

Business Case

ProjectPlan

Exceptionplan

BenefitsM.A.

Inputs Outputs



18 Closing a project

18.1 Purpose and objectives Purpose The purpose of the CP process is to provide a fixed point to check that the project has reached its objectives and that the products have been accepted by the customer.

Objectives • Verify user acceptance of the project’s products (delivered by the project) • Ensure that products can be supported after the project • Review the performance of the project • Assess the benefits already realized and plan post project reviews • Address open issues and risks with a follow-up on action recommendations

The project board close the project and the project manager only prepares the project for closure.

18.2 Closing a project activities • Prepare planned closure: Confirm the completion and acceptance of the products • Prepare premature closure: Only if requested by the project board (optional) • Hand over products This is described in the change control approach • Evaluate the project: Compare project objectives and write end project report. • Recommend project closure: Send a notification to the project board

18.3 CP inputs and outputs CP inputs

• There are 2 possible triggers for the closing a project process: a natural close towards the end of the project and a premature close, which comes from the project board.

• All other input documents are used, as the project manager wants to create an end project report and prepare the project for closure.



CP outputs • Lessons report: Lessons will be valuable to future projects and are given to the project board. • Follow-up on action recommendations: Given to the persons who will support the products. • Updated CIR (configuration item records): Keep CIR documents up to date • Draft closure notification: Prepared by PM and sent out by project board to stakeholders • Updated benefits management approach for post benefit reviews • End project report: This is a report on the performance of the project. The PM will use the

project plan, business case, and most other information in the baselined PID. • Finally, the PM will send a closure recommendation to the project board.

18.4 Roles and responsibilities Role Responsibilities Project manager • Create or update all CP management documents

• End project report, lessons report, benefits approach, etc. Project support • Assist the project manager (CIR documents, all records, etc.)

18.5 What you need to know You just need to know the following:

• The purpose of the CP process • The objectives of the CP process • The context of the CP process in relation to the rest of the project • The CP process inputs and outputs

PRINCE2 Foundation Booklet - mplaza.pm · PRINCE2® Foundation Booklet By Frank Turley PRINCE2...

Documents

Transcript of PRINCE2 Foundation Booklet - mplaza.pm · PRINCE2® Foundation Booklet By Frank Turley PRINCE2...