2016 PRINCE2 Quick Guide

PRINCE2 FOUNDATION QUICK GUIDE

Introduction 1.3 What makes projects different? 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. Characteristics of project work: • Change Projects are the means by which we introduce change • Temporary Projects are temporary in nature • Cross-functional Projects involve a team of people with different skills working together • Unique Every project is unique • Uncertainty Projects are more risky and introduce threat and opportunities over and above those that are typical for business as usual Those providing a solution will have different priorities to those with a problem to be solved.

1.5.2 What is it we wish to control? Project management wishes to control six aspects of a project:

• • • • • •

Costs Timescales Quality Scope Risk Benefits

Benefits are the aspect of project performance that ensures that what the project delivers is consistent with achieving the desired return.

1.5.3 The PRINCE2

Structure

of

The PRINCE2 method addresses project management with four integrated elements: • Principles • Themes • Processes • Tailoring PRINCE2 to the project environment Process is a PRINCE2 integrated perspective that offers checklists of products and related responsibilities.

Principles The 7 principles are: • Continued business justification there is a justifiable reason to start a project that remains valid throughout the life of the project; the justification is documented and approved

• Learn from experience • Defined roles and responsibilities • Manage by stages management stages never overlap and have definitive boundaries, there must be a minimum of two man-

agement stages: 1 initiation stage and 1 management stage; technical stages can overlap • Manage by exception don't be afraid to delegate authority • Focus on products • Tailor to suit the project environment

Themes The 7 themes are: • Business case • Organization • Quality • Plans

• Risk • Change • Progress

Process The 7 processes are: • Starting up a Project • Directing a Project • Initiating a Project • Controlling a Stage • Managing Product Delivery • Managing a Stage Boundary • Closing a Project

Principles 2.5 Manage by exception The Manage by exception principle supports the definition of tolerances for each of the project objectives. The Manage by exception principle provides for very efficient use of senior management time.

Themes Business Case 2.1 The Business Case theme mandates that even the simplest of project should have a Business Case.

4.2 Business Case defined 4.2.1 What is a Business Case? The Business Case presents the optimum mix of information used to judge whether the project is (and remains)

desirable, viable and achievable, therefore worthwhile investing in.

4.3 The PRINCE2 approach to the Business Case 4.3.1 Developing the Business Case The Executive is responsible for the Business Case.

4.3.4 The contents of a Business Case The Business Case typically contains: • Executive summary • Reasons • Business options • Expected benefits • Expected dis-benefits • Timescale • Costs • Investment appraisal • Major risks

4.4 Responsibilities Project Assurance covers the primary stakeholder interests (i.e. Business, User and Supplier): • Assisting the Project Manager • Advising on the Risk Management Strategy • Monitoring stage and project progress, changes, finance, i.e. monitoring the Business Case • Reviewing issues

Organization 5.3.2 The project management team 5.3.2.2 Senior Supplier is accountable for the quality of products delivered by the suppliers. 5.3.2.3 The Project Board is responsible, via Project Assurance, for monitoring all aspects of the project’s performance. Project Assurance is an independent check and support of the Project Manager (advice on standards and personnel, etc.). It is appointed as part of the project management team. Project Assurance reports to the Project Board and acts, assures the

Project, on behalf of one or more of its members. Nevertheless, Project Assurance tasks can be shared between Project Board members and other individuals. Do not confuse Project Assurance role with that of Quality Assurance: Project Assurance provides assurance to the project’s stakeholders, whereas Quality Assurance provides assurance to the corporate/programme organization. 5.3.2.4 A request for change or offspecification can be handled by the corporate management or the Project Board. The Project Board may decide to delegate consideration of a request for change to a Change Authority or to the Project Manager. The Project Manager asks the Project Board where the authority for making change lies in the Initiating a Project process. 5.3.2.6 Project Manager PRINCE2 assumes that the Project Manager normally comes from the Customer. 5.3.2.8 Configuration management are technical and administrative activities concerned with the creation, maintenance and controlled change of configuration throughout the life of a product. How, and by whom, the project’s products will be controlled and produced is described in the Configuration Management Strategy. Project Support handles the use of specific planning and control software, as well as some configuration management work after the project is finished. 5.3.2.9 Dealing with changes to the project management team Ideally, the Project Manager and Project Board members should stay with

the project through its life. In practice, however, this may not be always possible. A stage boundary provides an opportunity to hand over the role during the project if this is necessary. If procurement or contracting is to be undertaken during the early stages of the project, when a supplier is selected to develop some the project’s products, the Project Board and other parts of the project management structure may need changes once these stages have been completed and the supplier has been selected.

Quality 6.1 Purpose The purpose of the Quality theme is to define and implement the means by which the project will verify products that are fit for purpose. The Quality theme ensures that the project’s products: • Meet business expectations • Enable the desired benefits to be achieved subsequently. The product focus principle is central.

6.2.3 Quality management and quality management systems Quality management is an activity to direct and control an organization with regard to quality. The organization sponsoring the work creates, maintains and monitors the use of a quality management system.

6.3.1 Quality planning 6.3.1.2 The Project Product Description

The Project Product Description includes: • The overall purpose of the project • Its composition (products it needs to comprise) • The customer’s quality expectations • Acceptance criteria, methods and responsibilities • Project-level quality tolerances Acceptance methods tell us whether and when the project product has been completed and it is acceptable to the customer. 6.3.1.6 The Quality Register The Quality Register is a diary of quality events planned and undertaken (workshops, reviews, inspections, testing, pilots, acceptance and audit). The Quality Register is updated to reflect the actual results from the quality activities, including failures. The Quality Register provides key audit and assurance information.

6.3.2 Quality control 6.3.2.1 Quality methods: • In-process methods: where specialist methods are used in the creation of the products and ongoing inspections • Appraisal methods: where the finished products are assessed for completeness The quality review techniques are meant to provide consultation with a range of interested parties on a product’s fitness for purpose, to involve key interested parties in checking the product’s quality and in promoting wider acceptance of the product. The techniques can be used within the project, as quality controls, and by inde-

pendent experts, as part of quality assurance. When finding a grammatical or spelling mistake in a product under review a reviewer shall annotate the product copy. In a Quality review, the Presenter must provide all reviewers with the relevant review products.

7.3 The PRICE2 approach to plans

Plans

7.3.3 Define and analyze the products

7.2.1 What is a plan? Plan is detailed proposal for doing or achieving something which specifies the what, when, how and by whom. Plans make the backbone of the management information system required for any project. In PRINCE2 there are the following types of plan: Project Plan, Stage Plan, Team Plan, Exception Plan and Benefits Review Plan.

7.2.5 Stage Plans Stage Plans are created near the end of the current management stage.

7.2.7 Exception Plans Exception Plans cover period from the problem to the end of the plan that cannot finish within tolerance, from the present to the end of the current stage. If approved, an Exception Plan replaces the Project Plan or a Stage Plan where appropriate. Exception Report → Exception Plan There’s no Exception Plan for a Work Package: the Team Leader raises an issue and notifies the Project Manager accordingly.

7.3.1 Philosophy Plans are to identify the products required, and only then the activities, dependencies, resources. This is the product-base planning approach which is suggested for all levels of plan.

The sequence of activities in the product-based planning technique: Project Product Description → Product Breakdown Structure → Product Descriptions → Product Flow Diagram

7.3.8 Document the plan Having documented the schedule, the plan, its costs, the required controls and its supporting text need to be consolidated in accordance with the plan design. Narrative needs to be added to explain the plan.

Risk 8.3.5 Risk management procedure 8.3.5.1 Identify The primary goal of the “identify context” step is to obtain information about the project (project environment) in order to understand the specific objectives that are at risk and to formulate the Risk Management Strategy.

8.3.5.2 Assess PRINCE2 recommends that the following is understood: • The probability of the threats and opportunities in terms of how likely they are to occur • The impact of each threat and opportunity in terms of the project objectives • The probability of these threats and opportunities with regard to when they might materialize • How the impact of the threats and opportunities may change over the time of the project. Proximity is the time factor of a risk. 8.3.5.3 Plan When selecting the right action for a risk, the probability/likelihood and impact of a risk occurring must be balanced against the effect of the response on the Business Case. Table 8.2 Risk responses • • • • • • • • •

Avoid (threat) Reduce (threat) Fallback (threat) Transfer (threat) Accept (threat) Share (opportunity) Exploit (opportunity) Enhance (opportunity) Reject (opportunity)

Change 9.1 Purpose Change control is used to identify, document, review and approve all design changes and notifications, in accordance with ISO 9001 requirements.

9.2.3 Issues Issue is any relevant event that has happened, was not planned, and requires management action. It can be a concern, query, request for change, suggestion, observation or offspecification raised during a project. A team member making observations about some aspect of the project would document this by raising an issue.

9.2.4 Types of Issues • Request for change (a proposal for change to a baseline) • Off-specification (something that should be provided by the project but currently is not provided) • Problem/concern (any other issue that the Project Manager needs to resolve or escalate) Issues may be raised at any time during the project, by anyone with an interest in the project or its outcome.

9.3 The PRINCE2 approach to change 9.2.3 Issues The project’s controls for issues, changes and configuration management will be defined and established by the Initiating a Project process and then reviewed and updated if necessary by the Managing a Stage Boundary process. The following products are used to establish the project’s controls: • Configuration Management Strategy • Configuration Item Records • Product Status Account • Daily Log • Issue Register • Issue Reports

9.3.1.5 Issue Register captures and maintains information on all of the issues that are being managed formally where issues are concerns, queries, requests for change, suggestions, observations, off-specifications.

9.3.2 Configuration ment

manage-

Configuration management are technical and administrative activities concerned with the creation, maintenance and controlled change of configuration throughout the life of a product. Five core activities are: • Planning is deciding what level of management will be required by the project and planning how this level will be achieved. • Identification is specifying and identifying all components of the project’s products (configuration items) at the required level of control. • Control is the ability to approve and baseline products and to make changes only with the agreement of appropriate authorities. • Status accounting is the reporting of all current and historical data concerning each product in the form of a Product Status Account. • Verification and audit are a series of reviews and audits to ensure conformity between all products and the authorised state of products as registered in the configuration item records.

9.3.3 Issue and change control procedure 9.3.3.2 Examine The impact analysis should consider the impact the issue has on:

• The project performance targets in terms of time, cost, quality and scope • The project Business Case, especially in terms of the impact on benefits • The project risk profile, i.e. the impact on the overall risk exposure of the project.

Progress 10.3 The PRINCE2 proach to progress

ap-

10.3.1 Delegating authority 10.3.1.1 The four levels of management • Corporate (programme) management sets the overall requirements and tolerance levels for the project • The Project Board has overall control at a project level as long as forecasts remain within project tolerance • The Project Manager has day-today control for a management stage within the tolerance limits laid down by the Project Board • The Team Manager has control for a Work Package and must warn the Project Manager of any threat to the tolerances that are defined in the Work Package Table 10.1 Delegating tolerance and reporting actual and forecast progress Tolerances may be set for time, cost, scope, risk, quality and benefits. • Corporate (programme) management → Project tolerances • Project Board → Stage tolerances • Project Manager → Work Package tolerances

Product Description defines a product’s quality tolerance.

10.3.3 Event-driven and timedriven controls

10.3.2 Use of management stage for control

10.3.3.1 Baselines for progress controls

10.3.2.1 Number of stages

An Exception Plan is a replacement for the plant that can no longer finish within agreed tolerances.

The use of management stages in PRINCE2 is mandatory, but the number of stages is flexible and depends on the scale and risk of the project. Management stages never overlap and have definitive boundaries, there must be a minimum of two management stages: 1 initiation stage and 1 management stage; technical stages can overlap. PRINCE2 stages shall not identify the necessary Work Packages. 10.3.2.3 Technical stages When resolving the problem where the desired management stages do not coincide with the technical stages PRINCE2 suggests breaking down the technical work so that it can be divided over two management stages. Technical stages are typified by the use of a particular set of specialist skills. Management stages equates to commitment of resources and authority to spend. Where a technical stage spans a management stage boundary, the extent to which the product(s) of the technical stage should be complete at the stage boundary should be clear in the Product Description(s).

10.3.3.2 Reviewing progress A Daly Log records actions taken to recover from issues not recorded in the Issue Register. The level of project risk is important for the scheduling of an end stage assessment. 10.3.3.4 Reporting progress • Checkpoint Report provides the Project Manager with details of progress against the Work Package on a regular basis • Highlight Report is a time-drive control that advises the Project Board of the status of the stage; it can also be used to alert the Project Board and give early warning of any possible tolerance problems before an Exception Report is produced • End Stage Report provides the Project Board with the information on the progress to date • End Project Report is produced during the Closing a Project process for the Project Board to evaluate the project and authorise closure

10.3.4 Raising exceptions Exception Report is an event-driven control. An Exception Plan is the subject of an exception assessment. The correct sequence of events: Exception Report → Exception Plan → Exception Assessment.

Process Project mandate → Outline Business Case → Appointing the Executive and the Project Manager → Appointing the project management team → Selecting the project approach → Project Brief → Planning the instating stage → Project Product Description → Project Initiation Document (includes a detailed Business Case, Communication, Configuration, Quality and Risk Management Strategies, a Project Plan)

Starting up a Project 12.1 Purpose The purpose of the Starting up a Project process is to ensure that the prerequisites for initiating the project are in place. Starting up a Project is a pre-project process. The Starting up a Project process turns a project mandate into a Project Brief.

• The various ways the project can be delivered are evaluated and a project approach selected • Individuals are appointed who will undertake the work required in project initiation and will take significant project management roles • The work required for project initiation is planned • Time is not wasted initiating a project based on unsound assumptions.

12.3 Context

Fig. 12.1 Overview of Starting up a Project

The project mandate is a trigger to the process.

The following documents are produced during the Starting up a Project stage: • Project Brief • Lessons Log • Daily Log

12.4 Activities

12.2 Objective The objective of the Starting up a Project process is to ensure that: • There’s a business justification for initiating the project (documented in an outlined Business Case) • All the necessary authorities exist for initiating the project • Sufficient information is available to define and confirm the scope of the project (in the form of a Project Plan)

12.4.1 Appoint the Executive and the Project Manager The Executive and the Project Manager are appointed by the corporate (programme) management before the Project Brief during the Starting up a Project process. Furthermore, role descriptions for the Executive and the Project Manager are provided.

12.4.2 Capture previous lessons The Lessons Log is created.

12.4.3 Design and appoint the project management team Designing a project management team takes place and a project management team structure is created during the Starting up a Project process.

12.4.4 Prepare the outline Business Case The Business Case states why the work is worth doing and, as such, is a crucial element of the project. The outline Business Case is likely to be a high-level view and provides an agreed foundation for a more extensive Business Case developed during the Initiating a Project process. It further makes sure that the customer’s quality expectations are defined.

12.4.6 Plan the initiation stage The Stage Plan (for the initiation stage), not the Project Plan, is the first plan to be created during the Starting up a Project process.

Directing a Project 13.3 Context Directing a Project begins on completion of Starting up a Project. It’s after the Starting up a Project process that the Project Board makes its first formal decision. It is the activity End stage assessment that is meant to allow the Project Board to ensure that the project remains desirable, viable and achievable at all times.

13.4 Activities 13.4.1 Authorize initiation The authorisation of initiation confirms that all members of the project management team have agreed their roles thus supporting the defined roles and responsibilities principle. The Project Board also confirms the customer’s quality expectations and the acceptance criteria described in the Project Product Description, and ensures the investment in initiation is worthwhile. Once the Project Initiation Document has been approved the Project Board can close the project any time.

13.4.2 Authorize the project The Project Initiation Document is an input to the Project Board with a request to deliver the project.

13.4.3 Authorize a Stage or Exception Plan End stage assessment has the objective of allowing the Project Board to ensure that the project remains desirable, viable and achievable at all times; it is also designed to review and approve the Benefits Review Plan and to confirm the strategies and project controls in the Project Initiation Document are adequate for the remainder of the project. An end stage assessment is not specifically meant to approve an Exception Report or review/approve the Benefits Review Plan. Stage tolerance levels are decided and decisions on exception situations are made in the Directing a Project process.

It’s the Directing the Project process that covers the authority to initiate a project.

13.4.4 Give ad hoc direction Decisions on exception situations are made in the Directing a Project process and the activity Give ad hoc direction. The Project Board instructs the Project Manager to produce an Exception Plan. The Project Board can close down a project at any time.

13.4.5 Authorise project closure The Directing a Project process may authorise premature close to the project.

Initiating a Project 14.2 Objective The objective of the Initiating a Project process is to ensure that there is a common understanding of: • The reasons for doing the project, the benefits expected and the associated risks • The scope of what is to be done and the products to be delivered • How and when the project’s products will be delivered and at what cost • Who is to be involved in the project decision making • How the quality requirements will be achieved • How baselines will be established and controlled • How risks, issues and changes will be identified, assessed and controlled • How progress will be monitored and controlled

• Who needs information, in what format, and in what time

14.4.1 Prepare the Risk Management Strategy The Risk Management Strategy includes: • The risk management procedure (identify → assess → plan → implement → communicate) • Tools and techniques to be used • Records to be kept • How the performance of the risk management procedure will be reported • Timing of risk management activities • The roles and responsibilities for risk management activities • The scales to be used for estimating probability and impact • Guidance on how proximity for risks will be assessed The Risk Register is created.

14.4.2 Prepare the Configuration Management Strategy Configuration management is essential for the project to maintain control over its management and specialist products.

14.4.3 Prepare the Quality Management Strategy The Quality Management Strategy includes: • The risk management procedure (quality planning, quality control, quality assurance) • Tools and techniques to be used • Records to be kept • How the performance of the quality management procedure will be reported

• Timing of quality management activities • The roles and responsibilities for quality management activities It is during the Starting up a Project process it is established how the required quality will be achieved.

14.4.6 Create the Project Plan The Project Product Description is refined when creating the Project Plan during the Starting up a Project process.

14.4.7 Refine the Business Case The Project Manager creates the detailed Business Case and a Benefits Review Plan.

Controlling a Stage 15.1 Purpose The purpose of the Controlling a Stage process is to assign work to be done, monitor such work, deal with issues, report progress to the Project Board, and take corrective actions to ensure that the stage remains within tolerance.

15.2 Objective The objective of the Controlling a Stage process is to ensure that: • Attention is focused on delivery of the stage’s products • Risks and issues are kept under control • The Business Case is kept under review • The agreed products for the stage are delivered to stated quality standards, within cost, effort and time agreed

• The project management team is focused on delivery within the tolerances laid down

15.3 Context The Controlling a Stage process describes the work of the Project Manager in handling the day-to-day management of the stage. The process will be used for each delivery stage of a project. The process is normally first used after the Project Board authorizes the project, but it may optionally be used during the initiation stage for large or complex projects with a lengthy initiation.

15.4 Activities 15.4.1 Authorise a Work Package The triggers for the Project Manager to authorise a Work Package include: • Stage authorisation by the Project Board • Exception Plan approval by the Project Board • New Work Package required • Corrective action — in response to an issue or risk A Work Package may include extracts from, or simply cross-reference elements of, the Project Plan, Stage Plan or Project Initiation Document. The Project Manager should: • Examine the Stage Plan • Examine the Project Initiation Document • Define each Work Package to be authorised • Obtain and review the relevant Project Descriptions for inclusion in the Work Package

• Review the Work Package with the Team Manager • Review the Team Manager’s Team Plan • Update the Configuration Item Records • Update the Quality Register • Update the Risk Register if necessary • Update the Issue Register if necessary

15.4.2 Review Work Package status Review Work Package status receives information on Work Package status from the Execute a Work Package activity and gathers details of progress. The Project Manager should: • Collect and review progress from the Checkpoint Reports • Review the Team Plan • Assess the estimated time and effort to complete any unfinished work • Review the Quality Register • Confirm that the Configuration Item Record for each product in the Work Package matches its status • Update the Risk Register if necessary • Update the Issue Register if necessary • Update the Stage Plan for the current stage

15.4.3 Receive completed Work Package The Project Manager would refer to the Configuration Item Records for all products to ensure that they have been approved as anticipated.

15.4.5 Report highlights The Project Manager must provide the Project Board with summary informa-

tion about the status of the sage and project and distribute other information to stakeholders. Among other things the Communication Management Strategy should be reviewed in Project Highlights to confirm who requires a copy of the report.

15.4.6 Capture and examine issues and risks In the activity “capture and examine issues and risks” the Daily Log, Issue Register and Risk Register may be updated and a Risk Report may be created (logged in).

15.4.7 Escalate issues and risks A stage should not exceed the tolerances agreed with the Project Board. The Project Manager can only take corrective actions or maintain the status quo as long as the stage, or the project, is forecast to stay within the tolerances set by the Project Board. In the activity Escalate issues and risks alternative options to recover from an exception situation should be considered. Escalating issues and risks is good practice and should not be seen as failure. The earlier that issues are escalated, the more time is available to implement any corrective actions.

15.4.8 Take corrective action In taking corrective action, the objective is to select and, within the limits of the stage and project tolerances, implement actions that will resolve deviations from the plan.

Managing Project Delivery

Managing a Stage Boundary

16.1 Purpose

17.2 Objective

The purpose of the Managing Project Delivery is to control the link between the Project Manager and the Team Manager(s), by placing formal requirements on accepting, executing and delivering project work.

The objective of the Managing a Stage Boundary process is to: • Assure the Project Board that all products in the Stage Plan for the current stage have been completed and approved • Prepare the Stage Plan for the next stage • Review and, if necessary, update the Project Initiation Document (in particular the Business Case, Project Plan, project approach, strategies, project management team structure and role descriptions) • Provide the information needed for the Project Board to assess the continuing viability of the project including the aggregated risk exposure • Record any information or lessons that can help later stages of this project and/or other projects • Ensure that the Project Board is asked to authorise the start of the next stage

16.3 Context Managing Project Delivery views the project from the Team Manager’s perspective, while the Controlling a Stage process views it from the Project Manager’s perspective. It covers the implementation of a Work Package. The work must be agreed with the Project Manager, done and handed back.

16.4.1 Accept a Work Package The work must be agreed with the Project Manager, done and handed back. Team Plans are produced during the Accept a Work Package process. The Risk Register and the Quality Register are to be updated. The Team Manager will find details of how to deal with a new risk in the Work Package.

16.4.2 Execute a Work Package The work must be conducted in accordance with the required techniques, processes and procedures specified in the Work Package. The Team Manager is required to produce Checkpoint Reports during the creation of products by a team. Approval for developed specialist products as they are completed is obtained as part of the Managing Product Delivery process.

17.4.1 Plan the next stage It is the Quality Register that defines target review and approval dates. The Risk Register is reviewed for the status of risks. The Managing a Stage Boundary process supports the focus on projects principle by documenting the agreed level of quality for each of the deliverables of the next stage. It is recommended that the project management team should be considered for updating at the end of each stage, when preparing the Stage Plan for the next stage. Suitable reviewers are selected for a quality review in planning the relevant stage.

The business justification for the project is reviewed within the Managing a Stage Boundary process.

17.4.2 Update the Project Plan The Project Plan is updated to incorporate actual progress from the stage that is finishing, to include forecast duration and costs from the Exception Report or Stage Plan for the stage about to begin, and to reflect any changed or extra products sanctioned by the Project Board. Benefits already achieved are not used to update the Project Plan.

17.4.3 Update the Business Case

18.3 Context The Stage Plan for the final management stage shall provide for project closure activities.

18.4 Activities Only the Project Board uses the Directing a Project process, and only the Project Manager uses the Controlling a Stage process.

18.4.1 Prepare planned closure The Project Support produces, and the Project Manger and Project Assurance review, a Product Status Account.

The Business Case must be reviewed and updated for the Project Board in the Managing a Stage Boundary process.

The Project Manager produces, and the Project Assurance reviews, a Project Plan.

Closing a Project

Follow-on action recommendations are prepared to pass details on to those who will maintain the product in its operational life when there are items on the Issue Register that the Project Manager put in “pending” status during the project. In the Closing a Project process the Configuration Management Strategy is reviewed for the effectiveness in controlling and protecting all products, examined to confirm how all project files are to be archived and referenced to establish how all products need to be handed over into the operational environment. It is the Closing a Project process that produces operational and maintenance acceptance of products.

18.1 Purpose The purpose of the Closing a Project process is to provide a fixed point at which acceptance for the project product is confirmed, and to confirm that objectives set out in the original Project Initiation Document have been achieved.

18.2 Objective The objective of the Closing a Project process is to: • Verify user acceptance of the project’s products • Ensure that the host site is able to support the products when the project is disbanded • Review the performance of the project against its baselines

18.4.3 Hand over products

18.4.4 Evaluate the project The End Project Report reviews how well the project has been managed.

18.4.5 Recommend project closure PRINCE2 recommends the following actions (by the Project Manager): • Use the Configuration Management Strategy to identify any organization or interested party who needs to know that the project is closing • Close the project’s Issue Register, Risk Register, Quality Register, Daily Log and Lessons Log • Secure and archive all the project files to permit any future audit of the project management team’.

• Prepare and send a draft project closure notification for review by the Project Board

Tailoring PRINCE2 to the project environment 19.4 Projects in a programme environment Programme lifespan tends to cover realization of benefits.

Appendices Appendix A: Product Description Outlines A.1 Benefits Review Plan A.1.1 Purpose A Benefits Review Plan defines how and when a measurement of the achievement of the project’s benefits can be made. The Benefits Review Plan provides a schedule of activities to measure achievement of benefits.

A.2 Business Case A.2.2 Composition • • • • • • • • •

Executive summary Reasons Business options Expected benefits Expected dis-benefits Timescale Costs Investment appraisal Major risks

A.4 Communication Management Strategy A.4.1 Purpose A Communication Management Strategy contains a description of the means and frequency of communication to parties both internal and external to the project.

A.4.2 Composition The Communication Management Strategy includes introduction, tools and techniques, records, reporting, timing of communication activities, roles

and responsibilities, stakeholder analysis, and information needs for each interested party.

A.5 Configuration Item Record A.5.2 Composition • • • • • • • • • • • • • • • • • • • •

Project Identifier Item Identifier Current version Item Title Date of last status change Owner Location Copy holders Item type Item attributes Stage Users Status Product state Variant Producer Date allocated Source Relationship with other items Cross-references

A.10 Exception Report A.10.2 Composition Exception Reports contain exception title and cause, consequences of the deviation, options, recommendation, and lessons.

A.11 Highlight Report A.11.2 Composition Highlight Report contains status summary, information on the reporting period (products completed in the period, achievements) and next reporting period, project and stage tolerance status, requests for change, key issues and risks (actual and potential problems), and lessons report.

• Quality criteria • Quality tolerance • Quality method (type of quality check) • Quality skills required (necessary abilities of the people to review the product) • Quality responsibilities Reviewers (for a Quality Review) must be appointed when the Product Description is written.

A.12 Issue Register

A.19 Project Brief

A.12.1 Purpose

A.19.2 Composition

The Issue Register should be reviewed on a regular basis.

The Project Brief contains: • Project Definition • • • • • • •

Background Project Objectives Desired outcomes Project scope and exclusions Constraints and assumptions Project tolerances The users and other interested parties • Interfaces

A.16 Plan A.16.2 Composition A PRINCE2 Plan contains plan description, plan prerequisites, external dependences, planning assumptions, lessons incorporated, monitoring and control, budgets, tolerances, product descriptions, and schedule. The impact on the Business Case is not listed as an element of a PRINCE2 Plan.

A.17 Product description A.17.2 Composition • • • • • • •

Identifier Title Purpose (why the product is needed) Composition Derivation Format and presentation Development skills required (necessary abilities of the people to create the product)

• • • • • •

Outline Business Case Project Product Description Project approach Role descriptions References No Lessons Log, no strategies

A.20 Project Document

Initiation

A.20.1 Purpose The purpose of the Project Initiation Document is to define the project, in order to form the basis for its management and an assessment of its overall success.

The Project Plan is baselined every time Project Initiation Document is approved and baselined.

A.23 Quality Register

A.20.2 Composition

A.23.2 Composition

The Project Initiation Document contains: • Project Definition • Background

The Quality Register contains: • Quality identifier • Product identifier(s) • Product title(s) • Method • Roles and responsibilities (e.g. identification of the Chair of a Quality Review) • Dates • Result • Quality records

• • • • •

Project Objectives Desired outcomes Project scope and exclusions Constraints and assumptions The users and other interested parties • Interfaces

• • • • • • • •

Project approach Business Case Project management team structure Role descriptions Quality Management Strategy Configuration Management Strategy Risk Management Strategy Communication Management Strategy • Project Plan • Project controls • Tailoring of PRINCE2

A.21 Project Product Description A.21.2 Composition The Project Product Document contains: • Title • Purpose • Composition • Derivation • Development skills required • Customer’s quality expectations • Acceptance criteria • Project-level tolerances • Acceptance method • Acceptance responsibilities

Appendix C: Roles and responsibilities C.3 Senior User C.3.1 Responsibilities The Senior User will: • Provide the customer’s quality expectations and define acceptance criteria for the project • Ensure that the desired outcome of the project is specified • Ensure that the project produces products that will deliver the desired outcomes and meet user requirements • Provide a statement of actual vs. forecast benefits • Resolve user requirements and priority conflicts • Ensure that any user resources required for the project are available • Make decisions on escalated issue • Brief and advise user management on all matters concerning the project • Maintain business performance stability during transition from the project to business as usual

• Provide the user view on follow-on action recommendations • Undertake Project Assurance from the user perspective and, where appropriate, delegate user Project Assurance activities

C.7 Project Assurance C.7.1 Responsibilities A specific responsibility of the Project Assurance is to check that the right people are involved in writing Product Descriptions.

C.9 Project Support C.9.1 Responsibilities The Project Support will: • Set up and maintain project files • Establish document control procedures • Collect actuals and forecasts • Update plans

• Administer or assist the quality review process • Administer or assist Project Board meetings • Assist with the composition of reports • Contribute experience in specialist tools and techniques • Maintain the Quality Register, Configuration Item Records, and other registers/logs • Administer the configuration management procedure (configuration librarian role): the receipt, identification, storage and issue of all project products; providing information on the status of all products; archiving product copies; preservation of the master copies of all product copies; maintaining a record of all copies issued; notifying holders of any changes to their copies; numbering recording, storing and distributing Issue Reports; conducting configuration audits.