A

Product description outlines

 

A Product description outlines

This appendix contains product description outlines for PRINCE2’s defined management products. These are not full product descriptions as defined in section A.17, as some elements, such as quality method, will vary depending on the project’s needs. Format examples are provided, but these are not exhaustive.

Tailoring management product description outlines

Tailoring is described in Chapters 4 and 21. Management products should be tailored to the requirements and environment of each project. This could include the composition, format, quality criteria and naming of the management products. For example:

•Management products can be in other formats and do not necessarily need to be ‘text documents’. They could be slides, spreadsheets or data in information systems, which are brought together, either on screen or as outputs to form reports.

•Reports do not need to be documents. They could be emails, notes of meetings, wall charts or an entry in a daily log. Where verbal reports are used, the information would be incorporated in other reports.

•Management products can be combined for simpler projects where the products fulfil related purposes.

•Management products can be split into smaller parts if it makes them easier to use and maintain.

•Parts of the composition that are not relevant to the project can be added to or left out, or elements can be combined. The composition is not a table of contents; rather it is simply a list of what the product should typically cover and therefore the order of the topics may be changed.

•The PRINCE2 principles of focus on products and learn from experience recognize that projects need to retain information about product status and identified lessons. PRINCE2 does not recommend specific record or report formats for the information, and formal management products are not always used in projects unless there is a specific requirement for the additional information they provide. The following document names are used to show when the information is required in some form; they have outline descriptions of purpose but no recommended composition, derivation, format and presentation, nor any quality criteria:

•configuration item record

•lessons report

•product status account.

The product description outlines in this appendix may be tailored to an organization to create its own set of outlines which would form part of its own PRINCE2-based project management method. To be following PRINCE2, the purpose of each management product must be clearly stated and satisfied. More information on creating an organization’s project management method is given in Chapters 4 and 21.

Types of management products

There are three types of management product: baselines, records and reports.

Baseline management products are those that define aspects of the project and, when approved, are subject to change control. These are:

•A.1 Benefits management approach

•A.2 Business case

•A.3 Change control approach

•A.5 Communication management approach

•A.16 Plan (covers project plans, stage plans, exception plans and, optionally, team plans)

•A.17 Product description

•A.19 Project brief

•A.20 Project initiation documentation (PID)

•A.21 Project product description

•A.22 Quality management approach

•A.24 Risk management approach

•A.26 Work package.

Records are dynamic management products that maintain information regarding project progress. These are:

•A.6 Configuration item record

•A.7 Daily log

•A.12 Issue register

•A.14 Lessons log

•A.23 Quality register

•A.25 Risk register.

Reports are management products providing a snapshot of the status of certain aspects of the project. These are:

•A.4 Checkpoint report

•A.8 End project report

•A.9 End stage report

•A.10 Exception report

•A.11 Highlight report

•A.13 Issue report

•A.15 Lessons report

•A.18 Product status account.

Most of the baseline products evolve during pre-project and initiation stage activities, as shown in Figure A.1. The baseline products are then reviewed and (possibly) updated at the end of each stage or if an exception occurs.

A.1 Benefits management approach

A.1.1 Purpose

A benefits management approach defines the benefits management actions and benefits reviews that will be put in place to ensure that the project’s outcomes are achieved and confirm that the project’s benefits are realized.

If the project is part of a programme, the benefits management approach may be contained within the programme’s benefits realization plan and executed at the programme level. Post-project, the benefits management approach is maintained and executed by corporate, programme management or the customer.

A.1.2 Composition

A benefits management approach includes the following:

•the scope of the benefits management approach covering what benefits are to be managed and measured

•who is accountable for the expected benefits

•what management actions are required in order to ensure that the project’s outcomes are achieved

•how to measure achievement of expected benefits, and when they can be measured

•what resources are needed

•baseline measures from which the improvements will be calculated

•how the performance of the project product will be reviewed.

A.1.3 Derivation

The benefits management approach is derived from the following:

•business case

•project product description (and the acceptance criteria in particular)

•the programme’s benefits management approach and benefits realization plan (when the project is part of a programme)

•the corporate, programme management or customer performance monitoring function (such as a centre of excellence), if one exists.

A.1.4 Format and presentation

A benefits management approach can take a number of formats, including:

•a document, a spreadsheet or presentation slides

•an entry in a project management tool.

A.1.5 Quality criteria

The following quality criteria apply to a benefits management approach:

•It covers all benefits stated in the business case.

•The benefits are measurable and baseline measures have been recorded.

•It describes suitable timing for measurement of benefits, together with reasons for the timing.

•It identifies the skills or individuals who will be needed to carry out the measurements.

•The effort and cost to undertake the benefits reviews are realistic when compared with the value of the anticipated benefits.

•Consideration is given to whether dis-benefits should be measured and reviewed.

A.2 Business case

A.2.1 Purpose

A business case is used to document the business justification for undertaking a project, based on the estimated costs (of development, implementation and incremental ongoing operations and maintenance costs) against the anticipated benefits to be gained and offset by any associated risks. It should outline how and when the anticipated benefits can be measured.

The outline business case is developed in the starting up a project process and refined by the initiating a project process. The directing a project process covers the approval and reaffirmation of the business case.

The business case is used by the controlling a stage process when assessing impacts of issues and risks. It is reviewed and updated at the end of each management stage by the managing a stage boundary process, and at the end of the project by the closing a project process.

A.2.2 Composition

A business case includes the following:

•Executive summary Highlights the key points in the business case, which should include important benefits and the return on investment.

•Reasons Defines the reasons for undertaking the project and explains how the project will enable the achievement of corporate, programme management or customer strategies and objectives.

•Business options Analysis and reasoned recommendation for the base business options of do nothing, do the minimum or do something. ‘Do nothing’ should always be the starting option to act as the basis for quantifying the other options. The difference between ‘do nothing’ and ‘do the minimum’ or ‘do something’ is the benefit that the investment will buy.

The analysis of each option provides the project board and the project’s stakeholders with sufficient information to judge which option presents the best value for the organization. It provides the answer to the question: for this level of investment, are the anticipated benefits more desirable, viable and achievable than the other options available?

The business case for the chosen option should be continually assessed for desirability, viability and achievability as any new risks and/or changes may make one of the other options more justifiable.

•Expected benefits These result from the desired outcomes to be achieved through the use of the project outputs. The benefits are expressed in measurable terms against the situation as it exists prior to the project. Benefits should be both qualitative and quantitative. They should be aligned with corporate, programme management or customer benefits. Tolerances should be set for each benefit and for the aggregated benefit. Any benefits realization requirements should be stated.

The quantification of benefits enables benefits tolerances to be set (e.g. a 10–15 per cent increase in sales) and the measurability of the benefits ensures that they can be proven. If the project includes benefits that cannot be proven, then it is impossible to judge whether the project:

•has been a success

•has provided value for money

•should be (or have been) initiated.

There are many ways to verify the expected benefits. For example, sensitivity analysis can be used to determine whether the business case is heavily dependent on a specific benefit. If it is, this may affect project planning, monitoring and control activities, and risk management, as steps would need to be taken to protect that specific benefit.

•Expected dis-benefits The impact of one or more outcomes of the project might be perceived as negative by one or more stakeholders. Dis-benefits are actual consequences of an activity whereas, by definition, a risk is uncertain and may never materialize. For example, a decision to merge two elements of an organization onto a new site may have benefits (e.g. better joint working), costs (e.g. expanding one of the two sites) and dis-benefits (e.g. drop in productivity during the merger). Dis-benefits need to be valued and incorporated into the investment appraisal.

•Timescale The period over which the project will run (summary of the project plan) and the period over which the benefits will be realized. This information is subsequently used to help timing decisions when planning (project plan, stage plan and benefits management approach).

•Costs A summary of the project costs (taken from the project plan), the ongoing operations and maintenance costs and their funding arrangements.

•Investment appraisal Compares the aggregated benefits and dis-benefits with the project costs (extracted from the project plan) and ongoing incremental operations and maintenance costs. The analysis may use techniques such as cash-flow statement, return on investment, net present value, internal rate of return and payback period. The objective is to be able to define the value of a project as an investment. The investment appraisal should address how the project will be funded.

•Major risks Gives a summary of the key risks associated with the project, together with the likely impact and plans should they occur.

A.2.3 Derivation

A business case is derived from the following:

•project mandate and project brief: reasons

•project plan: costs and timescales

•senior user(s): expected benefits

•executive: value for money

•risk register

•issue register.

A.2.4 Format and presentation

A business case can take a number of formats, including:

•a document, a spreadsheet or presentation slides

•an entry in a project management tool.

A.2.5 Quality criteria

The following quality criteria apply to a business case:

•The reasons for the project must be consistent with the corporate, programme management or customer strategies.

•The project plan must be aligned with the business case.

•The benefits are clearly identified and justified.

•How the benefits will be realized must be clear.

•What defines a successful outcome is described.

•The preferred business option is stated, along with the reasons why.

•Where external procurement is required, the preferred sourcing option is stated, and why.

•How any necessary funding will be obtained is described.

•The business case includes non-financial, as well as financial, criteria.

•The business case includes operations and maintenance costs and risks, as well as project costs and risks.

•The business case conforms to organizational accounting standards (e.g. break-even analysis and cash-flow conventions).

•The major risks faced by the project are explicitly stated, together with any proposed responses.

A.3 Change control approach

A.3.1 Purpose

A change control approach is used to identify, assess and control any potential and approved changes to the project baselines to protect the project’s products. It describes the procedures, techniques and standards to be applied and the responsibilities for achieving an effective issue management and change control procedure.

A.3.2 Composition

A change control approach includes the following:

•Introduction States the purpose, objectives and scope, and identifies who is responsible for the approach.

•Issue management and change control procedure Describes (or refers to) the issue management and change control procedure to be used. Any variance from corporate, programme management or customer standards should be highlighted, together with a justification for the variances. The procedure should cover activities such as capturing issues, assessing their impact, proposing actions, deciding on actions, and implementing actions.

•Tools and techniques Refers to any systems or tools to be used and any preference for techniques that may be used for each step in the issue management and change control procedure.

•Records Defines the composition and format of the issue register.

•Reporting Describes the composition and format of the reports that are to be produced, their purpose, timing and chosen recipients. This should include reviewing the performance of the procedures.

•Timing of issue management and change control and issue activities States when formal activities (e.g. reviews or audits) are to be undertaken.

•Roles and responsibilities Describes who will be responsible for what aspects of the procedures, including any corporate, programme management or customer roles involved with the change control of the project’s products. Describes whether a change authority and/or change budget will be established.

•Scales for priority and severity Describes the scales for prioritizing requests for change and off-specifications and for determining the level of management that can make decisions on the severity of an issue.

A.3.3 Derivation

A change control approach is derived from the following:

•the customer’s quality expectations

•the corporate, programme management or customer tools and systems used for change control (e.g. any software in use or mandated by the user)

•the programme quality management strategy and information management strategy (if the project is part of a programme)

•the user’s quality management system

•the supplier’s quality management system

•specific needs of the project product and environment

•project management team structure (to identify those with change control responsibilities)

•facilitated workshops and informal discussions.

A.3.4 Format and presentation

A change control approach can take a number of formats, including:

•a stand-alone document or a section of the PID

•an entry in a project management tool.

A.3.5 Quality criteria

The following criteria apply to a change control approach:

•Responsibilities are clear and understood by both user and supplier.

•The issue management and change control procedure is clearly documented and can be understood by all parties.

•The chosen change control approach is appropriate for the size and nature of the project.

•Scales are clear and unambiguous.

•The scales are appropriate for the level of control required.

•Reporting requirements are fully defined.

•Resources are in place to administer the chosen method of change control.

A.4 Checkpoint report

A.4.1 Purpose

A checkpoint report is used to report, at a frequency defined in the work package, the status of the work package.

A.4.2 Composition

A checkpoint report includes the following:

•Date The date of the checkpoint

•Period The reporting period covered by the checkpoint report

•Follow-ups The outstanding items from previous reports (e.g. action items completed or unresolved issues)

•This reporting period:

•the products being developed by the team during the reporting period

•the products completed by the team during the reporting period

•quality management activities carried out during the period

•lessons identified

•Next reporting period:

•the products being developed by the team in the next reporting period

•the products planned to be completed by the team in the next reporting period

•quality management activities planned for the next reporting period

•Work package tolerance status How execution of the work package is performing against its tolerances (e.g. cost/time/scope actuals and forecast)

•Issues and risks An update on issues and risks associated with the work package.

A.4.3 Derivation

A checkpoint report is derived from the following:

•work package

•team plan and actuals

•previous checkpoint report.

A.4.4 Format and presentation

A checkpoint report can take a number of formats, including:

•an oral report to the project manager (could be in person or over the phone)

•a presentation at a progress review (physical meeting or conference call)

•a document or email issued to the project manager

•an entry in a project management tool.

A.4.5 Quality criteria

The following quality criteria apply to a checkpoint report:

•The report is prepared at the frequency required by the project manager.

•The level and frequency of progress assessment is right for the management stage and/or work package.

•The information is timely, useful, objective and accurate.

•Every product in the work package, for that period, is covered by the report.

•The report includes an update on any unresolved issues from the previous report.

A.5 Communication management approach

A.5.1 Purpose

A communication management approach contains a description of the means and frequency of communication with parties both internal and external to the project. It facilitates engagement with stakeholders through the establishment of a controlled and bidirectional flow of information.

A.5.2 Composition

A communication management approach includes the following:

•Introduction States the purpose, objectives and scope, and identifies who is responsible for the approach.

•Communication procedure Describes (or refers to) any communication methods to be used. Any variance from corporate, programme management or customer standards should be highlighted, together with a justification for the variance.

•Tools and techniques Refers to any communication tools to be used, and any preference for techniques that may be used, for each step in the communication process.

•Records Defines what communication records will be required and where they will be stored (e.g. logging of external correspondence).

•Reporting Describes any reports on the communication process that are to be produced, including their purpose, timing and recipients (e.g. performance indicators).

•Timing of communication activities States when formal communication activities are to be undertaken (e.g. at the end of a management stage), including performance audits of the communication methods.

•Roles and responsibilities Describes who will be responsible for what aspects of the communication process, including any corporate, programme management or customer roles involved with communication.

•Stakeholder analysis, including:

•identification of the interested party (which may include accounts staff, user forum, internal audit, corporate, programme management or customer quality assurance, competitors, etc.)

•current relationship

•desired relationship

•interfaces

•key messages

•Information needs for each interested party, including:

•information required to be provided from the project

•information required to be provided to the project

•information provider and recipient

•frequency of communication

•means of communication

•format of the communication.

A.5.3 Derivation

A communication management approach is derived from the following:

•the corporate, programme management or customer communications policies (e.g. rules for disclosure for publicly listed companies)

•the programme’s information management strategy

•other components of the PID; in particular, the project management team structure, risk management approach, quality management approach and change control approach

•facilitated workshops/informal discussions with stakeholders

•stakeholder analysis.

A.5.4 Format and presentation

A communication management approach can take a number of formats, including:

•a stand-alone product or a section of the PID

•a document, spreadsheet or mind map

•an entry in a project management tool.

A.5.5 Quality criteria

The following quality criteria apply to a communication management approach:

•All stakeholders have been identified and consulted with regard to their communication requirements.

•There is agreement from all stakeholders about the content, frequency and method of communication.

•A common standard for communication has been considered.

•The time, effort and resources required to carry out the identified communications have been allowed for in stage plans.

•The formality and frequency of communication is reasonable for the project’s importance and complexity.

•For projects that are part of a programme, the lines of communication, and the reporting structure between the project and programme, have been made clear in the communication management approach.

•The communication management approach incorporates corporate, programme management or customer communications facilities where appropriate (e.g. using the marketing communications department for distributing project bulletins).

A.6 Configuration item record

A.6.1 Purpose

Configuration item records are created only if required by the project’s change control approach. Their purpose is to provide a record of such information as the history, status, version and variant of each configuration item, and any details of important relationships between them. If configuration item records are not used, then less formal information about the configuration status of products may be part of the product status information.

The set of configuration item records for a project is often referred to as a configuration library. The records may be derived from:

•the change control approach

•the product breakdown structure

•a stage plan and work package

•the quality register, issue register and risk register.

PRINCE2 does not define the composition, format and presentation, nor any quality criteria for this product.

A.7 Daily log

A.7.1 Purpose

A daily log may be used to record informal issues, required actions or significant events not captured by other PRINCE2 registers or logs. It can act as the project diary for the project manager. It can also be used as a repository for issues and risks during the starting up a project process if the other registers have not been set up.

There may be more than one daily log as team managers may elect to have one for their work packages, separate from the project manager’s daily log. Entries are made when the project manager or team manager feels it is appropriate to log some event. Often entries are based on thoughts, conversations and observations.

PRINCE2 does not define the composition, format and presentation, nor any quality criteria for this product.

A.8 End project report

A.8.1 Purpose

An end project report is used during project closure to review how the project performed against the version of the PID used to authorize it. It also allows the passing on of:

•any lessons that can be usefully applied to other projects

•details of unfinished work, ongoing risks or potential product modifications to the group charged with future support of the project product in its operational life.

A.8.2 Composition

An end project report includes the following:

•Project manager’s report Summarizes the project’s performance

•Review of the business case Summarizes the validity of the project’s business case, including:

•benefits achieved to date

•residual benefits expected (post-project)

•expected net benefits

•deviations from the approved business case

•Review of project objectives Review of how the project performed against its planned targets and tolerances for time, cost, quality, scope, benefits and risk. Evaluates the effectiveness of the project’s approaches and controls

•Review of team performance In particular, provides recognition for good performance

•Review of products, including:

•Quality records Listing the quality activities planned and completed

•Approval records Listing the products and their requisite approvals

•Off-specifications Listing any missing products or products that do not meet the original requirements, and confirmation of any concessions granted

•Project product handover Confirmation (in the form of acceptance records) by the customer that operations and maintenance functions are ready to receive the project product

•Summary of follow-on action recommendations Request for project board advice about who should receive each recommended action. The recommended actions are related to unfinished work, ongoing issues and risks, and any other activities needed to take the products to the next phase of their life

•Lessons A review of what went well, what went badly, and any recommendations for corporate, programme management or customer consideration (and if the project was prematurely closed, then the reasons should be explained). Sourced from the lessons log (see section A.14) or any lessons reports that may exist.

A.8.3 Derivation

An end project report is derived from the following:

•PID

•business case

•project plan

•benefits management approach

•issue register, quality register and risk register

•lessons log

•end stage reports (and exception reports, if applicable).

A.8.4 Format and presentation

An end project report can take a number of formats, including:

•a presentation to the project board (physical meeting or conference call)

•a document or email issued to the project board

•an entry in a project management tool.

A.8.5 Quality criteria

The following quality criteria apply to an end project report:

•Any abnormal situations are described, together with their impact.

•At the end of the project, all issues should either be closed or become the subject of a follow-on action recommendation.

•Any available useful documentation or evidence should accompany the follow-on action recommendation(s).

•Any appointed project assurance roles should agree with the report.

A.9 End stage report

A.9.1 Purpose

An end stage report is used to give a summary of progress to date, the overall project situation, and sufficient information to ask for a project board decision on what to do next with the project.

The project board uses the information in the end stage report in tandem with the next stage plan to decide what action to take with the project; for example, authorize the next stage, amend the project scope or stop the project.

A.9.2 Composition

An end stage report includes the following:

•Project manager’s report Summarizes the management stage performance

•Review of the business case Summarizes the validity of the project’s business case, including:

•benefits achieved to date

•residual benefits expected (remaining management stages and post-project)

•expected net benefits

•deviations from approved business case

•aggregated risk exposure

•Review of project objectives Review of how the project has performed to date against its planned targets and tolerances for time, cost, quality, scope, benefits and risk. Evaluates the effectiveness of the project’s approaches and controls

•Review of management stage objectives Review of how the specific management stage performed against its planned targets and tolerances for time, cost, quality, scope, benefits and risk

•Review of team performance In particular, provides recognition for good performance

•Review of products, including:

•Quality records Listing the quality activities planned and completed in the management stage

•Approval records Listing the products planned for completion in the management stage and their requisite approvals

•Off-specifications Listing any missing products or products that do not meet the original requirements, and confirmation of any concessions granted

•Phased handover (if applicable) Confirmation by the customer that operations and maintenance functions are ready to receive the release

•Summary of follow-on action recommendations (if applicable) Request for project board advice for who should receive each recommended action. The recommended actions are related to unfinished work, ongoing issues and risks, and any other activities needed to take the products handed over to the next phase of their life

•Lessons (if appropriate) A review of what went well, what went badly, and any recommendations for corporate, programme management or customer consideration. Sourced from the lessons log (see section A.14) or any lessons reports that may exist

•Issues and risks Summary of the current set of issues and risks affecting the project

•Forecast The project manager’s forecast for the project and next management stage against planned targets and tolerances for time, cost, quality, scope, benefits and risk.

Where the end stage report is being produced at the end of the initiation stage, not all the above content may be appropriate or necessary.

A.9.3 Derivation

An end stage report is derived from the following:

•current management stage plan and actuals

•project plan

•benefits management approach

•risk register, quality register and issue register

•exception report (if applicable)

•lessons log

•completed/slipped work packages

•updated business case.

A.9.4 Format and presentation

An end stage report can take a number of formats, including:

•a presentation to the project board (physical meeting or conference call)

•a document or email issued to the project board

•an entry in a project management tool.

A.9.5 Quality criteria

The following quality criteria apply to an end stage report:

•The report clearly shows management stage performance against the plan.

•Any abnormal situations are described, together with their impact.

•Any appointed project assurance roles agree with the report.

A.10 Exception report

A.10.1 Purpose

An exception report is produced when a stage plan or project plan is forecast to exceed tolerance levels set. It is prepared by the project manager in order to inform the project board of the situation, and to offer options and recommendations for the way to proceed.

A.10.2 Composition

An exception report includes the following:

•Exception title An overview of the exception being reported

•Cause of the exception A description of the cause of a deviation from the current plan

•Consequences of the deviation What the implications are if the deviation is not addressed for:

•the project

•corporate, programme management or the customer

•Options What options are available to address the deviation and the effect of each option on the business case, risks and tolerances

•Recommendation Of the available options, which is recommended, and why?

•Lessons What can be learned from the exception, on this project or future projects?

A.10.3 Derivation

An exception report is derived from the following:

•current plan and actuals

•issue register, risk register and quality register

•highlight reports, issue reports (for management stage/project-level deviations) or checkpoint reports (for team-level deviations)

•project board advice of an external event that affects the project.

A.10.4 Format and presentation

An exception report can take a number of formats, including:

•an issue raised at a minuted progress review (physical meeting or conference call)

•a document or email issued to the next higher level of management

•an entry in a project management tool.

For urgent exceptions, it is recommended that the exception report is oral in the first instance, and is then followed up in the agreed format.

A.10.5 Quality criteria

The following quality criteria apply to an exception report:

•The current plan must accurately show the status of time and cost performance.

•The reason(s) for the deviation must be stated, the exception clearly analysed, and any impacts assessed and fully described.

•The implications for the business case have been considered and the impact on the overall project plan has been calculated.

•Options are analysed (including any risks associated with them) and recommendations are made for the most appropriate way to proceed.

•The exception report is given in a timely and appropriate manner.

A.11 Highlight report

A.11.1 Purpose

A highlight report is used to provide the project board (and possibly other stakeholders) with a summary of the management stage status at intervals defined by them. The project board uses the report to monitor management stage and project progress. The project manager also uses it to advise the project board of any potential problems or areas where the project board could help.

A.11.2 Composition

A highlight report includes the following:

•Date The date of the report

•Period The reporting period covered by the highlight report

•Status summary An overview of the status of the management stage at this time

•This reporting period:

•work packages, including those pending authorization, in execution, and completed in the period (if the work packages are being performed by external suppliers, this information may be accompanied by purchase order and invoicing data)

•products completed in the period

•products planned but not started or completed in the period (providing an early warning indicator or potential breach of time tolerance)

•corrective actions taken during the period

•Next reporting period:

•work packages, including those to be authorized, in execution and to be completed during the next period (if the work packages are being performed by external suppliers, this information may be accompanied by purchase order and invoicing data)

•products to be completed in the next period

•corrective actions to be completed during the next period

•Project and management stage tolerance status How execution of the project and management stage are performing against their tolerances (e.g. cost/time actuals and forecast)

•Requests for change Raised, approved/rejected and pending

•Key issues and risks Summary of actual or potential problems and risks

•Lessons (if appropriate) A review of what went well, what went badly, and any recommendations for corporate, programme management or customer consideration. Sourced from the lessons log (see section A.14) or any lessons reports that may exist.

A.11.3 Derivation

A highlight report is derived from the following:

•PID

•checkpoint reports

•issue register, quality register and risk register

•stage plan and actuals

•communication management approach.

A.11.4 Format and presentation

A highlight report can take a number of formats, including:

•a presentation to the project board (physical meeting or conference call)

•a document or email issued to the project board

•an entry in a project management tool

•a wall chart or Kanban board.

A.11.5 Quality criteria

The following quality criteria apply to a highlight report:

•The level and frequency of progress reporting required by the project board are right for the management stage and/or project.

•The project manager provides the highlight report at the frequency, and with the content, required by the project board.

•The information is timely, useful, accurate and objective.

•The report highlights any potential problem areas.

A.12 Issue report

A.12.1 Purpose

The purpose of the issue register is to capture and maintain information on all the issues that are being formally managed. The issue register should be monitored by the project manager on a regular basis.

A.12.2 Composition

The composition of the issue register will be defined in the change control approach. For each entry in the issue register, the following should be recorded:

•Issue identifier Provides a unique reference for every issue entered into the issue register. It will typically be a numeric or alphanumeric value

•Issue type Defines the type of issue being recorded, namely:

•request for change

•off-specification

•problem/concern

•Date raised The date on which the issue was originally raised

•Raised by The name of the individual or team who raised the issue

•Issue report author The name of the individual or team who created the issue report

•Issue description Describes the issue, its cause and impact

•Priority This should be given in terms of the project’s chosen categories. Priority should be re-evaluated after impact analysis

•Severity This should be given in terms of the project’s chosen scale. Severity will indicate what level of management is required to make a decision on the issue

•Status The current status of the issue and the date of the last update

•Closure date The date the issue was closed.

A.12.3 Derivation

The issue register is derived in the following way:

•Entries are initially made on the issue register when a new issue is raised.

•The issue register is updated as the issue is progressed. When the issue has been resolved, the entry in the issue register is closed.

A.12.4 Format and presentation

The format of the issue register will be defined in the change control approach. It can take a number of formats, including:

•a document, spreadsheet or database

•a stand-alone register or a carry-forward in the minutes of progress review meetings

•an entry in a project management tool

•a part of an integrated project register for all risks, actions, decisions, assumptions, issues, lessons, etc.

A.12.5 Quality criteria

The following quality criteria apply to an issue register:

•The status indicates whether action has been taken.

•The issues are uniquely identified, including information about which product they refer to.

•A process is defined by which the issue register is to be updated.

•Entries on the issue register that, upon examination, are in fact risks, are transferred to the risk register and the entries annotated accordingly.

•Access to the issue register is controlled and the register is kept in a safe place.

A.13 Issue register

A.13.1 Purpose

An issue report is a report containing the description, impact assessment and recommendations for a request for change, off-specification or a problem/concern. It is created only for those issues that need to be handled formally.

The report is initially created when capturing the issue, and updated both after the issue has been assessed and when proposals are identified for issue resolution. The issue report is later amended further in order to record what option was decided upon, and finally updated when the implementation has been verified and the issue is closed.

A.13.2 Composition

The composition of the issue report will be defined in the change control approach. It includes the following:

•Issue identifier As shown in the issue register (provides a unique reference for every issue report)

•Issue type Defines the type of issue being recorded, namely:

•request for change

•off-specification

•problem/concern

•Date raised The date on which the issue was originally raised

•Raised by The name of the individual or team who raised the issue

•Issue report author The name of the individual or team who created the issue report

•Issue description Describes the issue in terms of its cause and impact

•Impact analysis A detailed analysis of the likely impact of the issue. This may include, for example, a list of products impacted

•Recommendation A description of what the project manager believes should be done to resolve the issue (and why)

•Priority This should be given in terms of the project’s chosen scale. It should be re-evaluated after impact analysis

•Severity This should be given in terms of the project’s chosen scale. Severity will indicate what level of management is required to make a decision on the issue

•Decision The decision made (accept, reject, defer or grant concession)

•Approved by A record of who made the decision

•Decision date The date of the decision

•Closure date The date that the issue was closed.

A.13.3 Derivation

An issue report is derived from the following:

•highlight report(s), checkpoint report(s) and end stage report(s)

•stage plan, together with actual values and events

•users and supplier teams working on the project

•the application of quality controls

•observation and experience of the processes

•quality register, risk register and lessons log

•completed work packages.

A.13.4 Format and presentation

The format of the issue report will be defined in the change control approach. Its various formats include:

•a document, spreadsheet or database

•an entry in a project management tool.

Not all entries in the issue register will need a separately documented issue report.

A.13.5 Quality criteria

The following quality criteria apply to an issue report:

•The issue stated is clear and unambiguous.

•A detailed impact analysis has occurred.

•All implications have been considered.

•The issue has been assessed for its effect on the tolerances.

•The issue has been correctly registered in the issue register.

•Decisions are accurately and unambiguously described.

A.14 Lessons log

A.14.1 Purpose

The lessons log is a project repository for lessons that apply to this project or future projects. Some lessons may originate from other projects and should be captured on the lessons log for input to the project’s approaches and plans. Some lessons may originate from within the project, where new experience (both good and bad) can be passed on to others.

A.14.2 Composition

For each entry in the lessons log, the following should be recorded:

•Lesson type Defines the type of lesson being recorded, namely:

•project (to be applied to this project)

•corporate, programme management or the customer (to be passed on to corporate, programme management or the customer)

•both project and corporate, programme management or the customer

•Lesson detail The detail may include:

•event

•effect (e.g. positive/negative financial impact)

•causes/trigger

•whether there were any early warning indicators

•recommendations

•whether it was previously identified as a risk (threat or opportunity)

•Date logged The date on which the lesson was originally logged

•Logged by The name of the person or team who raised the lesson

•Priority In terms of the project’s chosen categories.

A.14.3 Derivation

The lessons log is derived from the following:

•lessons from other projects

•project mandate or project brief

•daily log, issue register, quality register and risk register

•checkpoint reports and highlight reports

•completed work packages

•stage plans with actuals

•observation and experience of the project’s processes.

A.14.4 Format and presentation

A lessons log can take a number of formats, including:

•a document, spreadsheet or database

•a stand-alone log or a carry-forward in the minutes of progress review meetings

•an entry in a project management tool

•a part of an integrated project register for all risks, actions, decisions, assumptions, issues, lessons, etc.

A.14.5 Quality criteria

The following quality criteria apply to the lessons log:

•The status indicates whether action has been taken.

•Lessons are uniquely identified, including to which product they refer.

•A process is defined by which the lessons log is to be updated.

•Access to the lessons log is controlled.

•The lessons log is kept in a safe place.

A.15 Lessons report

A.15.1 Purpose

A lessons report may be produced to support the lessons log if more information is required. It can be used to pass on any lessons that can be usefully applied to other projects.

The purpose of the report is to provoke action so that the positive lessons become embedded in the organization’s way of working, and so that the organization is able to avoid any negative lessons on future projects.

A lessons report can be created at any time in a project and should not necessarily be delayed until the end. Typically it can be included as part of the end stage report and end project report. It may be appropriate (and necessary) for there to be several lessons reports specific to the particular organization (e.g. user, supplier, corporate or programme).

The data in the report should be used by the corporate group that is responsible for the quality management system, in order to refine, change and improve the standards. Statistics on how much effort was needed for products can help improve future estimating.

A lessons report may be derived from:

•the PID (for the baseline position)

•the lessons log (for identification of lessons)

•the quality register, issue register and risk register (for statistical analysis)

•quality records (for statistical analysis)

•the communication management approach (for the distribution list).

PRINCE2 does not define the composition, format and presentation, nor any quality criteria for this product.

A.16 Plan

A.16.1 Purpose

A plan provides a statement of how and when objectives are to be achieved, by showing the major products, activities and resources required for the scope of the plan. In PRINCE2, there are three levels of plan: project, stage and team. Team plans are optional and may not need to follow the same composition as a project plan or stage plan.

An exception plan is created at the same level as the plan that it is replacing.

A project plan provides the business case with planned costs, and it identifies the management stages and other major control points. It is used by the project board as a baseline against which to monitor project progress.

Stage plans cover the products, resources, activities and controls specific to the management stage and are used as a baseline against which to monitor management stage progress.

Team plans (if used) could comprise just a schedule appended to the work package(s) assigned to the team manager.

A plan should cover not just the activities to create products but also the activities to manage product creation, including activities for assurance, quality management, risk management, change control, communication and any other project controls required.

A.16.2 Composition

A plan includes the following:

•Plan description A brief description of what the plan encompasses (i.e. project, stage, team, exception) and the planning approach

•Plan prerequisites Any fundamental aspects that must be in place, and remain in place, for the plan to succeed

•External dependencies Dependencies that may influence the plan

•Planning assumptions Assumptions upon which the plan is based

•Delivery approach(es) A description of the approaches to be used

•Lessons incorporated Details of relevant lessons from previous similar projects, which have been reviewed and accommodated within this plan

•Monitoring and control Details of how the plan will be monitored and controlled

•Budgets Time and cost budgets, including provisions for risks and changes

•Tolerances Time, cost and scope tolerances for the level of plan (which may also include more specific management-stage- or team-level risk tolerances)

•Product descriptions (see section A.17) Descriptions of the products within the scope of the plan (for the project plan this will include the project’s products; for the stage plan this will be the management stage products; and for a team plan this should be a reference to the work package assigned). Quality tolerances will be defined in each product description

•Schedule This may include graphical representations as:

•a Gantt or bar chart

•a product breakdown structure (see Appendix D for examples)

•a product flow diagram (see Appendix D for an example)

•an activity network

•a table of resource requirements, by resource type (e.g. four engineers, one test manager, one business analyst)

•a table of requested/assigned specific resources, by name (e.g. Nikki, Jay, Francesca).

A.16.3 Derivation

A plan is derived from the following:

•project brief

•quality management approach (for quality management activities to be included in the plan)

•risk management approach (for risk management activities to be included in the plan)

•communication management approach (for communication management activities to be included in the plan)

•change control approach

•resource availability

•registers and logs.

A.16.4 Format and presentation

A plan can take a number of formats, including:

•a stand-alone document or a section of the PID

•a document, spreadsheet, presentation slides or mind map

•an entry in a project management tool.

The schedule may be in the form of a product checklist (which is a list of the products to be delivered within the scope of the plan, together with key status dates such as draft ready, quality inspected, approved, etc.) or the output from a project planning tool. Table A.1 provides an example of a product checklist.

A.16.5 Quality criteria

The following quality criteria apply to a plan:

•The plan is achievable.

•Estimates are based on consultation with those responsible for the people who will undertake the work, and/or historical data.

•Team managers agree that their part of the plan is achievable.

•It is planned to an appropriate level of detail (not too much, not too little).

•The plan conforms to required corporate, programme management or customer standards.

•The plan incorporates lessons from previous projects.

•The plan incorporates any legal requirements.

•The plan covers management and control activities (such as quality) as well as the activities to create the products in scope.

•The plan supports the quality management approach, change control approach, risk management approach, communication management approach and project approach.

•The plan supports the management controls defined in the PID.

A.17 Product description

A.17.1 Purpose

A product description is used to:

•understand the detailed nature, purpose, function and appearance of the product

•define who will use the product

•identify the sources of information or supply for the product

•identify the level of quality required of the product

•enable identification of activities to produce, review and approve the product

•define the people or skills required to produce, review and approve the product.

A.17.2 Composition

A product description includes the following:

•Identifier Unique key, probably allocated by the change control method and likely to include the project name, item name and version number

•Title Name by which the product is known

•Purpose This defines the purpose that the product will fulfil and who will use it. Is it a means to an end or an end in itself? It is helpful in understanding the product’s functions, size, quality, complexity, robustness, etc.

•Composition This is a list of the parts of the product. For example, if the product were a report, this would be a list of the expected chapters or sections

•Derivation What are the source products from which this product is derived? Examples are:

•a design is derived from a specification

•a product is bought in from a supplier

•a statement of the expected benefits is obtained from the user

•a product is obtained from another department or team

•Format and presentation The characteristics of the product; for example, if the product were a report, this would specify whether the report should be a document, presentation slides or an email

•Development skills required An indication of the skills required to develop the product or a pointer to which area(s) should supply the development resources. Identification of the actual people may be left until planning the management stage in which the product is to be created

•Quality criteria To what quality specification must the product be produced, and what quality measurements will be applied by those inspecting the finished product? This might be a simple reference to one or more common standards that are documented elsewhere, or it might be a full explanation of some yardstick to be applied. If the product is to be developed and approved in different states (e.g. dismantled machinery, moved machinery and reassembled machinery), then the quality criteria should be grouped into those that apply for each state

•Quality tolerance Details of any range in the quality criteria within which the product would be acceptable

•Quality method The kinds of quality method (e.g. design verification, pilot, test, inspection or review) that are to be used to check the quality or functionality of the product

•Quality skills required An indication of the skills required to undertake the quality method or a pointer to which area(s) should supply the checking resources. Identification of the actual people may be left until planning the management stage in which the quality inspection is to be done

•Quality responsibilities These define the producer, reviewer(s) and approver(s) for the product.

A.17.3 Derivation

A product description is derived from the following:

•product breakdown structure

•the end-users of the product

•quality management approach

•change control approach.

A.17.4 Format and presentation

A product description can take a number of formats, including:

•a document, presentation slides or mind map

•an entry in a project management tool.

A.17.5 Quality criteria

The following quality criteria apply to a product description:

•The purpose of the product is clear and is consistent with that of other products.

•The product is described to a level of detail that is sufficient to plan and manage its development.

•The product description is concise yet sufficient enough to enable the product to be produced, reviewed and approved.

•Responsibility for the development of the product is clearly identified.

•Responsibility for the development of the product is consistent with the roles and responsibilities described in the project management team organization and the quality management approach.

•The quality criteria are consistent with the project quality standards, standard checklists and acceptance criteria.

•The quality criteria can be used to determine when the product is fit for purpose.

•The types of quality inspection required are able to verify whether the product meets its stated quality criteria.

•The senior user(s) confirms that their requirements of the product, as defined in the product description, are accurately described.

•The senior supplier(s) confirms that the requirements of the product, as defined in the product description, can be achieved.

A.18 Product status account

A.18.1 Purpose

Information about the status of products should be maintained and may be presented, within defined limits, in a product status account. The limits can vary. For example, the report could cover the entire project, a particular management stage, a particular area of the project or the history of a specific product. It is particularly useful if the project manager wishes to confirm the version number of products.

The product status account may be derived from:

•configuration item records

•a stage plan.

PRINCE2 does not define the composition, format and presentation, nor any quality criteria for this product.

A.19 Project brief

A.19.1 Purpose

A project brief is used to provide a full and firm foundation for the initiation of the project and is created in the starting up a project process.

In the initiating a project process, the contents of the project brief are extended and refined in the PID, after which the project brief is no longer maintained.

A.19.2 Composition

A project brief includes the following:

•Project definition Explains what the project needs to achieve. It should include:

•background

•project objectives (covering time, cost, quality, scope, benefits and risk performance)

•desired outcomes

•project scope and exclusions

•constraints and assumptions

•project tolerances

•the user(s) and any other known interested parties

•interfaces

•Outline business case (see section A.2) Reasons why the project is needed and the business option selected. This will later be developed into a detailed business case during the initiating a project process

•Project product description (see section A.21) Includes the customer’s quality expectations, user acceptance criteria, and operations and maintenance acceptance criteria

•Project approach Defines the choice of solution that will be used within the project to deliver the business option selected from the business case. This will take into consideration the operational environment into which the solution must fit and any tailoring requirements (if known)

•Project management team structure A chart showing who will be involved with the project

•Role descriptions These describe the roles of those in the project management team and any other key resources identified at this time

•References These include references to any associated documents or products.

A.19.3 Derivation

A project brief is derived from the following:

•a project mandate supplied at the start of the project

•programme management: if the project is part of a programme, the project brief is likely to be supplied by the programme, and therefore it will not have to be derived from a project mandate

•discussions with corporate, programme management or the customer regarding corporate, programme management or customer strategies and any policies and standards that apply

•discussions with the project board and users if the project mandate is incomplete or if no project mandate is provided

•discussions with the operations and maintenance organization (if applicable)

•discussion with the (potential) suppliers regarding specialist delivery approaches that could be used

•lessons log.

A.19.4 Format and presentation

A project brief can take a number of formats, including:

•a document or presentation slides

•an entry in a project management tool.

A.19.5 Quality criteria

The following quality criteria apply to a project brief:

•It is brief because its purpose at this point is to provide a firm basis on which to initiate a project. It will later be refined and expanded as part of the PID.

•It accurately reflects the project mandate and the requirements of the business and the users.

•The project approach considers a range of solutions, such as: bespoke or off-the-shelf; contracted-out or developed in-house; or designed from scratch or modified from an existing product.

•The project approach selected maximizes the chance of achieving overall success for the project.

•The project objectives and project approaches are consistent with the organization’s social responsibility directive.

•The project objectives are specific, measurable, achievable, relevant and time-bound (SMART).

A.20 Project initiation documentation (PID)

A.20.1 Purpose

The purpose of the PID is to define the project, in order to form the basis for its management and an assessment of its overall success. The PID gives the direction and scope of the project and (along with the stage plan) forms the ‘contract’ between the project manager and the project board.

The three primary uses of the PID are to:

•ensure that the project has a sound basis before asking the project board to make any major commitment to the project

•act as a base document against which the project board and project manager can assess progress, issues and ongoing viability questions

•provide a single source of reference about the project so that people joining the ‘temporary organization’ can quickly and easily find out what the project is about, and how it is being managed.

The PID is a living product in that it should always reflect the current status, plans and controls of the project. Its component products will need to be updated and re-baselined, as necessary, at the end of each management stage, to reflect the current status of its constituent parts.

The version of the PID that was used to gain authorization for the project is preserved as the basis against which performance will later be assessed when closing the project.

A.20.2 Composition

There follows a contents list for the PID. Project definition and project approach are extracted from the project brief:

•Project definition Explains what the project needs to achieve. It should include:

•background

•project objectives and desired outcomes

•project scope and exclusions

•constraints and assumptions

•the user(s) and any other known interested parties

•interfaces

•Project approach Defines the choice of solution and delivery approach that will be used in the project to deliver the business option selected from the business case, taking into consideration the operational environment into which the solution must fit

•Business case (see section A.2) Describes the justification for the project based on estimated costs, risks and benefits

•Project management team structure A chart showing who will be involved with the project

•Role descriptions These describe the roles of those in the project management team and any other key resources

•Quality management approach (see section A.22) Describes the quality techniques and standards to be applied, and the responsibilities for achieving the required quality levels. Where the project is subject to the commissioning organization’s quality management policies/strategies, the PID should make reference to them rather than duplicate them. Where the project is not subject to the commissioning organization’s quality management policies/strategies, appropriate strategies/approaches should be documented

•Change control approach (see section A.3) Describes how and by whom the project’s products will be controlled and protected. Where the project is subject to the commissioning organization’s change control policies/strategies, the PID should make reference to them rather than duplicate them. Where the project is not subject to the commissioning organization’s change control policies/strategies, appropriate strategies/approaches should be documented

•Risk management approach (see section A.24) Describes the specific risk management techniques and standards to be applied, and the responsibilities for achieving an effective risk management procedure. Where the project is subject to the commissioning organization’s risk management policies/strategies, the PID should refer to rather than duplicate them. Where the project is not subject to the commissioning organization’s risk management policies/strategies, appropriate strategies/approaches should be documented

•Communication management approach (see section A.5) Defines the parties interested in the project and the means and frequency of communication between them and the project. Where the project is subject to the commissioning organization’s communication management policies/strategies, the PID should make reference to them rather than duplicate them. Where the project is not subject to the commissioning organization’s communication management policies/strategies, appropriate strategies/approaches should be documented

•Project plan (see section A.16) Describes how and when the project’s objectives are to be achieved, by showing the major products, activities and resources required on the project. It provides a baseline against which to monitor the project’s progress, management stage by management stage

•Project controls Summarizes the project-level controls such as management stage boundaries, agreed tolerances, monitoring and reporting

•Tailoring of PRINCE2 A summary of how PRINCE2 will be tailored for the project.

A.20.3 Derivation

The PID is derived from the following:

•project brief

•discussions with user, business and supplier stakeholders for input on methods, standards and controls.

A.20.4 Format and presentation

The PID could be:

•a single document

•an index for a collection of documents

•a document with cross-references to a number of other documents

•a collection of information sources in a project management tool.

A.20.5 Quality criteria

The following quality criteria apply to a PID:

•The PID correctly represents the project.

•It shows a viable, achievable project that is in line with corporate, programme management or customer strategies or overall programme needs.

•The project management team structure is complete, with names and titles. All the roles have been considered and are backed up by agreed role descriptions. The relationships and lines of authority are clear. If necessary, the project management team structure shows to whom the project board reports.

•It clearly shows a control, reporting and direction regime that can be implemented, appropriate to the scale, risk and importance of the project to corporate, programme management or the customer.

•The controls cover the needs of the project board, project manager and team managers and satisfy any delegated assurance requirements.

•It is clear who will administer each control.

•The project objectives and approaches are consistent with the organization’s social responsibility directive, and the project controls are adequate to ensure that the project remains compliant with such a directive.

•Consideration has been given to the format of the PID. For small projects a single document is appropriate. For large projects, it is more appropriate for the PID to be a collection of stand-alone documents. The volatility of each element of the PID should be used to assess whether it should be stand-alone (e.g. elements that are likely to change frequently are best separated out).

A.21 Project product description

A.21.1 Purpose

The project product description is a special form of product description that defines what the project must deliver in order to gain acceptance. It is used to:

•gain agreement from the user on the project’s scope and requirements

•define the customer’s quality expectations

•define the acceptance criteria, method and responsibilities for the project.

The product description for the project product is created in the starting up a project process as part of the initial scoping activity, and is refined during the initiating a project process when creating the project plan. It is subject to formal change control and should be checked at management stage boundaries (during managing a stage boundary) to see if any changes are required. It is used by the closing a project process as part of the verification that the project has delivered what was expected of it, and that the acceptance criteria have been met.

A.21.2 Composition

The project product description includes the following:

•Title Name by which the project is known

•Purpose This defines the purpose that the project product will fulfil and who will use it. It is helpful in understanding the product’s functions, size, quality, complexity, robustness, etc.

•Composition A description of the major products and/or outcomes to be delivered by the project

•Derivation What are the source products from which this product is derived? Examples are:

•existing products to be modified

•design specifications

•a feasibility report

•the project mandate

•Development skills required An indication of the skills required to develop the product, or a pointer to which area(s) should supply the development resources

•Customer’s quality expectations A description of the quality expected of the project product and/or outcomes and the standards and processes that will need to be applied to achieve that quality. They will impact on every part of the product development, and thus on time and cost. The quality expectations are captured in discussions with the customer. Where possible, expectations should be prioritized

•Acceptance criteria A prioritized list of criteria that the project product and/or outcomes must meet before the customer will accept them. These are measurable definitions of the attributes that must apply to the set of products to be acceptable to key stakeholders and, in particular, the users and the operational and maintenance organizations. Examples are ease of use, ease of support, ease of maintenance, appearance, major functions, development costs, running costs, capacity, availability, reliability, security, accuracy and performance

•Project-level quality tolerances Specification of any tolerances that may apply for the acceptance criteria

•Acceptance method Statement of the means by which acceptance will be confirmed. This may simply be a case of confirming that the project product and/or outcomes have been approved, or may involve describing complex handover arrangements for the project product, including any phased handover of the project product’s components

•Acceptance responsibilities Definition of who will be responsible for confirming acceptance.

A.21.3 Derivation

The project product description is derived from the following:

•project mandate

•discussions with the senior user and executive, possibly via scoping workshops

•request for proposal (if in a commercial customer/supplier environment).

A.21.4 Format and presentation

A product description for the project product can take a number of formats, including:

•a document, presentation slides or mind map

•an entry in a project management tool.

A.21.5 Quality criteria

The following quality criteria apply to a project product description:

•The purpose is clear.

•The composition defines the complete scope of the project.

•The acceptance criteria form the complete list against which the project will be assessed.

•The acceptance criteria address the requirements of all the key stakeholders (e.g. operations and maintenance).

•The project product description defines how the users and the operational and maintenance organizations will assess the acceptability of the finished product(s). It should ensure that:

•all criteria are measurable

•each individual criterion is realistic

•the criteria are consistent as a set. For example, high quality, early delivery and low cost may not go together

•all criteria can be proven within the project life (e.g. the maximum throughput of a water pump) or by proxy measures that provide reasonable indicators as to whether acceptance criteria will be achieved post-project (e.g. a water pump that complies with design and manufacturing standards of reliability)

•The quality expectations have been considered, including:

•the characteristics of the key quality requirements (e.g. fast/slow, large/small, national/global)

•the elements of the customer’s quality management system that should be used

•any other standards that should be used

•the level of customer/staff satisfaction that should be achieved if surveyed.

A.22 Quality management approach

A.22.1 Purpose

A quality management approach describes how quality will be managed on the project. This includes the specific processes, procedures, techniques, standards and responsibilities to be applied.

A.22.2 Composition

A quality management approach includes the following:

•Introduction States the purpose, objectives and scope, and identifies who is responsible for the approach

•Quality management process or procedure A description of (or reference to) the quality management procedure to be used. Any variance from corporate, programme management or customer quality standards should be highlighted, together with a justification for the variance. The process or procedure should cover:

•the approach to quality assurance and quality planning

•quality control: the project’s approach to quality control activities. This may include:

–quality standards

–templates and forms to be employed (e.g. product description(s), quality register)

–definitions of types of quality methods (e.g. inspection, pilot)

–metrics to be employed in support of quality control

•project assurance: the project’s approach to project assurance activities. This may include:

–responsibilities of the project board

–compliance audits

–corporate, programme management or customer reviews

•Tools and techniques Refers to any quality management systems or tools to be used, and any preference for techniques which may be used for each step in the quality management procedure

•Records Definition of what quality records will be required and where they will be stored, including the composition and format of the quality register

•Reporting Describes any quality management reports, including their purpose, timing and recipients

•Timing of quality management activities States when formal quality management activities are to be undertaken (e.g. during audits, when this may involve reference to the quality register)

•Roles and responsibilities Defines the roles and responsibilities for quality management activities, including those with quality responsibilities from corporate, programme management or the customer.

A.22.3 Derivation

A quality management approach is derived from the following:

•project board

•project brief, including:

•the project management team structure (for roles and responsibilities)

•the project product description (for the customer’s quality expectations and acceptance criteria)

•organizational standards

•supplier and customer quality management systems

•change control requirements

•corporate, programme management or customer strategies

•facilitated workshops and informal discussions.

A.22.4 Format and presentation

A quality management approach can take a number of formats, including:

•a stand-alone document or a section of the PID

•an entry in a project management tool.

A.22.5 Quality criteria

The following quality criteria apply to a quality management approach:

•The approach clearly defines ways in which the customer’s quality expectations will be met.

•The defined ways are sufficient to achieve the required quality.

•Responsibilities for quality are defined up to a level that is independent of the project and project manager.

•The approach conforms to the supplier’s and customer’s quality management systems.

•The approach conforms to the corporate, programme management or customer quality policy.

•The approaches to assuring quality for the project are appropriate in the light of the standards selected.

A.23 Quality register

A.23.1 Purpose

A quality register is used to summarize all the quality management activities that are planned or have taken place, and provides information for the end stage reports and end project report. Its purpose is to:

•issue a unique reference for each quality activity

•act as a pointer to the quality records for a product

•act as a summary of the number and type of quality activities undertaken.

A.23.2 Composition

The composition of the quality register will be defined in the quality management approach. For each entry in the quality register, the following should be recorded:

•Quality identifier Provides a unique reference for every quality activity entered into the quality register. It will typically be a numeric or alphanumeric value

•Product identifier(s) Unique identifier(s) for the product(s) that the quality activity relates to

•Product title(s) The name(s) by which the product(s) is known

•Method The method employed for the quality activity (e.g. pilot, quality review, audit, etc.)

•Roles and responsibilities The person or team responsible for the quality management activities (e.g. auditor or, for quality reviews, presenter, reviewer(s), chair, administrator)

•Dates Planned, forecast and actual dates for:

•the quality activity

•sign-off that the quality activity is complete

•Result The result of the quality activity. If a product fails a quality review, then any reassessment should be listed as a separate entry in the register, as the original quality activity has been completed (in deciding that the result is a ‘fail’)

•Quality records The quality inspection documentation, such as a test plan or the details of any actions required to correct errors and omissions of the products being inspected.

A.23.3 Derivation

The quality register is derived in the following way:

•Entries are made when a quality activity is entered on a stage plan for the current management stage. It may be updated when a team plan is created

•The remaining information comes from the actual performance of the quality activity

•The sign-off date is when all corrective action items have been signed off.

A.23.4 Format and presentation

The format of the quality register will be defined in the quality management approach. A quality register can take a number of formats, including:

•a document, spreadsheet or database

•a stand-alone register or a carry-forward in the minutes of progress review meetings

•an entry in a project management tool

•a part of an integrated project register for all risks, actions, decisions, assumptions, issues, lessons, etc.

A.23.5 Quality criteria

The following quality criteria apply to a quality register:

•A procedure is in place that will ensure that every quality activity is entered on the quality register.

•Responsibility for the quality register has been allocated.

•Actions are clearly described and assigned.

•Entries are uniquely identified, including to which product they refer.

•Access to the quality register is controlled.

•The quality register is kept in a safe place.

•All quality activities are at an appropriate level of control.

A.24 Risk management approach

A.24.1 Purpose

A risk management approach describes how risk will be managed on the project. This includes the specific processes, procedures, techniques, standards and responsibilities to be applied.

A.24.2 Composition

The risk management approach includes the following:

•Introduction States the purpose, objectives and scope, and identifies who is responsible for the approach

•Risk management process or procedure Describes (or refers to) the risk management process or procedure to be used. Any variance from corporate, programme management or customer standards should be highlighted, together with a justification for the variance. The process or procedure must describe how:

•risks are identified and assessed

•risk responses are planned and implemented

•risk management activities are communicated

•Tools and techniques Refers to any risk management systems or tools to be used, and any preference for techniques which may be used for each step in the risk management procedure

•Records Defines the composition and format of the risk register and any other risk records to be used by the project

•Reporting Describes any risk management reports that are to be produced, including their purpose, timing and recipients

•Timing of risk management activities States when formal risk management activities are to be undertaken (e.g. at the end of management stages)

•Roles and responsibilities Defines the roles and responsibilities for risk management activities

•Scales Defines the scales for estimating probability and impact for the project to ensure that the scales for cost and time (for instance) are relevant to the cost and timeframe of the project. These may be shown in the form of probability impact grids giving the criteria for each level within the scale (e.g. for ‘very high’, ‘high’, ‘medium’, ‘low’ and ‘very low’)

•Proximity Provides guidance on how proximity for risk events is to be assessed. Proximity reflects the fact that risks will occur at particular times and the severity of their impact will vary according to when they occur. Typical proximity categories will be: imminent, within the management stage, within the project, beyond the project

•Risk categories Defines the risk categories to be used (if at all). These may be derived from a risk breakdown structure or prompt list. If no risks have been recorded against a category, this may suggest that the risk identification has not been as thorough as it should have been

•Risk response categories Defines the risk response categories to be used, which themselves depend on whether a risk is a perceived threat or an opportunity

•Early warning indicators Defines any indicators to be used to track critical aspects of the project so that if certain predefined levels are reached corrective action will be triggered. They will be selected for their relevance to the project objectives

•Risk tolerance Defines the threshold levels of risk exposure which, when exceeded, require the risk to be escalated to the next level of management. (For example, a project-level risk tolerance could be set as any risk that, should it occur, would result in loss of trading. Such risks would need to be escalated to corporate, programme management or the customer.) The risk tolerance should define the risk expectations of corporate, programme management or customer and the project board

•Risk budget Describes whether a risk budget is to be established and, if so, how it will be used.

A.24.3 Derivation

The risk management approach is derived from the following:

•project brief

•business case

•where relevant, any corporate, programme management or customer risk management guides, strategies or policies.

A.24.4 Format and presentation

A risk management approach can take a number of formats, including:

•a stand-alone document

•a section of the PID

•an entry in a project management tool.

A.24.5 Quality criteria

The following quality criteria apply to the risk management approach:

•Responsibilities are clear and understood by both customer and supplier.

•The risk management procedure is clearly documented and can be understood by all parties.

•Scales, expected value and proximity definitions are clear and unambiguous.

•The chosen scales are appropriate for the level of control required.

•Risk reporting requirements are fully defined.

A.25 Risk register

A.25.1 Purpose

A risk register provides a record of identified risks relating to the project, including their status and history. It is used to capture and maintain information on all the identified threats and opportunities relating to the project.

A.25.2 Composition

The composition of the risk register will be derived from the risk management approach. For each entry in the risk register, the following should be recorded:

•Risk identifier Provides a unique reference for every risk entered into the risk register. It will typically be a numeric or alphanumeric value

•Risk author The person who raised the risk

•Date registered The date the risk was identified

•Risk category The type of risk in terms of the project’s chosen categories (e.g. schedule, quality, legal)

•Risk description Describes the risk in terms of the cause, event (threat or opportunity) and effect (in words of the impact)

•Probability, impact and expected value It is helpful to estimate the inherent values (pre-response action) and residual values (post-response action). These should be recorded in accordance with the project’s chosen scales

•Proximity This would typically state how close to the present time the risk event is anticipated to happen (e.g. imminent, within the management stage, within the project, beyond the project). Proximity should be recorded in accordance with the project’s chosen scales

•Risk response categories How the project will treat the risk in terms of the project’s chosen categories. For example:

•for threats: avoid, reduce, transfer, share, accept, prepare contingent plans

•for opportunities: exploit, enhance, transfer, share, accept, prepare contingent plans

•Risk response Actions to be taken to resolve the risk. These actions should be aligned with the chosen response categories. Note that more than one risk response may apply to a risk

•Risk status Typically described in terms of whether the risk is active or closed. Inclusion of a date last amended will help track changes in risk status

•Risk owner The person responsible for managing the risk (there should be only one risk owner per risk)

•Risk actionee The person(s) who will implement the action(s) described in the risk response. This may or may not be the same person as the risk owner.

A.25.3 Derivation

The risk register is derived in the following way:

•Entries are made on the risk register when a new risk is identified.

•There may be one or more inherent risks in the project mandate.

A.25.4 Format and presentation

The format and presentation of the risk register will be derived from the risk management approach. A risk register can take a number of formats, including:

•a document, spreadsheet or database

•sticky notes on a wall chart

•a stand-alone register or a carry-forward in the minutes of progress review meetings

•an entry in a project management tool

•a part of an integrated project register for all risks, actions, decisions, assumptions, issues, lessons, etc.

A.25.5 Quality criteria

The following quality criteria apply to the risk register:

•The status indicates whether action has been taken.

•Risks are uniquely identified, including information about which product they refer to.

•Access to the risk register is controlled.

•The risk register is kept in a safe place.

A.26 Work package

A.26.1 Purpose

A work package is a set of information about one or more required products collated by the project manager to pass responsibility for work or delivery formally to a team manager or team member.

A.26.2 Composition

Although the content may vary greatly according to the relationship between the project manager and the recipient of the work package, it should cover:

•Date The date of the agreement between the project manager and the team manager/person authorized

•Team manager or person authorized The name of the team manager or individual with whom the agreement has been made

•Work package description A description of the work to be done

•Techniques, processes and procedures Any techniques, tools, standards, processes or procedures to be used in the creation of the specialist products

•Development interfaces Interfaces that must be maintained while developing the products. These may be people providing information or those who need to receive information

•Operations and maintenance interfaces Identification of any specialist products with which the product(s) in the work package will have to interface during their operational life. These may be other products to be produced by the project, existing products, or those to be produced by other projects (e.g. if the project is part of a programme)

•Change control requirements A statement of any arrangements that must be made by the producer for:

•version control of the products in the work package

•obtaining copies of other products or their product descriptions

•submission of the product to change control

•any storage or security requirements

•who, if anyone, needs to be advised of changes in the status of the work package

•Joint agreements Details of the agreements on effort, cost, start and end dates, and key milestones for the work package

•Tolerances Details of the tolerances for the work package (the tolerances will be for time and cost but may also include scope and risk)

•Constraints Any constraints (apart from the tolerances) on the work, people to be involved, timings, charges, rules to be followed (e.g. security and safety), etc.

•Reporting arrangements The expected frequency and content of checkpoint reports

•Problem handling and escalation This refers to the procedure for raising issues and risks

•Extracts or references Any extracts or references to related documents, specifically:

•Stage plan extract This will be the relevant section of the stage plan for the current management stage or will be a pointer to it

•Product description(s) This would normally be an attachment of the product description(s) for the products identified in the work package (note that the product description contains the quality methods to be used)

•Approval method The person, role or group who will approve the completed products within the work package, and how the project manager is to be advised of completion of the products and work package.

There should be space on the work package to record both its initial authorization and its acceptance and return as a completed work package. This can be enhanced to include an assessment of the work and go towards performance appraisal.

Projects with common controls across all work packages may simply cross-reference the controls defined in the project plan or stage plan.

A.26.3 Derivation

The work package is derived from the following:

•existing commercial agreements between the customer and supplier (if any)

•quality management approach

•change control approach

•stage plan.

A.26.4 Format and presentation

A work package can take a number of formats, including:

•a document

•a conversation between the project manager and a team manager

•an entry in a project management tool.

The work package will vary in content and in degree of formality, depending on circumstances. Where the work is being conducted by a team working directly under the project manager, the work package may be an oral instruction, although there are good reasons for putting it in writing, such as avoidance of misunderstanding and providing a link to performance assessment. Where the work is being carried out by a supplier under a contract and the project manager is part of the customer organization, there is a need for a formal written instruction in line with the standards laid down in that contract.

A.26.5 Quality criteria

The following quality criteria apply to the work package:

•The required work package is clearly defined and understood by the assigned resource.

•There is a product description for each required product, with clearly identified and acceptable quality criteria.

•The product description(s) matches up with the other work package documentation.

•Standards for the work are agreed.

•The defined standards are in line with those applied to similar products.

•All necessary interfaces have been defined.

•The reporting arrangements include the provision for raising issues and risks.

•There is agreement between the project manager and the recipient on exactly what is to be done.

•There is agreement on the constraints, including effort, cost and targets.

•The dates and effort are in line with those shown in the stage plan for the current management stage.

•Reporting arrangements are defined.

•Any requirement for independent attendance at, and participation in, quality activities is defined.

 

B

Standards alignment

 

B Standards alignment

Project management standards summarize the key concepts and activities that need to be undertaken in order to increase the likelihood of project success.

There is scope for confusion regarding the respective uses of standards and methods, and how they are applied in organizations. In simple terms:

•A standard, such as BS 6079, defines what needs to be done and by whom, but not how activities are done.

•A method, such as PRINCE2, provides not only a set of activities to be done, together with roles, but also techniques for undertaking these activities.

Standards can improve the effectiveness of project management by drawing attention to the key principles and activities required. After they have been established, standards can promote continual improvement by being periodically reviewed and updated. This ensures that the latest consensus on best practice is included and that any omissions or clarifications are dealt with. In this way, all users of standards benefit from the collective experience of all other users.

B.1 How PRINCE2 meets BS 6079

PRINCE2 and BS 6079 (British Standards Institution, 2010) share a core of common practice and both cover ‘project management’ in its widest sense, notably:

•The roles used map exactly, except that PRINCE2 calls BS 6079’s ‘project sponsor’ the ‘executive’ and is more prescriptive about the use and constituency of a project board.

•In terms of project lifecycle, PRINCE2 and BS 6079 follow the same concept of phases/stages, with a project having at least two phases/stages.

•BS 6079 describes ‘gates’, which are decision points to start the next phase/stage of the project and are independent of when a stage actually ends. By contrast, PRINCE2 describes ‘stage boundaries’.

•BS 6079 has an activity for managing a project as a whole (managing a project), whereas PRINCE2 manages at stage level (controlling a stage).

•Being a method, PRINCE2 has details of techniques and approaches that are not in BS 6079 (e.g. product-based planning).

Therefore, if an organization is using PRINCE2, it could be said to comply with BS 6079 Part 1 provided that those aspects which are explicitly beyond the scope of PRINCE2 are covered either by its enterprise method or by other corporate processes and methods.

B.2 How PRINCE2 meets ISO 21500

As PRINCE2 and ISO 21500 (International Organization for Standardization, 2012) have different structures and scopes, it is not always possible to make direct comparisons clause by clause.

•ISO 21500 does not cover, in its processes, the roles of what PRINCE2 refers to as the executive or the team manager. However, PRINCE2 and ISO 21500 do share a core of common practice relating to the role and activities of the project manager.

•ISO 21500 does not define the roles of team manager or team member in any detail because they, like the project sponsor, are outside the standard’s scope.

•In terms of project lifecycle, PRINCE2 and ISO 21500 have the same concept of phases/stages, with decision points where each phase/stage of the project starts. ISO 21500 provides no detail on best practice relating to such decisions, which are deemed out of scope.

•The actual structure of ISO 21500 in its logical form is very different from that of PRINCE2. In PRINCE2, the stages of a project are explicit and defined within the processes, such that the initiating and closing of a project is done in a different way from the initiating and closing of a phase/stage. ISO 21500 treats a project and a phase/stage within a project identically and has no explicit procedure for starting new stages within a project. How this is done is left to the user of the standard to determine. PRINCE2 provides detail on this in its managing a stage boundary and directing a project processes.

•Being a method, PRINCE2 has details of techniques and approaches which are not in ISO 21500 (e.g. product-based planning).

Therefore, if an organization is using PRINCE2, it could be said to comply with ISO 21500 provided that those aspects which are explicitly beyond the scope of PRINCE2 are covered either by its enterprise method or by other corporate processes and methods.

B.3 Comparative glossary

Table B.1 compares terms used in PRINCE2 with those in BS 6079 and ISO 21500.

 

C

Roles and responsibilities

 

C Roles and responsibilities

This appendix includes detailed descriptions of the PRINCE2 roles. In order to meet the needs of different projects, these roles may be tailored as described in Chapter 4 in general and in Chapter 7 in particular. It should be noted, however, that these roles do not necessarily equate to jobs to be allocated to people on a one-to-one basis. Some roles may be undertaken part-time, while many roles may be shared or combined according to the project’s needs, provided the minimum requirements set out in section 7.2 are met.

C.1 Project board

The project board is accountable to corporate, programme management or the customer for the success of the project, and has the authority to direct the project within the remit set by corporate, programme management or the customer as documented in the project mandate.

The project board is also responsible for the communications between the project management team and stakeholders external to that team (e.g. corporate, programme management or the customer).

According to the scale, complexity, importance and risk of the project, project board members may delegate some project assurance tasks to separate individuals. The project board may also delegate decisions regarding changes to a change authority.

C.1.1 General responsibilities

During start-up and initiation, the project board should:

•confirm project tolerances with corporate, programme management or the customer

•approve the project brief

•approve the stage plan for the initiation stage

•authorize project initiation

•decide whether to use a change authority and, if so, agree the level of authority to be delegated

•set the scale for severity ratings for issues

•set the scale for priority ratings for requests for change and off-specifications

•approve the supplier contract (if the relationship between the customer and supplier is a commercial one)

•approve the PID, and its components, including any tailoring

•authorize the start of the project.

During the project, the project board should:

•set tolerances for each management stage and approve stage plans

•authorize each management stage and approve the product descriptions for each management stage

•approve exception plans when management-stage-level tolerances are forecast to be exceeded

•communicate with stakeholders as defined in the communication management approach (including briefing corporate, programme management or the customer about project progress)

•provide overall guidance and direction to the project, ensuring it remains viable and within any specified constraints

•respond to requests for advice from the project manager

•ensure that risks are being tracked and managed as effectively as possible

•approve changes (unless delegated to a change authority)

•make decisions on escalated issues

•approve completed products.

At the end of the project, the project board should:

•provide assurance that all products have been delivered satisfactorily

•provide assurance that all acceptance criteria have been met

•confirm acceptance of the project product

•approve the end project report and ensure that any issues, lessons and risks are documented and passed on to the appropriate body

•authorize follow-on action recommendations to be distributed to corporate, programme management or the customer

•transfer responsibility for the updated benefits management approach to corporate, programme management or the customer

•authorize project closure and send project closure notification to corporate, programme management or the customer.

C.1.2 Competencies

To be successful, the project board should:

•have sufficient authority to make decisions, approve plans and authorize any necessary deviation from stage plans

•have sufficient authority to allocate resources to the project

•be capable of adequately representing the business, user and supplier interests

•ideally be able to stay with the project throughout its life.

Key competencies include:

•decision-making

•delegation

•leadership

•negotiation

•conflict resolution.

C.2 Executive

The executive is ultimately accountable for the project, supported by the senior user and senior supplier. The executive’s role is to ensure that the project is focused throughout its life on achieving its objectives and delivering a product that will achieve the forecast benefits. The executive has to ensure that the project gives value for money, ensuring a cost-conscious approach to the project, balancing the demands of the business, user and supplier.

Throughout the project, the executive is responsible for the business case.

The project board is not a democracy controlled by votes. The executive is the ultimate decision maker and is supported in the decision-making by the senior user and senior supplier.

C.2.1 Responsibilities

In addition to the project board’s collective responsibilities, the executive will:

•design and appoint the project management team (in particular the project manager)

•oversee the development of the project brief and the outline business case, ensuring that the project is aligned with corporate, programme management or customer strategies (and presenting the outline business case to corporate, programme management or the customer for approval where required)

•oversee the development of the detailed business case

•secure the funding for the project

•approve any additional supplier contracts (if the relationship between the user and supplier is a commercial one)

•hold the senior supplier to account for the quality and integrity of the specialist approach and specialist products created for the project

•hold the senior user to account for realizing the benefits defined in the business case, ensuring that benefits reviews take place to monitor the extent to which the business case benefits are achieved

•transfer responsibility for post-project benefits reviews to corporate, programme management or the customer

•monitor and control the progress of the project at a strategic level, in particular reviewing the business case regularly

•escalate issues and risks to corporate, programme management or the customer if project tolerance is forecast to be exceeded

•ensure that risks associated with the business case are identified, assessed and controlled

•make decisions on escalated issues, with particular focus on continued business justification

•organize and chair project board reviews

•ensure overall business assurance of the project so that it remains on target to deliver products that will achieve the expected business benefits, and so that the project will be completed within its agreed tolerances. Where appropriate, delegate some business assurance activities (see section C.7).

C.3 Senior user

The senior user is responsible for specifying the needs of those who will use the project product, for user liaison with the project management team, and for monitoring that the solution will meet those needs within the constraints of the business case in terms of quality, functionality and ease of use.

The role represents the interests of all those who will use the project product (including operations and maintenance services), those for whom the product will achieve an objective or those who will use the product to deliver benefits. The senior user role commits user resources and monitors products against requirements. This role may require more than one person to cover all the user interests. For the sake of effectiveness, the role should not be split between too many people.

The senior user specifies the benefits and is held to account by demonstrating to corporate, programme management or the customer that the forecast benefits which were the basis of project approval have in fact been realized. This is likely to involve a commitment beyond the end of the life of the project.

C.3.1 Responsibilities

In addition to the project board’s collective 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

•ensure that the expected benefits (derived from the project’s outcomes) are realized

•provide a statement of actual versus forecast benefits at the benefits reviews

•resolve user requirements and priority conflicts

•ensure that any user resources required for the project (e.g. to undertake user quality inspections and product approval) are made available

•make decisions on escalated issues, with particular focus on safeguarding the expected benefits

•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 (user assurance) and, where appropriate, delegate user assurance activities (see section C.7).

C.4 Senior supplier

The senior supplier represents the interests of those designing, developing, facilitating, procuring and implementing the project product. This role is accountable for the quality of the project product (and its components) delivered by the supplier(s) and is responsible for the technical integrity of the project. If necessary, more than one person may represent the suppliers.

Depending on the particular customer/supplier environment, the customer may also wish to appoint an independent person or group to carry out assurance on the supplier’s products (e.g. if the relationship between the customer and supplier is a commercial one).

C.4.1 Responsibilities

In addition to the project board’s collective responsibilities, the senior supplier will:

•assess and confirm the viability of the project approach

•ensure that proposals for designing and developing the products are realistic

•advise on the selection of design, development and acceptance methods

•ensure that the supplier resources required for the project are made available

•make decisions on escalated issues, with particular focus on safeguarding the integrity of the complete solution

•resolve supplier requirements and priority conflicts

•brief non-technical management on supplier aspects of the project

•ensure quality procedures are used correctly, so that products adhere to requirements

•undertake project assurance from the supplier perspective (supplier assurance) and, where appropriate, delegate supplier assurance activities (see section C.7).

C.5 Project manager

The project manager is accountable to the project board and ultimately the executive and has the authority to run the project on a day-to-day basis, within the constraints laid down by them.

The project manager’s prime responsibility is to ensure that the project produces the required products within the specified tolerances of time, cost, quality, scope, benefits and risk. The project manager is also responsible for the project producing a result capable of achieving the benefits defined in the business case.

C.5.1 Responsibilities

The project manager’s responsibilities include the following:

•Prepare the following baseline management products, in conjunction with any project assurance roles, and agree them with the project board:

•project brief, including the project product description

•benefits management approach

•PID, and its components

•stage/exception plans and their product descriptions

•work packages.

•Prepare the following reports:

•highlight reports

•issue reports

•end stage reports

•exception reports

•end project report.

•Maintain the following records:

•issue register

•risk register

•daily log

•lessons log.

•Tailor the PRINCE2 method to suit the project’s situation, documenting this, as appropriate, in the PID.

•Liaise with corporate, programme management or the customer to ensure that work is neither overlooked nor duplicated by related projects.

•Liaise with any external suppliers or account managers.

•Lead and motivate the project management team.

•Establish behavioural expectations of team members.

•Manage the information flows between the directing and delivering levels of the project.

•Manage the production of the required products, taking responsibility for overall progress and use of resources and initiating corrective action where necessary.

•Establish and manage the project’s procedures: risk management, issue management, change control and communication.

•Establish and manage the project controls: monitoring and reporting.

•Authorize work packages.

•Advise the project board of any deviations from the plan.

•Unless appointed to another person(s), perform the team manager role (see section C.6).

•Unless appointed to another person (or corporate, programme management or customer function), perform the project support role (see section C.9).

•Implement the change control approach.

•Ensure project personnel comply with the change control approach.

•Schedule audits to check that the physical products are consistent with the configuration item records and initiate any necessary corrective action.

C.5.2 Competencies

Different types of project will require different types of project management skills. To be successful, the project manager must be able to balance the different aspects of the project manager role for a particular project.

Key competencies include:

•planning

•time management

•people management

•problem-solving

•attention to detail

•communication

•negotiation

•conflict management.

C.6 Team manager

The team manager’s prime responsibility is to ensure production of those products defined by the project manager to an appropriate quality, in a set timescale and at a cost acceptable to the project board. The team manager is accountable to, and takes direction from, the project manager.

C.6.1 Responsibilities

The team manager’s responsibilities include the following:

•Prepare the team plan and agree it with the project manager.

•Provide the project manager with recommendations on how PRINCE2 may be tailored to suit the management of the work package.

•Produce checkpoint reports as agreed with the project manager.

•Plan, monitor and manage the team’s work.

•Take responsibility for the progress of the team’s work and use of team resources, and initiate corrective action, where necessary, within the constraints laid down by the project manager.

•Identify, and advise the project manager of, any issues and risks associated with a work package.

•Advise the project manager of any deviations from the plan, recommend corrective action and help to prepare any appropriate exception plans.

•Pass back to the project manager products that have been completed and approved in line with the agreed work package requirements.

•Liaise with any project assurance and project support roles.

•Ensure that quality activities relating to the team’s work are planned and performed correctly, and are within tolerance.

•Ensure that the appropriate entries are made in the quality register.

•Manage specific issues and risks as directed by the project manager.

•Assist the project manager in assessing issues and risks.

•Ensure that all assigned issues are properly reported to the person maintaining the issue register.

C.6.2 Competencies

Different types of project will require different types of skills from the team manager. Key competencies are similar to those of a project manager.

C.7 Project assurance

Project assurance covers the primary stakeholder interests (business, user and supplier). The role has to be independent of the project manager; therefore the project board cannot delegate any of its assurance activities to the project manager.

C.7.1 Responsibilities

The implementation of the assurance responsibilities needs to answer the question of what is to be assured. A list of possibilities applicable to the business, user and supplier stakeholder interests would include ensuring that:

•liaison is maintained between the business, user and supplier throughout the project

•risks are controlled

•the right people are involved in writing product descriptions

•the right people are planned to be involved in quality inspection at the correct points in the development of product(s)

•staff are properly trained in the quality methods

•the quality methods are being correctly followed

•tailoring of PRINCE2 is suited to the project’s situation

•quality control follow-up actions are dealt with correctly

•an acceptable solution is being developed

•the scope of the project is not changing unnoticed

•internal and external communications are working

•applicable standards are being used

•the needs of specialist interests (e.g. security) are being observed.

Business assurance responsibilities include:

•assisting the project manager to develop the business case and benefits management approach (if it is being prepared by the project manager)

•advising on the selection of project management team members

•advising on the risk management approach

•reviewing the business case for compliance with corporate, programme management or customer standards

•verifying the business case against external events and project progress

•checking that the business case is being adhered to throughout the project

•checking that the project remains aligned with the corporate, programme management or customer strategy

•reviewing project finance on behalf of the customer

•verifying that the solution continues to provide value for money

•periodically checking that the project remains viable

•assessing whether the aggregated risk exposure remains within project tolerance

•checking that any supplier and contractor payments are authorized

•reviewing issues and risks by assessing their impact on the business case

•constraining user and supplier excesses

•informing the project management team of any changes caused by a programme of which the project is part (this responsibility may be transferred if there is other programme representation on the project management team)

•monitoring management stage and project progress against the agreed tolerances.

User assurance responsibilities include:

•advising on stakeholder engagement

•advising on the communication management approach

•ensuring that the specification of the user’s needs is accurate, complete and unambiguous

•assessing whether the solution will meet the user’s needs and is progressing towards that target

•advising on the impact of potential changes from the user’s point of view

•monitoring risks to the user

•ensuring that the quality activities relating to products at all management stages have appropriate user representation

•ensuring that quality control procedures are used correctly to ensure that products meet user requirements

•ensuring that user liaison is functioning effectively.

Supplier assurance responsibilities include:

•reviewing the product descriptions

•advising on the quality management approach and change control approach

•advising on the selection of the development strategy, design and methods

•ensuring that any supplier and operating standards defined for the project are met and used to good effect

•advising on potential changes and their impact on the correctness, completeness and integrity of products against their product description from a supplier perspective

•monitoring any risks in the production aspects of the project

•assessing whether quality control procedures are used correctly, so that products adhere to requirements.

C.7.2 Competencies

To be successful, project assurance should:

•be capable of adequately representing the business, user or supplier stakeholder interests

•have sufficient credibility to ensure that advice and guidance are followed

•have sufficient specialist knowledge of the business, user or supplier stakeholder areas

•ideally be able to stay with the project throughout its lifecycle.

Key competencies include:

•diplomacy

•thoroughness

•attention to detail

•ability to communicate effectively.

C.8 Change authority

The project board may delegate authority for approving responses to requests for change or off-specifications to a separate individual or group, called a change authority. The project manager could be assigned as the change authority for some aspects of the project (e.g. changing baselined work packages if this does not affect management stage tolerances).

C.8.1 Responsibilities

Responsibilities of the change authority include:

•Review and approve or reject all requests for change and off-specifications within the delegated limits of authority and change budget set by the project board.

•Refer to the project board if any delegated limits of authority or allocated change budget are forecast to be exceeded.

C.8.2 Competencies

The change authority should:

•be capable of adequately representing the business, user and supplier stakeholder interests

•have sufficient credibility to ensure that advice and guidance are followed

•have sufficient specialist knowledge of the business, user or supplier stakeholder areas.

Key competencies include:

•decision-making

•planning

•attention to detail

•problem-solving.

C.9 Project support

The provision of any project support on a formal basis is optional. If it is not delegated to a separate person or function, it will need to be undertaken by the project manager.

One support function that must be considered is that of change control. Depending on the project size and environment, there may be a need to formalize this and it may become a task with which the project manager cannot cope without support.

Project support functions may be provided by a project office or by specific resources for the project. For further information on the use of a project office, see Portfolio, Programme and Project Offices (Cabinet Office, 2013).

C.9.1 Responsibilities

The following is a suggested list of tasks for project support:

•Set up and maintain project files.

•Establish document control procedures.

•Collect actuals data and forecasts.

•Update plans.

•Administer or assist the quality review process.

•Administer or assist project board meetings.

•Assist with the compilation of reports.

•Contribute expertise in specialist tools and techniques (e.g. planning and control tools, risk analysis), including tailoring recommendations suited to the project’s situation.

•Maintain the following records:

•quality register

•configuration item records, if used

•any other registers/logs delegated by the project manager.

•Administer the change control procedure as follows (these responsibilities may be undertaken by a configuration librarian from corporate, programme management or the customer):

•administer the receipt, identification, versions, storage and issue of all the project’s products

•provide information on the status of all products

•archive superseded product copies

•ensure the security and preservation of the master copies of all the project’s products

•maintain a record of all copies issued

•notify holders of any changes to their copies

•number, record, store and distribute issue reports

•conduct reviews or audits.

C.9.2 Competencies

Typical competencies for project support roles will depend on the type of project and organization. Key competencies include:

•administration and organization

•knowledge of specialist tools and techniques

•knowledge of corporate, programme management or customer standards applicable to the project.

 

D

Product-based planning example

 

D Product-based planning example

D.1 Scenario

A project is required to organize and run a conference for between 80 and 100 delegates. The date and subject matter are set, and the focus of the conference is to bring members of a particular profession up to date on recent developments in professional procedures and standards. The project team will need to identify a venue, and check its availability, facilities and price before booking it. They will also need to identify suitable speakers and book them, before producing a detailed agenda and programme. A mailing list of delegates is available, and after the venue has been booked, the project team will need to issue a press release based on the agreed programme. Part of the project will involve producing 100 delegate handouts, with a cover reflecting the selected subject matter. These handouts must contain a printed agenda covering the agreed programme, copies of slides and notes used by the speakers, and a feedback form to capture attendee reviews. Booking arrangements for attending the conference, including details of the programme and venue, must be sent out in the bulk email. The team will need to regularly update the attendance list based on responses to the email, and make arrangements to recruit staff to help on the day, based on the final attendance list.

D.2 Product examples

Table D.1 gives an example of a project product description for the conference. Examples of a product breakdown structure for this event are provided as a hierarchical chart (Figure D.1), a mind map (Figure D.2) and an indented list. Note that PRINCE2 does not specify the format in which the product breakdown structure is drawn.

Figure D.3 gives an example of a product description for the bulk email for the conference, whereas Figure D.4 shows a possible product flow diagram.

Note that only the project product, releases and products need to be transferred from the product breakdown structure in Figure D.1 to the product flow diagram in Figure D.4. For example, in this scenario the planner has used ‘publicity’ in the product breakdown structure but the only publicity products that need to be produced are the bulk email and press release. (Note that ‘product groups’ in Figure D.1 are not products that require work but a way of identifying products that have some common characteristics or focus. In this case, ‘publicity’ is a convenient way to describe the products that provide publicity for the conference.) The delegate handout, however, is a product that is created by bringing together the covers, printed agenda, print-outs of the conference slides and notes, and the satisfaction survey form products.

 

E

Health check

 

E Health check

The following are process-oriented checklists that can be used at various points in the project to assess whether the key aspects of PRINCE2 are adequately addressed. The checklists are not exhaustive but should provide reasonable confidence as to whether a project is being managed in accordance with PRINCE2.

It is important to note that any reference to a management product means ‘in accordance with the product description in Appendix A’ and in particular the quality criteria for those management products should also be reviewed.

The checklists may need to be adapted to reflect any tailoring of the PRINCE2 method.

E.1 Starting up a project

Question			Yes/No
1	Have project management team roles been allocated for the:
	a	executive?
	b	project manager?
	c	senior user(s)?
	d	senior supplier(s), if appropriate at this point?
	e	project support?
	f	team managers, if appropriate at this point?
	g	project assurance?
	h	change authority, if appropriate at this point?
2	Do the project board members have sufficient authority, availability and credibility to direct the project?
3	Are the project’s stakeholders sufficiently represented by the project board?
4	Do role descriptions exist for each key appointment?
5	Have those people appointed confirmed their acceptance?
6	Has a daily log been set up?
7	Has the lessons log been set up?
8	Have lessons from previous similar projects been identified and, where appropriate, applied?
9	If the organization has not undertaken a project like this before, have lessons been sought from comparable projects external to the organization?
10	Has the project brief been produced?
11	Is there an outline business case?
12	Has the project product description been produced?
13	Has the project approach been decided upon?
14	Is there a stage plan for the initiation stage?

E.2 Directing a project

E.2.1 Authorize initiation

Question			Yes/No
15	Has the project board approved the project brief? Specifically, has it:
	a	confirmed the project definition and approach?
	b	reviewed and approved the project product description?
	c	formally confirmed the appointments to the core project management team?
	d	reviewed and approved the outline business case, particularly the projected benefits?
16	Has the project board approved the initiation stage plan? Specifically, has it:
	a	approved the plan to develop the PID?
	b	obtained or committed the resources needed by the stage plan for the initiation stage?
	c	ensured that adequate reporting and control mechanisms are in place for the initiation stage?
	d	set tolerances for the initiation stage?
	e	requested the necessary logistical support (e.g. accommodation, communication facilities, equipment and any project support) from corporate, programme management or the customer?
	f	confirmed that it has understood any risks that affect the decision to authorize the initiation stage?
	g	confirmed to the project manager that the work defined in the initiation stage plan may start?
17	Has the project board informed corporate, programme management or the customer (and other interested parties) that project initiation has been authorized?

E.2.2 Authorize the project

Question			Yes/No
18	Has the project board approved the PID? Specifically, has it:
	a	confirmed that the business case is viable, desirable and achievable and meets corporate, programme management or customer expectations and standards, and approved it?
	b	confirmed that lessons from previous similar projects have been reviewed and incorporated?
	c	confirmed that the quality management approach will deliver the quality expectations, and approved it?
	d	confirmed that the change control approach will deliver the approach expected, and approved it?
	e	confirmed that the risk management approach will safeguard the project, and approved it?
	f	confirmed that there has been a risk assessment, and that risk response actions have been planned?
	g	confirmed the validity and achievability of the project plan and approved it?
	h	confirmed that the benefits management approach covers all expected benefits, and approved it?
	i	confirmed that all members of the project management team have agreed their roles (the project management team structure, roles and responsibilities)?
	j	ensured that the project controls are adequate for the nature of the project?
	k	ensured that the information needs and timing of communications, as defined in the communication management approach, are adequate for the nature of the project, and approved it?
	l	reviewed the tolerances for the project provided by corporate, programme management or the customer to ensure that they are appropriate and realistic?
	m	considered the consistency of the various components and approved the PID overall, including any tailoring?
19	Has the project board informed corporate, programme management or the customer (and other interested parties) that the project has been authorized?

E.2.3 Authorize a stage or exception plan

Question			Yes/No
20	Has the project board reviewed the end stage report? Specifically:
	a	did the board review the performance status of the project using the end stage report for the current management stage?
	b	has the board reviewed the benefits achieved and lessons captured during the management stage?
21	Has the project board assessed overall project viability? Specifically, has it:
	a	reviewed the project plan and the position in relation to project tolerances agreed with corporate, programme management or the customer?
	b	reviewed the business case to ensure that the project is still justified?
	c	reviewed the key risks to ensure that the exposure level is still acceptable and that response actions are planned?
	d	obtained decisions from outside the project for any potential deviations beyond project tolerances? (For example, if this project is part of a programme, then programme management should have examined the impact on the programme, and taken appropriate action.)
22	Has the project board reviewed and approved the next stage plan (or exception plan)? Specifically, has it:
	a	reviewed the plan for which the project manager is seeking approval? (This will be a stage plan for the next management stage or an exception plan.)
	b	authorized the project manager to proceed with the submitted plan (stage plan or exception plan) or instructed the project manager to prematurely close the project?
	c	set the tolerances for the next management stage or (in the case of an exception plan) revised the current stage tolerances as necessary?
23	Has the project board informed corporate, programme management or the customer (and other interested parties) that the next management stage has been authorized (or that an exception plan for the current management stage has been approved)?

E.2.4 Give ad hoc direction

Question			Yes/No
24	Has the project board responded to the project manager’s requests? Specifically, has it:
	a	reviewed the request? (This could be informal or formal, the latter in the form of an issue report.)
	b	made a decision (e.g. approved, rejected, deferred decision or requested more information)?
	c	provided guidance to the project manager?
25	Has the project board responded to reports? Specifically, has it:
	a	reviewed the latest highlight report in order to understand the status of the project and satisfied itself, through a dialogue with the project manager, that the management stage is progressing according to plan?
	b	made decisions on exception reports, adjusted tolerances or approved responses to the exception as appropriate?
	c	made decisions on issue reports within the board’s delegated limits of authority or sought advice from corporate, programme management or the customer?
26	Has the project board responded to external influences? Specifically, has it:
	a	ensured that the project is kept informed of external events that may affect it?
	b	ensured that the project remains focused on the corporate, programme management or customer objectives set, and remains justified in business terms?
	c	ensured that the project manager is notified of any changes in the corporate, programme management or customer environment that may impact on the project and that appropriate action is taken?
27	Has the project board informed corporate, programme management or the customer (and other interested parties) of the project’s progress in accordance with the communication management approach?

E.2.5 Authorize project closure

Question			Yes/No
28	Has the project board confirmed handover and acceptance? Specifically, has it:
	a	verified that the handover of the project product was in accordance with the change control approach and in particular that records of all required user acceptance and operational/maintenance acceptance exist?
	b	ensured that, where appropriate, the resulting changes in the business are supported and sustainable?
	c	ensured that any customer quality expectations that cannot be confirmed until after the project closes (e.g. performance levels regarding reliability) are included in the benefits management approach as a post-project check?
29	Has the project board approved the end project report? Specifically, has it:
	a	used the version of the PID which was approved at project initiation as the baseline to assess how the project has deviated from its initial basis, and to provide information against which the success of the project can be judged?
	b	ensured follow-on action recommendations have been recorded correctly in the end project report and that the appropriate groups have been made aware of their responsibility for taking them forward?
	c	approved the end project report for distribution to any interested parties, such as corporate, programme management or the customer?
30	Has the project board reviewed the lessons log and agreed how the lessons should be disseminated? Has the board ensured that the appropriate groups (e.g. corporate, programme management or the customer, centre of excellence) have been made aware of their responsibility for taking any recommendations forward?
31	Has the project board confirmed the business case? Specifically, has it confirmed the updated business case by comparing actual and forecast benefits, costs and risks against the approved business case within the PID? (It may not be possible to confirm all the benefits as some will not be realized until after the project is closed.)
32	Has the project board approved the updated benefits management approach? Specifically, has it:
	a	reviewed and gained approval for the updated benefits management approach, ensuring that it addresses the expected benefits that cannot yet be confirmed?
	b	confirmed that the responsibility for the benefits management approach has been transferred to corporate, programme management or the customer?
33	Has the project board issued the project closure notification? Specifically, has it:
	a	reviewed and issued a project closure notification in accordance with the communication management approach?
	b	advised those who have provided the support infrastructure and resources for the project that these can now be withdrawn?
	c	released the resources provided to the project?
	d	provided a closing date for costs being charged to the project?

E.3 Initiating a project

Question		Yes/No
34	Have lessons from previous similar projects been identified and, where appropriate, have they been applied?
35	Has the risk management approach been defined and documented?
36	Has the risk register been set up and populated?
37	Has the change control approach been defined and documented?
38	Have the initial configuration item records, if used, been set up?
39	Has the issue register been set up and populated?
40	Has the quality management approach been defined and documented?
41	Has the quality register been set up and populated?
42	Has the communication management approach been defined and documented?
43	Have the project controls been determined and established?
44	Has the project plan been created?
45	Has the project management team structure been updated to reflect any new roles being appointed or any changes to responsibilities of existing roles?
46	For new appointments, do role descriptions exist and have those people who have been appointed confirmed their acceptance?
47	Has the outline business case been refined into a detailed business case?
48	Has the benefits management approach been created (this may have been done by corporate, programme management or the customer)?
49	Has the PID been assembled, including tailoring?

E.4 Controlling a stage

Question		Yes/No
50	Have work packages been created and issued?
51	Have all the team managers agreed all their work packages?
52	Have completed products been produced in accordance with the work package and product description?
53	Have the relevant configuration item records, if used, been created/updated?
54	Has the quality register been maintained?
55	Were any products handed over as part of a phased delivery? If so, were they handed over in accordance with the change control approach?
56	Has the risk register been maintained?
57	Has the issue register been maintained?
58	Has the stage plan been updated with actuals and revised forecasts?
59	Has the daily log been maintained?
60	Have checkpoint reports been received for each issued work package at the frequency and in the format agreed?
61	Was progress (actual and forecast) checked against agreed tolerances?
62	If tolerances were forecast to be exceeded, were they escalated to the project board?
63	If corrective actions were required, were they logged, implemented and tracked?
64	Was the business case periodically checked for ongoing viability?
65	Were highlight reports created and issued in accordance with the agreed reporting format and frequency?
66	Do issue reports exist for all issues being handled formally?
67	Do exception reports exist for all exceptions raised to the project board?
68	Has the lessons log been updated with any new lessons?

E.5 Managing product delivery

Question		Yes/No
69	Did the work package and product description(s) contain sufficient information, including cross-references, to enable the team manager to produce the products required?
70	Has a team plan been created that demonstrates that the work package could be completed within agreed tolerances?
71	Has the team plan been updated with actuals and revised forecasts?
72	Was progress (actual and forecast) checked against agreed tolerances?
73	If tolerances were forecast to be exceeded, were they escalated to the project manager?
74	Were checkpoint reports issued to the project manager at the frequency and in the format agreed?
75	Did the team manager notify the project manager of any issues and risks?
76	Do approval records exist for each planned product?
77	Did the team manager notify project support of any required updates to configuration item records, if used, and the quality register?
78	Did the team manager notify the project manager that all the products in the work package had been delivered?

E.6 Managing a stage boundary

Question		Yes/No
79	Have all products that were planned to be completed within the management stage been approved?
80	Has a product status account been created to verify the status of the management stage’s products?
81	If there was a product handover during the management stage, were related outstanding issues documented as follow-on action recommendations ready for distribution subject to project board approval?
82	Has the lessons log been reviewed and updated?
83	Has the stage plan been updated with actuals?
84	Has the risk management approach been reviewed and (if necessary) updated?
85	Has the risk register been reviewed and updated?
86	Has the change control approach been reviewed and (if necessary) updated?
87	Have the configuration item records, if used, been reviewed and updated?
88	Has the issue register been reviewed and updated?
89	Has the quality management approach been reviewed and (if necessary) updated?
90	Has the quality register been reviewed and updated?
91	Has the communication management approach been reviewed and (if necessary) updated?
92	Have the project controls been reviewed and (if necessary) updated?
93	Has the project plan been reviewed and (if necessary) updated?
94	Has the project management team structure been updated to reflect any new roles being appointed or any changes to responsibilities of existing roles?
95	For new appointments, do role descriptions exist and have those people who have been appointed confirmed their acceptance?
96	Has the business case been reviewed and (if necessary) updated?
97	Has the benefits management approach been reviewed and (if necessary) updated?
98	Has the PID been reviewed and (if necessary) updated?
99	Has an end stage report been produced showing actual against planned performance, and summarizing lessons and follow-on action recommendations?
100	Has the end stage report been issued to the project board in accordance with the project controls?
For the next stage
101	Has a stage plan for the next management stage been created?
102	Have product descriptions been created for the next management stage’s products?
103	Has the project board been requested to authorize the next management stage?
For exceptions
104	Has an exception plan been created (if requested by the project board)?
105	Have product descriptions been created/updated for the exception plan?
106	Has the project board been requested to approve the exception plan?

E.7 Closing a project

Question		Yes/No
107	Have all products been completed and approved?
108	Has a product status account been created to verify the status of all the products?
109	Have all outstanding issues been documented as follow-on action recommendations ready for distribution subject to project board approval?
110	For premature closure, has the means for recovering products that have been completed or are in progress been approved by the project board? If requested, was an exception plan created and approved?
111	Is there an acceptance record for the handover of the project product?
112	Does the acceptance record include operational and maintenance acceptance?
113	Has the lessons log been reviewed and have relevant lessons been included in the end project report?
114	Has the project plan been updated with actuals?
115	Has the business case been updated with actuals?
116	Has the benefits management approach been updated with actuals?
117	Has an end project report been produced showing actual against planned performance and summarizing lessons and follow-on action recommendations?
118	Has the end project report been issued to the project board in accordance with the project controls?
119	Has a draft project closure notification been created for project board approval and onward distribution?
120	Have all registers and logs been closed?
121	Has all project documentation been archived?