Category Archives: MANAGEMENT ARTICLES

PRINCE2 RESEARCH – PART SEVEN (TAILORING PRINCE2)


19 Tailoring PRINCE2 to the project environment

19.2 General approach to tailoring

Some projects may claim that they do not need ‘full PRINCE2’ and therefore have only implemented portions of the method. This can reveal a flawed understanding of PRINCE2 because the method is designed to be tailored. So tailoring PRINCE2 appropriately is ‘full PRINCE2’.

Tailoring does not consist of omitting elements of PRINCE2. The method is not a series of isolated silos whereby any element can be omitted with no effect on the others. PRINCE2 is a web of interlinking elements: themes are used in processes; techniques are undertaken to bring themes to life; and individuals fulfilling project roles create management products. If the practitioner omits an element, project management for the project is weakened.

Therefore tailoring is about adapting the method to external factors (such as any corporate standards that need to be applied) and the project factors to consider (such as the scale of the project).

Tailoring, therefore, is about thinking how to apply the method and then using it with a lightness of touch. Figure 19.1 shows how the environmental and project factors are evaluated in order to tailor the method.

19.2.1 Applying the principles
As PRINCE2’s principles are universal, they will always apply and are not tailored. By looking at the principles, the practitioner can understand how to adapt the theme to the environmental and project factors without losing its value.

19.2.2 Adapting the themes
Adapting a theme does not necessarily mean modifying the method. In most cases, the environmental and project factors are incorporated into the project’s strategies and controls. Relevant corporate or programme policies and standards are captured and documented in the project’s Risk Management Strategy, Quality Management Strategy, Configuration Management Strategy and Communication Management Strategy. These management products will describe the procedures to be used on the project that fulfil the requirements of the corporate or programme organization. The level of control required will influence the formality and frequency of monitoring, reviewing and reporting.

19.2.3 Applying the organization’s terms and language
The method may need to be adapted to incorporate the terms and language of the corporate or programme organization. For example, if the corporate or programme organization uses the term ‘investment case’ rather than ‘Business Case’, it may be appropriate to substitute the term within all of the project’s documentation if that improves understanding.

19.2.4 Adapting the management products
PRINCE2 provides Product Description outlines for those management products that require particular purpose or composition for their use by the themes and processes. In tailoring PRINCE2, the management products may be adapted, in which case it may be necessary to modify their Product Descriptions or to provide a template for them. For everyone involved in the project, it should remain clear as to what the purpose of the management product is, what it should comprise and what the quality criteria are. For example, in a commercial environment, the Work Package may need to include purchase order details and accompanying terms and conditions.

19.2.6 Adapting the processes
All the PRINCE2 process activities need to be done; it is just that the responsibilities for performing the activities may change (if any roles have been adapted) and any references to the management products may need to change (if any management products have been adapted).

19.4 Projects in a programme environment
The distinction between projects and programmes is that projects typically produce or change something and are then disbanded. The benefits of the undertaking are likely to be accrued after the project is completed. Programmes are typically used to help transform organizations. Therefore, the temporary programme organization tends to have a lifespan that covers the realization of the benefits – which could be several years. This is illustrated in Figure 19.2.

Projects operating in a programme environment benefit from a number of advantages, and there are a number of ways in which PRINCE2 can be tailored for use within a programme.

The following sections explain how PRINCE2 can be tailored when working in a programme environment (using Cabinet Office’s Managing Successful Programmes framework) by looking at how to adapt the themes, processes and management products.

19.4.1 Themes
19.4.1.1 Business Case
The programme will define the standards that the project will need to use when developing the Business Case.

The project Business Case will be aggregated into the overall programme Business Case and is likely to be reduced in content. It may comprise just the details of the budget, a list of benefits (and the benefits tolerance), and a statement as to how the project is contributing to the programme blueprint, with the justification aspects of the project Business Case sitting in the programme Business Case.

In some cases, the Business Case might be produced and maintained by the programme and even exist in detail prior to initiating the project.

Benefits will be defined, tracked and managed by the programme management team, and the project’s Benefits Review Plan will be part of the programme’s benefits realization plan.

19.4.1.2 Organization
Cabinet Office’s Managing Successful Programmes framework defines a programme board that comprises a programme Senior Responsible Owner (SRO), a programme manager, one or more business change managers, representatives of corporate functions as necessary (e.g. human resources, finance), the lead supplier, and the project Executives of the projects within the programme.

The programme SRO is the single individual with overall responsibility for ensuring that a programme will meet its objectives and deliver the projected benefits. It is likely that the programme SRO will confirm the appointment of the project Executive.

The programme manager is responsible for the setup and day-to-day management and delivery of the programme on behalf of the programme SRO.

The business change manager is responsible for benefits definition and management throughout the programme. This role provides the bridge between the programme and business operations to ensure that the capabilities delivered by the projects are adopted by the organization in order to achieve the desired outcome and their subsequent benefits.

The programme and project management team structures need to be integrated such that:

There are clear lines of responsibility from top to bottom (i.e. everyone is accountable to someone)
Duplication is avoided
Reports and reviews are efficient (e.g. four projects within a programme have common Project Board members and by aligning stage boundaries they meet collectively to conduct end stage assessments for all four projects as part of a programme review).
The integration of roles may include:

The programme manager being the Executive for one or more of the projects
A business change manager from the programme fulfilling the project role of Senior User (or having input in the appointment of the Senior User) for one or more of the projects, or being the project Executive for one or more of the projects
Project Support being provided by the programme
The programme’s design authority (if used) fulfilling the project role of Change Authority or Project Assurance for one or more of the projects as the purpose of a design authority at a programme level is to ensure that there is appropriate alignment and control when changes are being planned and implemented.
The choice of structure and appointments will depend on the scale and complexity of the programme. The pros and cons of the choice of organization structure and appointments need to be evaluated along with their consequences. For example, in Figure 19.4, where the programme manager is also the Executive of one of the projects within the programme, consideration should be given as to how exceptions will be escalated between the project and the programme, and whether any additional assurance mechanisms need to be established.

See Figures 19.3 and 19.4 for two examples. The project’s Communication Management Strategy will be derived from the programme’s stakeholder engagement strategy, with communications being controlled and scheduled as part of the programme communications plan. Stakeholder analysis for the project may be performed by the programme, or the programme may require the project to take a lead with certain stakeholder groups with which it has good engagement.

19.4.1.3 Quality
The project’s Quality Management Strategy is derived from the programme’s Quality Management Strategy.

Quality assurance and quality control activities may be carried out by members of the programme management team.

The programme’s design authority may provide advice and guidance to the Project Manager on any quality methods to be used.

19.4.1.4 Plans
Any specific standards that the project planners should work to will be described in the programme monitoring and control strategy. The project planning activity to design the plan will ensure that such standards and tools are adopted by the project.

The programme may have dedicated planners that can help the Project Manager prepare and maintain the Project Plan and Stage Plans. The programme dependency network will detail how each project’s deliverables are being used by other projects within the programme. Any dependencies to or from the project should be incorporated into the project’s plans.

19.4.1.5 Risk
The project’s Risk Management Strategy will be derived from the programme’s Risk Management Strategy. This will include defining a common set of risk categories, risk scales (for probability, impact and proximity), any risk evaluation techniques (such as expected monetary value), the projectlevel risk tolerance, and the mechanisms to escalate risks to the programme level.

19.4.1.6 Change
The project’s Configuration Management Strategy will be derived from the programme’s information management strategy. The information management strategy defines how interfaces between projects should be maintained (e.g. so that any changes within this project that may affect one or more other projects are captured and escalated).

The project’s change control procedure will be derived from the programme’s issue resolution strategy. This will define how scope or delivery changes that take the project out of tolerance, or affect the programme benefits or programme plan, are escalated to the programme level.

The project’s Change Authority may include the programme’s design authority.

19.4.1.7 Progress
The programme’s monitoring and control strategy may influence the formality, frequency and content of the project’s reviews and reports, and any project management standards that are to be complied with.

Project-level time and cost tolerances will be defined by the programme.

The number and length of management stages will be influenced by the programme plan.

It may be desirable or necessary to align end stage assessments to programme milestones (for example, the end of a tranche). The programme may even define a set of standard management stages that all projects within the programme comply with.

19.4.2 Processes
Within Cabinet Office’s MSP framework, the Delivering the Capability process within Managing the Tranches is entirely focused on starting, monitoring and closing projects within the programme. This process does not need to be tailored when working with PRINCE2.

The PRINCE2 process most affected by working in a programme will be Starting up a Project. This process could be undertaken almost entirely by the programme. The programme will: appoint the Executive and Project Manager, review previous lessons, design and appoint the project management team, and probably prepare the Project Brief. The Project Manager will, however, be responsible for preparing the Initiation Stage Plan. In this context, it is not so much that the Starting up a Project process is not done, just that it is now done mainly by the programme.

19.4.3 Management products
Confusingly, there are numerous management products that exist for both the project and programme, for example a Quality Management Strategy. When in a programme environment, it may be desirable to prefix the management product with ‘project’ and ‘programme’ to distinguish the difference. Another consideration is to make the project and programme document templates look very different in style so that it is immediately obvious where they apply.

Consideration should be given to whether the project’s logs and registers will be maintained locally to the project, or centrally by the programme. For example, a choice needs to be made as to whether there is a single Risk Register, administered by the programme for the programme-level risks and all the risks for each project within the programme, or whether each project should maintain its own Risk Register. If the latter is chosen the project’s Risk Management Strategy should define how programme-level risks that are identified and captured by the project are promoted to the programme Risk Register.

Likewise, the programme’s Risk Management Strategy should define mechanisms for project risks that are identified and captured by the programme level to be demoted to the project Risk Register.

19.5 Project scale
PRINCE2 can be used regardless of the scale of the project. A project’s scale is relative to the size and experience of the organization hosting the project – e.g. a £10 million project could be a simple project to one organization or a daunting project to another. Scale is related not just to the size of the project (often measured in terms of time, money and people) but also to the context of the project’s complexity, risk and importance.

19.5.1 Simple project
As has been stated above, the scale of a project is relative to the organization and context. Nevertheless, there are some pointers that are useful to consider for a project that an organization considers is simple.

A question often asked is: which elements of PRINCE2 can be relaxed on simple projects? There is no easy answer to this. Even simple projects vary enormously in type and style.

First of all, it is important to remember that even simple projects should adhere to the seven PRINCE2 principles if the project is to be managed using PRINCE2. It is in the way the themes, processes and management products are used that PRINCE2 is ‘tailored’.

Overall, the purpose of PRINCE2 can be regarded as reducing the risk of project failure. Thus, whenever any element of PRINCE2 is relaxed, this should be regarded as taking a risk.

19.5.1.1 Themes
The theme most affected by simple projects is the Organization theme:

Scaling the project management team is primarily about role and function consolidation. Roles can be combined but should not be eliminated
As the Executive and Senior User roles are both from the customer environment, these can often be combined
As the Project Manager is likely to be much closer to the Project Board than on larger more complex projects, members of the Project Board are often in a better position to carry out their own Project Assurance rather than appointing another individual to fulfil this role
For small teams it may not be necessary to appoint Team Managers. The Project Manager of a small project can carry out those responsibilities
The Project Manager may undertake the role of Project Support and be a team member. In this case, the Project Manager must balance the effort of managing the project against the effort of doing any project work.
Of the other themes, the minimum requirements are:
Business Case Some form of business justification, no matter how this is documented
Plans Product Descriptions for the key deliverables and a simple plan, in the form of a schedule of who is involved in producing, reviewing and approving products, together with key milestones. This is often referred to as a product checklist (see the Product Description outline for a Plan in Appendix A for an example)
Quality An understanding of the levels of quality required in the project, and of the project products
Risk An analysis of the risks facing the project, actions that will be taken to implement risk responses, and communicating risk status via Checkpoint and Highlight Reports
Change A simple method of controlling changes to the project and managing the configuration of the products being delivered – for example, simple product identification and version control standards with secure arrangements for the storage of work products
Progress Some form of agreed controls and reporting requirements (whether written or oral).
19.5.1.2 Processes
All processes remain relevant even in simple projects. However, the Starting up a Project process can usually be handled in a less formal manner. The Executive and Project Manager should, however, avoid the temptation to bypass it altogether. In some cases it may be appropriate to combine the Starting up a Project and Initiating a Project processes (i.e. creating the Project Initiation Documentation straight from the mandate and skipping the production of a Project Brief).

19.5.1.3 Management products
The choice of format of the management product can help reduce the project management effort for a small project, for example:

The Project Board may decide to receive some, or all, reports orally or have a verbal exchange of information and decisions instead of formal meetings. In such cases, the Project Manager should, as a minimum, document the exchange in the Daily Log since people’s recollection of a verbal agreement can differ weeks, or even days, later
Reports could be in the form of an email
The Project Initiation Documentation could be a set of presentation slides.
Consideration should be given to creating documents that physically include more than one management product. It is possible to manage a small PRINCE2 project with just four sets of documentation:
The Project Initiation Documentation, which includes:
Project Brief
Business Case
Risk Management Strategy
Quality Management Strategy
Configuration Management Strategy
Communication Management Strategy
Project Plan, which includes:
Project Product Description
Product Descriptions
Benefits Review Plan
Highlight Reports, which include:
Product Status Account
The Daily Log, which includes:
Issues
Risks
Lessons
Planned and actual quality management activities
Configuration Item Records
End Project Report, which includes:
Lessons Report.
The following management products may not be needed:

Stage Plan If there is only one delivery stage, then the Stage Plan details can be included in the Project Plan
Checkpoint Reports If there are no Team Managers, there may be no need for Checkpoint Reports (although the Project Manager may request individual team members to provide them)
Work Packages May only be appropriate when the project has Team Managers. When there is only the Project Manager, then the Stage Plan may suffice. However, even in such cases, the Project Manager may choose to use Work Packages as a control for individual team members
End Stage Report If there is only one delivery stage, then the end of that stage is also the end of the project and only an End Project Report is required
Issue Report If the details of the issue are adequately captured in the Issue Register (or Daily Log), there may be no need for an Issue Report.

Advertisements

PRINCE2 RESEARCH – PART SIX (ROLES AND RESPONSIBILITIES)


C.1 Project Board

The Project Board is accountable to corporate or programme management for the success of the project, and has the authority to direct the project within the remit set by corporate or programme management 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 and programme management).

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.2 Executive
The Executive is ultimately responsible 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.3 Senior User
The Senior User(s) is responsible for specifying the needs of those who will use the project’s products, 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’s products (including operations and maintenance), those for whom the products will achieve an objective or those who will use the products 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(s) specifies the benefits and is held to account by demonstrating to corporate or programme management 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.4 Senior Supplier
The Senior Supplier represents the interests of those designing, developing, facilitating, procuring and implementing the project’s products. This role is accountable for the quality of products delivered by the supplier(s) and is responsible for the technical integrity of the project. If necessary, more than one person may be required to 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 (for example, if the relationship between the customer and supplier is a commercial one).

C.5 Project Manager
The Project Manager has the authority to run the project on a day-to-day basis on behalf of the Project Board 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, risk and benefits. The Project Manager is also responsible for the project producing a result capable of achieving the benefits defined in the Business Case.

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 role reports to, and takes direction from, the Project Manager.

C.7 Project Assurance
Project Assurance covers the primary stakeholder interests (business, user and supplier). Project Assurance has to be independent of the Project Manager; therefore the Project Board cannot delegate any of its assurance activities to the Project Manager.

C.8 Change Authority
The Project Board may delegate authority for approving responses to requests for change or offspecifications 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 it does not affect stage tolerances).

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 configuration management. 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. Refer to OGC’s guidance Portfolio, Programme and Project Support Offices (2008) for further information on the use of a project office.


PRINCE2 RESEARCH – PART FIVE (TECHNIQUES)


The PRINCE2 quality review technique

Objectives

To assess the conformity of a product which takes the form of a document (or similar item, e.g. a presentation or test results) against set criteria
To involve key interested parties in checking the product’s quality and in promoting wider acceptance of the product
To provide confirmation that the product is complete and ready for approval
To baseline the product for change control purposes.
Review team roles
Chair This role is responsible for the overall conduct of the review
Presenter This role introduces the product for review and represents the producer(s) of the product. The presenter also coordinates and tracks the work after the review, i.e. applying the changes to the product agreed by the team
Reviewer This role reviews the product, submits questions and confirms corrections and/or improvements
Administrator This role provides administrative support for the chair and records the result and actions.
The minimum form of review (used for simple inspections, e.g. of test results) involves only two people: one taking the chair and reviewer roles, the other taking the presenter and administrator roles.

Note: quality review is a generic technique which can be used outside the project context. Thus the quality review roles have no specific relationship to roles in the project management team structure. However, team-building benefits can be realized where Project and Team Managers regularly chair reviews. Chairing quality reviews requires competence in facilitation and independence of the product being reviewed (the primary responsibility is to ensure that the review is undertaken properly).

Review preparation
Make the administrative arrangements for the review (chair/administrator)
Check the product is ready for review and confirm the availability of the reviewers (chair)
Distribute copies of the product and the relevant Product Description to the review team, allowing sufficient time for reviewers to prepare (presenter)
Review the product in line with the quality criteria in the associated Product Description (reviewers)
Submit a question list to the chair and presenter ahead of the review (reviewers)
Annotate the product copy where there are spelling/grammar mistakes and return to the presenter (reviewers)
Produce a consolidated question list (chair) and send to the presenter in advance of the meeting.
Review meeting agenda
Personal introductions, if necessary (chair)
Product introduction (presenter) A very brief summary, covering the product ‘s purpose: who needs it, why they need it and what it will do
Major/global questions (chair) Invite each reviewer to contribute any major or global questions with the product. Global questions are ones that appear repeatedly throughout the product. The review team agrees any action on each question as it is raised. The administrator records the actions and responsibilities
Product ‘talk-through’ (presenter) Lead the review team through the product section by section or page by page, as appropriate, by reviewing the consolidated question list and inviting clarification where required. The review team agrees actions on each question as it is raised. The administrator records the actions and responsibilities
Read back actions (administrator) Confirm the actions and responsibilities
Determine the review result (chair) Lead the review team to a collective decision. The options are:
Complete (the product is fit for purpose, as is)
Conditionally complete (the product is fit for purpose subject to the actions)
Incomplete (the product requires another quality review cycle)
Close the review (chair)
Inform interested parties of the result (chair).
Review follow-up
Coordinate the actions (presenter)
Sign off individual actions (reviewers, as agreed at the meeting)
Once all actions are complete, sign off that the product is now complete (chair)
Communicate the quality review outcome to appropriate managers/support personnel (administrator)
Store the quality records (administrator)
Request approval for the product (presenter).
Hints and tips
Reviewers Review the product not the person. This means avoid personalizing issues (‘You …’) and operate as a team (‘We …’)
Reviewers Operate as a team but defer to specialist areas of expertise. Some reviewers may be selected to address specific aspects of the product and their comments may be considered to carry more weight in those areas
Reviewers Do not introduce trivia at reviews (spelling, punctuation etc.) unless it is a major/global issue (e.g. if the document will be communicated to an important audience, such as the public)
Chair Encourage the presenter to maintain a steady pace during the product talkthrough. The reviewers must have the opportunity to introduce their issues but allowing too much time invites comments that would not otherwise be made. The presenter should not be opening discussions unnecessarily
Chair Resolve each point as it is raised by getting a decision from the review team. Does the product have to be changed or not? Do not allow discussions to drift. Remember, the purpose of the review is to identify defects, not to design solutions to them. Avoid the temptation to formulate and agree solutions. These should be done post-review
Chair Focus on this product. Do not allow discussion to drift onto other related products. If it appears that there may be a problem associated with a related product, handle it outside the meeting as an issue
Chair Make sure the reviewers contribute effectively. It is your responsibility to ensure that the approved product is fit for purpose
Chair If a reviewer cannot attend the review, accept the question list from them and either raise the questions on their behalf, accept a delegate or replace the reviewer
Presenter It may be that a follow-up action is not feasible to implement or cannot be done within agreed tolerances, in which case an issue should be raised to the Project Manager
Approver If the person (or group) who will approve the product participates in the quality review, it may be possible to approve the product as part of the review.

Product-based Planning
The philosophy behind producing plans in PRINCE2 is that the products required are identified first, and only then are the activities, dependencies and resources required to deliver those products identified. This is known as product-based planning and is used for the Project Plan, the Stage Plan and, optionally, the Team Plan.


PRINCE2 RESEARCH – PART FOUR (MANAGEMENT PRODUCTS)


A.1 Benefits Review Plan

A.1.1 Purpose

A Benefits Review Plan is used to define how and when a measurement of the achievement of the project’s benefits, expected by the Senior User, can be made. The plan is presented to the Executive during the Initiating a Project process, updated at each stage boundary, and used during the Closing a Project process to define any post-project benefits reviews that are required.

The plan has to cover the activities to find out whether the expected benefits of the products have been realized and how the products have performed when in operational use. Each expected benefit has to be assessed for the level of its achievement and whether any additional time is needed to assess the residual benefits. Use of the project’s products may have brought unexpected side-effects, either beneficial or adverse. Time and effort have to be allowed to identify and analyse why these side-effects were not foreseen.

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

A.1.2 Composition
The scope of the Benefits Review Plan covering what benefits are to be measured
Who is accountable for the expected benefits
How to measure the achievement of the expected benefits, and when they can be measured
What resources are needed to carry out the review work
Baseline measures form which the improvements will be calculated
How the performance of the project’s products will be reviewed.

A.2 Business Case
A.2.1 Purpose
A Business Case is used to document the justification for the undertaking of 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.

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 re-affirmation 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
Executive summaryHighlights the key points in the Business Case, which should include important benefits and the return on investment (ROI)
Reasons Defines the reasons for undertaking the project and explains how the project will enable the achievement of corporate strategies and objectives
Business options Analysis and reasoned recommendation for the base business options of: do nothing, do the minimal or do something
Expected benefits The benefits that the project will deliver 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 to corporate or programme benefits. Tolerances should be set for each benefit and for the aggregated benefit. Any benefits realization requirements should be stated
Expected dis-benefits Outcomes perceived as negative by one or more stakeholders. Dis-benefits are actual consequences of an activity whereas, by definition, a risk has some uncertainty about whether it will 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 disbenefits (e.g. drop in productivity during the merger). Dis-benefits need to be valued and incorporated into the investment appraisal
Timescale 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 Review Plan)
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 to 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, ROI, 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.3 Checkpoint Report
A.3.1 Purpose
A Checkpoint Report is used to report, at a frequency defined in the Work Package, the status of the Work Package.

A.3.2 Composition
Date The date of the checkpoint
Period The reporting period covered by the Checkpoint Report
Follow-ups From previous reports, for example action items completed or issues outstanding
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 Update on issues and risks associated with the Work Package.

A.4 Communication Management Strategy
A.4.1 Purpose
A Communication Management Strategy contains a description of the means and frequency of communication to parties both internal and external to the project. It facilitates engagement with stakeholders through the establishment of a controlled and bi-directional flow of information.

A.4.2 Composition
Introduction States the purpose, objectives and scope, and identifies who is responsible for the strategy
Communication procedure A description of (or reference to) any communication methods to be used. Any variance from corporate or programme management 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 Definition of what communication records will be required and where they will be stored (for example, logging of external correspondence)
Reporting Describes any reports on the communication process that are to be produced, including their purpose, timing and recipients (for example, performance indicators)
Timing of communication activities States when formal communication activities are to be undertaken (for example, at the end of a 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 or programme management roles involved with communication
Stakeholder analysis:
Identification of the interested party (which may include accounts staff, user forum, internal audit, corporate or programme quality assurance, competitors etc.)
Current relationship
Desired relationship
Interfaces
Key messages
Information needs for each interested party:
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 Configuration Item Record
A.5.1 Purpose
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. The set of Configuration Item Records for a project is often referred to as a configuration library.

A.5.2 Composition
The composition of a Configuration Item Record will be defined in the project’s Configuration Management Strategy.

There follows a suggested list of components for each Configuration Item Record (note that the first three uniquely identify the configuration item):

Project identifier A unique reference. It will typically be a numeric or alpha-numeric value
Item identifier A unique reference. It will typically be a numeric or alpha-numeric value
Current version Typically an alpha-numeric value
Item title The description of the item (for a product this should be as it appears in the product breakdown structure)
Date of last status change
Owner The person or group who will take ownership of the product when it is handed over
Location Where the item is stored
Copy holders (if relevant) Who currently has the product?
Item type Component, product, release (see section 9.2.2)
Item attributes As defined by the Configuration Management Strategy. These are used to specify a subset of products when producing a Product Status Account, such as the management stage in which the product is created, the type of product (e.g. hardware/ software), product destination etc.
Stage When the product will be developed
Users The person or group who will use the item
Status As defined by the Configuration Management Strategy, e.g. pending development, in development, in review, approved or handed over
Product state (if used) As defined by the Product Description, e.g. dismantled machinery, moved machinery, reassembled machinery (see section 7.3.3.2)
Variant (if used) for example, language variants
Producer The person or team responsible for creating or obtaining the item
Date allocated To the producer
Source For example, in house, or purchased from a third-party company
Relationship with other items Those items that:
Would be affected if this item changed
If changed, would affect this item
Cross-references:
Issues and risks
Documentation that defines requirements, design, build, production and verification for the item (specifically this will include the Product Description).

A.6 Configuration Management Strategy
A.6.1 Purpose
A Configuration Management Strategy is used to identify how, and by whom, the project’s products will be controlled and protected. It answers the questions:

How and where the project’s products will be stored
What storage and retrieval security will be put in place
How the products and the various versions and variants of these will be identified
How changes to products will be controlled
Where responsibility for configuration management will lie.
A.6.2 Composition
Introduction States the purpose, objectives and scope, and identifies who is responsible for the strategy
Configuration management procedure A description of (or reference to) the configuration management procedure to be used. Any variance from corporate or programme management standards should be highlighted, together with a justification for the variance. The procedure should cover activities such as planning, identification, control (including storage/retrieval, product security, handover procedures etc.), status accounting, and verification and audit.
Issue and change control procedure A description (or reference to) the issue and change control procedures to be used. Any variance from corporate or programme management standards should be highlighted, together with a justification for the variance. The procedure should cover activities such as capturing, examining, proposing, deciding and implementing.
Tools and techniques Refers to any configuration management systems or tools to be used and any preference for techniques that may be used for each step in the configuration management procedure
Records Definition of the composition and format of the Issue Register and Configuration Item Records
Reporting Describes the composition and format of the reports that are to be produced (Issue Report, Product Status Account), their purpose, timing and chosen recipients. This should include reviewing the performance of the procedures
Timing of configuration management and issue and change control activities States when formal activities are to be undertaken, for example configuration audits
Roles and responsibilities Describes who will be responsible for what aspects of the procedures, including any corporate or programme management roles involved with the configuration management of the project’s products. Describes whether a Change Authority and/or change budget will be established.
Scales for priority and severity For prioritizing requests for change and off-specifications and for determining the level of management that can make decisions on severity of issue.

A.7 Daily Log
A.7.1 Purpose
A Daily Log is used to record informal issues, required actions or significant events not caught by other PRINCE2 registers or logs. It acts 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.

A.7.2
A Daily Log is in free form but likely to include:

Date of entry
Problem, action, event or comment
Person accountable
Target date
Results.

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 Project Initiation Documentation used to authorize it. It also allows the:

Passing on of any lessons that can be usefully applied to other projects
Passing on of details of unfinished work, ongoing risks or potential product modifications to the group charged with future support of the project’s products in their operational life.
A.8.2 Composition
Project Manager’s report Summarizing the project’s performance
Review of the Business Case Summarizing the validity of the project’s Business Case:
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. Review the effectiveness of the project’s strategies and controls
Review of team performance In particular, providing recognition for good performance
Review of products:
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’s 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 Report (see section A.15) A review of what went well, what went badly, and any recommendations for corporate or programme management consideration (and if the project was prematurely closed, then the reasons should be explained).

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
Project Manager’s report Summarizing the stage performance
Review of the Business Case Summarizing the validity of the project’s Business Case:
Benefits achieved to date
Residual benefits expected (remaining 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. Review the effectiveness of the project’s strategies and controls
Review of stage objectives Review of how the specific stage performed against its planned targets and tolerances for time, cost, quality, scope, benefits and risk
Review of team performance In particular, providing recognition for good performance
Review of products:
Quality records Listing the quality activities planned and completed in the stage
Approval records Listing the products planned for completion in the 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 Report (if appropriate) (see section A.15) A review of what went well, what went badly, and any recommendations for corporate or programme management consideration
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 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 of the above content may be appropriate or necessary.

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
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 or programme management
Options What are the options that are available to address the deviation and what would the effect of each option be on the Business Case, risks and tolerances
Recommendation Of the available options, what is the recommendation, and why?
Lessons What can be learned from the exception, on this project or future projects.

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 stage status at intervals defined by them. The Project Board uses the report to monitor 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
Date The date of the report
Period The reporting period covered by the Highlight Report
Status summary An overview of the status of the stage at this time
This reporting period:
Work Packages – 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 – 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 stage tolerance status How execution of the project and 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 Report (if appropriate) (see section A.15) A review of what went well, what went badly, and any recommendations for corporate or programme management consideration.

A.12 Issue Register
A.12.1 Purpose
The purpose of the Issue Register is to capture and maintain information on all of 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
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 alpha-numeric 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 A statement describing 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.13 Issue Report
A.13.1 Purpose
An Issue Report is a report containing the description, impact assessment and recommendations for a request for change, offspecification or a problem/concern. It is only created 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 examined 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
Issue identifier As shown in the Issue Register (provides a unique reference for every Issue Report)
Issue type Defines the type of issue being
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 A statement describing 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.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 strategies and plans. Some lessons may originate from within the project – where new experience (both good and bad) can be passed on to others via a Lessons Report.

A.14.2 Composition
For each entry in the Lessons Log, the following should be recorded:

Lesson type Defines the type of lesson being
Project – to be applied to this project
Corporate or programme – to be passed on to the corporate or programme management
Both project and corporate or programme management
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.15 Lessons Report
A.15.1 Purpose
The Lessons Report is 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 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 wait to the end. Typically it should 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.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 stage and are used as a baseline against which to monitor 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, configuration management, communication and any other project controls required.

A.16.2 Composition
Plan description Covering a brief description of what the plan encompasses (i.e. project, stage, team, exception) and the planning approach
Plan prerequisites Containing any fundamental aspects that must be in place, and remain in place, for the plan to succeed
External dependencies That may influence the plan
Planning assumptions Upon which the plan is based
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 Covering time and cost, including provisions for risks and changes
Tolerances Time, cost and scope tolerances for the level of plan (which may also include more specific stage- or team-level risk tolerances)
Product Descriptions (see section A.17) Covering the products within the scope of the plan (for the Project Plan this will include the project’s product; for the Stage Plan this will be the 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 Which may include graphical
Gantt or bar chart
Product breakdown structure (see Appendix D for an example)
Product flow diagram (see Appendix D for an example)
Activity network
Table of resource requirements – by resource type (e.g. four engineers, one test manager, one business analyst)
Table of requested/assigned specific resources – by name (e.g. Nikki, Jay, Francesca).

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
Identifier Unique key, probably allocated by the configuration management 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
A design is derived from a specification
A product is bought in from a supplier
A statement of the expected benefits are 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 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
– for example, 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 stage in which the quality inspection is to be done
Quality responsibilities Defining the producer, reviewer(s) and approver(s) for the product.

A.18 Product Status Account
A.18.1 Purpose
The Product Status Account provides information about the state of products within defined limits. The limits can vary. For example, the report could cover the entire project, a particular 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.

A.18.2 Composition
Report scope Describing the scope of the report (e.g. for the entire project, by stage, by product type, by supplier etc. The product’s attribute can be used to select the subset of products for the report)
Date produced The date the report was generated
Product status For each product within the
Product identifier and title
Version
Status and date of status change
Product state
Owner
Copy-holders
Location
User(s)
Producer and date allocated to producer
Planned and actual date Product Description was baselined
Planned and actual date product was baselined
Planned date for the next baseline
List of related items
List of related issues (including changes pending and approved) and risks.

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 Project Initiation Documentation, after which the Project Brief is no longer maintained.

A.19.2 Composition
Project definition Explaining what the project
Background
Project objectives (covering time, cost, quality, scope, risk and benefit performance goals)
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) Including the customer’s quality expectations, user acceptance criteria, and operations and maintenance acceptance criteria
Project approach To define the choice of solution that will be used within the project to deliver the business option selected from the Business Case, taking into consideration the operational environment into which the solution must fit
Project management team structure A chart showing who will be involved with the project
Role descriptions For the project management team and any other key resources identified at this time
References To any associated documents or products.

A.20 Project Initiation Documentation
A.20.1 Purpose
The purpose of the Project Initiation Documentation is to define the project, in order to form the basis for its management and an assessment of its overall success. The Project Initiation Documentation 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 Project Initiation Documentation 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 Project Initiation Documentation 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 stage, to reflect the current status of its constituent parts. The version of the Project Initiation Documentation 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 Project Initiation Document. Note that the first two (project definition and project approach) are extracted from the Project Brief.

Project definition Explaining what the project
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 To define the choice of solution 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) Describing 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 For the project management team and any other key resources
Quality Management Strategy (see section A.22) Describing the quality techniques and standards to be applied, and the responsibilities for achieving the required quality levels
Configuration Management Strategy (see section A.6) Describing how and by whom the project’s products will be controlled and protected
Risk Management Strategy (see section A.24) Describing the specific risk management techniques and standards to be applied, and the responsibilities for achieving an effective risk management procedure
Communication Management Strategy (see section A.4) To define the parties interested in the project and the means and frequency of communication between them and the project
Project Plan (see section A.16) Describing 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 stage by stage
Project controls Summarizing the projectlevel controls such as stage boundaries, agreed tolerances, monitoring and reporting
Tailoring of PRINCE2 A summary of how PRINCE2 will be tailored for the project.

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 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
Title Name by which the project is known
Purpose This defines the purpose that the project’s 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 to be delivered by the project
Derivation What are the source products from
Existing products to be modified
Design specifications
A feasibility report
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’s product 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’s product must meet before the customer will accept it
– i.e. 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 or performance
Project-level quality tolerances Specifying any tolerances that may apply for the acceptance criteria
Acceptance method Stating the means by which acceptance will be confirmed. This may simply be a case of confirming that all the project’s products have been approved or may involve describing complex handover arrangements for the project’s product, including any phased handover of the project’s products
Acceptance responsibilities Defining who will be responsible for confirming acceptance.

A.22 Quality Management Strategy
A.22.1 Purpose
A Quality Management Strategy is used to define the quality techniques and standards to be applied, and the various responsibilities for achieving the required quality levels, during the project.

A.22.2 Composition
Introduction States the purpose, objectives and scope, and identifies who is responsible for the strategy
Quality management procedure A description of (or reference to) the quality management procedure to be used. Any variance from corporate or programme management quality standards should be highlighted, together with a justification for the variance. The procedure
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
Quality assurance: the project’s approach to quality assurance activities. This may include:
Responsibilities of the Project Board
Compliance audits
Corporate or programme management 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 that are to produced, their purpose, timing and recipients
Timing of quality management activities States when formal quality management activities are to be undertaken, for example audits (this may be a reference to the Quality Register)
Roles and responsibilities Defines the roles and responsibilities for quality management activities, including those with quality responsibilities from corporate or programme management.

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
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 alpha-numeric 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 re-assessment 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 References to 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.24 Risk Management Strategy
A.24.1 Purpose
A Risk Management Strategy describes the specific risk management techniques and standards to be applied and the responsibilities for achieving an effective risk management procedure.

A.24.2 Composition
Introduction States the purpose, objectives and scope, and identifies who is responsible for the strategy
Risk management procedure A description of (or reference to) the risk management procedure to be used. Any variance from corporate or programme management standards should be highlighted, together with a justification for the variance. The procedure
Identify
Assess
Plan
Implement
Communicate
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 Definition of 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
– for example, at end stage assessments
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 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 stage, within the project, beyond the project
Risk categories Definition of 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 Definition of the risk response categories to be used, which themselves depend on whether a risk is a perceived threat or an opportunity
Early-warning indicators Definition of 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 Defining 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 or programme management.) The risk tolerance should define the risk expectations of corporate or programme management and the Project Board
Risk budget Describing whether a risk budget is to be established and, if so, how it will be used.

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 of the identified threats and opportunities relating to the project.

A.25.2 Composition
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 alpha-numeric 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 etc.)
Risk description In terms of the cause, event (threat or opportunity) and effect (description in words of the impact)
Probability, impact and expected value It is helpful to estimate the inherent values (preresponse action) and residual values (postresponse 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 stage, within project, beyond 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
For threats: avoid, reduce, fallback, transfer, accept, share
For opportunities: enhance, exploit, reject, share
Risk response Actions to resolve the risk, and these actions should be aligned to 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
Risk owner The person responsible for managing the risk (there can 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.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 (for example, if the project is part of a programme)
Configuration management 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 configuration management; any storage or security requirements; and 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 (for example, 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
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.


PRINCE2 RESEARCH – PART THREE (PROCESSES) Part Nine


Managing Product Delivery Process

16.1 Purpose

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

The role of the Team Manager(s) is to coordinate an area of work that will deliver one or more of the project’s products. They can be internal or external to the customer’s organization.

16.2 Objective
The objective of the Managing Product Delivery process is to ensure that:

Work on products allocated to the team is authorized and agreed
Team Managers, team members and suppliers are clear as to what is to be produced and what is the expected effort, cost or timescales
The planned products are delivered to expectations and within tolerance
Accurate progress information is provided to the Project Manager at an agreed frequency to ensure that expectations are managed.
16.3 Context
Managing Product Delivery views the project from the Team Manager’s perspective, while the Controlling a Stage process views it from the Project Manager’s perspective.

The Team Manager ensures that products are created and delivered by the team to the project by:

Accepting and checking authorized Work Packages from the Project Manager
Ensuring that interfaces identified in the Work Package are maintained
Creating a Team Plan for the Work Packages being assigned (where this may be done in
parallel with the Project Manager creating the Stage Plan for the management stage)
Ensuring that the products are developed in accordance with any development method(s) specified in the Work Package
Demonstrating that each product meets its quality criteria through the quality method(s) specified in the Product Description – this may include using the PRINCE2 quality review technique (see Chapter 6)
Obtaining approval for completed products from the authorities identified in the Product Description

Delivering the products to the Project Manager in accordance with any procedures specified in the Work Package.
If the project uses external suppliers that are not using PRINCE2, Managing Product Delivery provides a statement of the required interface between the Team Manager and the PRINCE2 method being used in the project by the Project Manager. The Work Package may be part of a contractual agreement. Therefore, the formality of a Team Plan could vary from simply appending a schedule to the Work Package, to creating a fully formed plan that is presented in a similar style to a Stage Plan.

16.4 Activities
The activities within the Managing Product Delivery process are Team-Manager-oriented and are to:

Accept a Work Package
Execute a Work Package
Deliver a Work Package.
Input Triggers
Authority to deliver a Work Package (from Controlling a Stage process)
Output Triggers
Completed Work Package (sent to Controlling a Stage process)

Accept Work Package
The fundamental principle is that before a Work Package is allocated to a team, there should be agreement between the Project Manager and the Team Manager as to what is to be delivered, the reporting requirements, what constraints apply, any procedures to be applied, and whether the requirements of the Work Package are reasonable and can be achieved.

Execute Work Package
The work has to be executed and monitored to the requirements defined in the authorized Work Package.

While developing the products, the Team Manager should not exceed the Work Package tolerances agreed with the Project Manager. The Team Manager can only proceed with the Work Package or take corrective action while the Work Package is forecast to complete within the tolerances set by the Project Manager. As soon as Work Package tolerances are forecast to be exceeded, the Team Manager should raise an issue to the Project Manager who will decide upon a course of action.

Deliver Work Package
Just as the Work Package was accepted from the Project Manager, notification of its completion must be returned to the Project Manager.

Closing a Project Process
18.1 Purpose
The purpose of the Closing a Project process is to provide a fixed point at which acceptance for the project product is confirmed, and to recognize that objectives set out in the original Project Initiation Documentation have been achieved (or approved changes to the objectives have been achieved), or that the project has nothing more to contribute.

18.2 Objective
The objective of the Closing a Project process is to:

Verify user acceptance of the project’s products
Ensure that the host site is able to support the products when the project is disbanded
Review the performance of the project against its baselines
Assess any benefits that have already been realized, update the forecast of the remaining benefits, and plan for a review of those unrealized benefits
Ensure that provision has been made to address all open issues and risks, with follow-on action recommendations.
18.3 Context
One of the defining features of a PRINCE2 project is that it is finite – it has a start and an end. If the project loses this distinctiveness, it loses some of its advantages over purely operational management approaches.

A clear end to a project:

Is always more successful than a slow drift into use as it is a recognition by all concerned that:
The original objectives have been met (subject to any approved changes)
The current project has run its course
Either the operational regime must now take over the products from this project, or the products become inputs into some subsequent project or into some larger programme
The project management team can be disbanded
Project costs should no longer be incurred

Provides an opportunity to ensure that all unachieved goals and objectives are identified so that they can be addressed in the future
Transfers ownership of the products to the customer and terminates the responsibility of the project management team.
Closure activities should be planned as part of the Stage Plan for the final management stage. When closing a project, work is required to prepare input to the Project Board in order to obtain its authorization to close the project. Subsequently, the Executive should also notify corporate or programme management that the project has closed (see Chapter 13).

It is also possible that the Project Board may wish to trigger a premature closure of the project under some circumstances (for example, if the Business Case is no longer valid). If the project is being brought to a premature close, this process will still need to be executed, but may have to be tailored to the actual project situation.

A number of actions specific to the project’s products may be required after the project, and these should be documented and planned for as follow-on action recommendations. These may have different audiences and therefore may need to be issued individually. The needs of the recipient will determine the format and content – some may want a formal report, some a log entry on a system, and others a meeting.

18.4 Activities
The activities within the Closing a Project process are Project-Manager-oriented and are to:

Prepare planned closure
Prepare premature closure
Hand over products
Evaluate the project
Recommend project closure.
Input Triggers
Premature Closure (from Directing a Project process)
Project end approaching (from Controlling s Stage process)
Output Triggers
Closure recommendation (sent to Directing a Project process)

Prepare Planned Closure
Project end approaching (from Controlling s Stage process)

Prepare Planned Closure
Before closure of the project can be recommended, the Project Manager must ensure that the expected results have all been achieved and delivered.

Prepare Planned Closure
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – update the Project Plan [p.250]
Reviewer – review the Product Status Account [p.253]
Project Assurance Role Actions:

Reviewer – review the Project Plan [p.250]
Reviewer – review the Product Status Account [p.253]
Project Board Role Actions:

Producer – create the Product Status Account [p.253]

Prepare Planned Closure
Project Plan [A.16 – p.250]

Update by the Project Manager
Reviewed by Project Assurance
Product Status Account [A.18 – p.253]

Created by Project Support
Reviewed by the Project Manager
Reviewed by Project Assurance

Hand Over Products
The project’s products must be passed to an operational and maintenance environment prior to the project being closed. This may happen as a single release at the end of the project, or the project approach may include phased delivery where products are handed over in a number of releases.

In the case of a premature closure, there may be some products that have been approved but not yet handed over and, depending on the Project Board guidance, the ownership of some or all of those products may need to be transferred to the customer.

When handing over products, the Benefits Review Plan may need to be updated to include the post-project benefits review(s) of the performance of the project’s products in operational use. Such benefits reviews may identify whether there have been any side-effects (beneficial or adverse) that could provide useful lessons for other projects.

It is not a project activity to undertake benefits reviews post-project, only to plan for such benefits reviews to occur. If the project is part of a programme, then the post-project benefits reviews need to be covered by the programme’s benefits management activities.

Hand Over Products
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – create/update the Follow-on-action-recommendations
Approver – approve the Configuration Item Records [p.240]
Producer – update the Benefits Review Plan [p.235]
Producer – obtain the Acceptance record
Project Assurance Role Actions:

Reviewer – review the Follow-on-action-recommendations
Reviewer – review the Configuration Item Records [p.240]
Reviewer – review the Benefits Review Plan [p.235]
Reviewer – review the Acceptance record
Project Board Role Actions:

(Approver – approve the Follow-on action recommendations)
(Approver – approve the Acceptance record)
(Reviewer – review the Benefits Review Plan [p.235])
Corporate/Programme Role Actions:

(Approver – approve the Benefits Review Plan [p.235])

Hand Over Products
Follow-on-action-recommendations

Created/Update by the Project Manager
Reviewed by Project Assurance
(Approved by the Project Board)
Configuration Item Records [A.5 – p.240]

Updated by Project Support
Reviewed by Project Assurance
Approved by the Project Manager
Benefits Review Plan [A.1 – p.235]

Updated by the Project Manager
Reviewed by Project Assurance
(Reviewed by the Project Board)
(Approved by the Corporate/Programme management)
Acceptance record

Obtained by the Project Manager
Reviewed by Project Assurance
(Approved by the Project Board)

Evaluate The project
Successful organizations learn from their experiences with projects. When evaluating the project, the objective is to assess how successful or unsuccessful the project has been. It may also be possible to improve the estimation for future projects by analysing the estimates and actual progress metrics for this project.

Evaluate The project
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – create the End Project Report [p.243]
Producer – create the Lessons Report [p.249]
Project Assurance Role Actions:

Reviewer – review the End Project Report [p.243]
Reviewer – review the Lessons Report [p.249]
Project Board Role Actions:

(Approver – approve the End Project Report [p.243])
(Approver – review the Lessons Report [p.249])
Corporate/Programme Role Actions:

(Approver – approve the Lessons Report [p.249])

Evaluate The project
End Project Report [A.8 – p.243]

Created by the Project Manager
Reviewed by Project Assurance
(Approved by the Project Board)
Lessons Report [A.15 – p.249]

Created by the Project Manager
Reviewed by Project Assurance
(Reviewed by the Project Board)
(Approved by Corporate/Programme management)

Recommend Project Closure
Closure recommendation (sent to Directing a Project process)

Recommend Project Closure
Once the Project Manager has confirmed that the project can be closed, a closure recommendation should be raised to the Project Board.

Recommend Project Closure
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – close the Issue Register [p.246]
Producer – close the Risk Register [p.260]
Producer – close the Quality Register [p.258]
Producer – close the Daily Log [p.242]
Producer – close the Lessons Log [p.248]
Producer – prepare the draft project closure notification
Project Assurance Role Actions:

Reviewer – review the draft project closure notification
Project Board Role Actions:

(Approver – approve the draft project closure notification)

Recommend Project Closure
Issue Register [A.12 – p.246]

Closed by the Project Manager
Risk Register [A.25 – p.260]

Closed by the Project Manager
Quality Register [A.23 – p.258]

Closed by the Project Manager
Daily Log [A.7 – p.242]

Closed by the Project Manager
Lessons Log [A.14 – p.248]

Closed by the Project Manager
Draft project closure notification

Prepared by the Project Manager
Reviewed by Project Assurance
(Approved by the Project Board)

Prepare Premature Closure
Premature Closure (from Directing a Project process)

Prepare Premature Closure
In some situations, the Project Board may have instructed the Project Manager to close the project prematurely. In such circumstances, the Project Manager must ensure that work in progress is not simply abandoned, but that the project salvages anything of value created to date and checks that any gaps left by the cancellation of the project are raised to corporate or programme management.

Prepare Premature Closure
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – update the Issue Register [p.250]
Producer – update the Project Plan [p.250]
Reviewer – review the Product Status Account [p.253]
Producer – create Additional work estimates
Project Assurance Role Actions:

Reviewer – review the Project Plan [p.250]
Reviewer – review the Product Status Account [p.253]
Reviewer – review the Additional work estimates
Project Support Role Actions:

Producer – create the Product Status Account [p.253]
Project Board Role Actions:

Approver – approve Additional work estimates

Prepare Premature Closure
Issue Register [A.16 – p.250]

Updated by the Project Manager
Project Plan [A.16 – p.250]

Updated by the Project Manager
Reviewed by Project Assurance
Product Status Account [A.18 – p.253]

Created by Project Support
Reviewed by the Project Manager
Reviewed by Project Assurance
Additional work estimates

Created by the Project Manager
Reviewed by Project Assurance
Approved later by the Project Board in Directing a Project process


PRINCE2 RESEARCH – PART THREE (PROCESSES) Part Eight


Controlling a Stage

15.1 Purpose

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

15.2 Objective
The objective of the Controlling a Stage process is to ensure that:

Attention is focused on delivery of the stage’s products. Any movement away from the direction and products agreed at the start of the stage is monitored to avoid uncontrolled change (‘scope creep’) andq loss of focus
Risks and issues are kept under control
The Business Case is kept under review
The agreed products for the stage are delivered to stated quality standards, within cost, effort and time agreed, and ultimately in support of the achievement of the defined benefits
The project management team is focused on delivery within the tolerances laid down.
15.3 Context
The Controlling a Stage process describes the work of the Project Manager in handling the day-to­day management of the stage. This process will be used for each delivery stage of a project. Towards the end of each stage, except the final one, the activities within the Managing a Stage Boundary process (see Chapter 17) will occur.

The Controlling a Stage process is normally first used after the Project Board authorizes the project, but it may optionally be used during the initiation stage for large or complex projects with a lengthy initiation.

Work Packages are used to define and control the work to be done, and also to set tolerances for the Team Manager(s). In the case where the Project Manager is fulfilling the Team Manager role, Work Packages should still be used to define and control the work of the individual team members being assigned work. Where this is the case, references to Team Manager throughout the Controlling a Stage process should be regarded as references to the individual team member being assigned work.

Central to the ultimate success of the project is the day-to-day control of the work that is being conducted. Throughout a stage, this will consist of a cycle of:

Authorizing work to be done
Monitoring progress information about that work, including signing off completed Work Packages
Reviewing the situation (including that for product quality) and triggering new Work Packages
Reporting highlights
Watching for, assessing and dealing with issues and risks
Taking any necessary corrective action.
Towards the end of the last stage, the Closing a Project process (see Chapter 18) will be invoked.

15.4 Activities
Controlling a Stage activities are Project-Manager-oriented and comprise:

Work Packages:
Authorize a Work Package
Review Work Package status
Receive completed Work Packages
Monitoring and reporting
Review the stage status
Report highlights
Issues:
Capture and examine issues and risks
Escalate issues and risks
Take corrective action.
Input Triggers
Authority to initiate a project (from Directing a Project process)

Output Triggers
Request to deliver a project (sent to Directing a Project process)
Stage Boundary approaching (sent to Managing a Stage Boundary process)

Authorize Work Package
Exception Plan approved (from Directing a Project process)
Stage Plan approved (from Directing a Project process)
Corrective action (internally from Controlling a Stage process)
New Work Package (internally from Controlling a Stage process)

Authorize Work Package
Authority to deliver a Work Package (sent to Managing Product Delivery process)

Authorize Work Package
It would be chaotic to have the people who are working on the project starting activities whenever they think fit. There must be a level of autonomy within the project team(s), but there will be wider issues involved of which they cannot be expected to be aware. It is therefore important that work only commences and continues with the consent of the Project Manager. The vehicle for this is the production, execution and delivery of a Work Package.

A Work Package may include extracts from, or simply cross-reference elements of, the Project Plan, Stage Plan or Project Initiation Documentation.

A Work Package should cover the work to create one or more products. If a product requires more than one Work Package to create it, then it should be broken down into further products with their supporting Product Descriptions.

The triggers for the Project Manager to authorize a Work Package include:

Stage authorization – the Project Board gives authority to execute a Stage Plan
Exception Plan approved – the Project Board gives authority to execute an Exception Plan
New Work Package required – an output from reviewing the stage status (see section 15.4.4)
Corrective action – in response to an issue or risk.
This activity is used to authorize new Work Packages or to authorize amendments to existing ones.

Authorize Work Package
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – create the Work Package [p.261]
Approver – approve the Configuration Item Record(s) [p.240]
Reviewer – review the Quality Register [p.258]
Producer – update the Risk Register [p.260]
Producer – update the Issue Register [p.246]
Reviewer – review the Team Plan [p.250]
Producer – update the Stage Plan [p.250]
Team Manager Role Actions:

(Approver – approve the Work Package [p.261])
(Reviewer – review the Configuration Item Record(s) [p.240])
(Reviewer – review the Quality Register [p.258])
(Producer – create the Team Plan [p.250])
(Reviewer – review the Stage Plan [p.250])
Project Assurance Role Actions:

Reviewer – review the Work Package [p.261]
Reviewer – review the Configuration Item Record(s) [p.240]
Reviewer – review the Quality Register [p.258]
Reviewer – review the Stage Plan [p.250]
Project Support Role Actions:

Producer – create/update the Configuration Item Record(s) [p.240]
Producer – update the Quality Register [p.258]

Authorize Work Package
Work Package [A.26 – p.261]

Created by the Project Manager
Reviewed by Project Assurance
(Approved by the Team Manager)
Configuration Item Record(s) [A.5 – p.240]

Created/Updated by Project Support
Reviewed by Project Assurance
Approved by the Project Manager
(Reviewed by the Team Manager)
Quality Register [A.23 – p.258]

Updated by Project Support
Reviewed by Project Assurance
Reviewed by the Project Manager
(Reviewed by the Team Manager)
Risk Register [A.25 – p.260]

Updated by the Project Manager
Issue Register [A.12 – p.246]

Updated by the Project Manager
Team Plan [A.16 – p.250]

Reviewed by the Project Manager
(Produced by the Team Manager)
Stage Plan [A.16 – p.250]

Updated by the Project Manager
Reviewed by Project Assurance
(Reviewed by the Team Manager)

Review Work Package Status
This activity provides the means for a regular assessment of the status of the Work Package(s). The frequency and formality of this activity will usually be aligned with the frequency of reporting defined in the Work Package(s) and supported by the Stage Plan for the current stage.

Review Work Package Status
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Reviewer – review the Checkpoint Report [p.238]
Reviewer – review the Team Plan(s) [p.250]
Producer – update the Stage Plan [p.250]
Approver – approve the Configuration Item Record [p.240]
Producer – update the Risk Register [p.260]
Producer – update the Issue Register [p.246]
Team Manager Role Actions:

(Producer – create the Checkpoint Report [p.238])
(Producer – create the Team Plan(s) [p.250])
(Reviewer – review the Configuration Item Record [p.240])
Project Assurance Role Actions:

Reviewer – review the Stage Plan [p.250]
Reviewer – review the Configuration Item Record [p.240]
Project Support Role Actions:

Producer – update the Configuration Item Record [p.240]

Review Work Package Status
Checkpoint Report [A.3 – p.238]

(Produced by the Team Manager)
Reviewed by the Project Manager
Team Plan(s) [A.16 – p.250]

(Produced by the Team Manager)
Reviewed by the Project Manager
Stage Plan [A.16 – p.250]

Updated by the Project Manager
Review by Project Assurance
Configuration Item Record [A.5 – p.240]

Produced by Project Support
Reviewed by Project Assurance
(Reviewed by the Team Manager)
Approved by the Project Manager
Risk Register [A.25 – p.260]

Updated by the Project Manager
Issue Register [A.12 – p.246]

Updated by the Project Manager

Receive Work Package
Completed Work Package (from Managing Product Delivery process)

Receive Work Package
Where work has been allocated to individuals or teams, there should be a matching confirmation that the work has been completed and approved.

Once approved, any subsequent changes to the product(s) must pass through change control (see Chapter 9). This should be an automatic part of any configuration management method being used.

Receive Work Package
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Approver – approve the Configuration Item Record(s) [p.240]
Producer – update the Stage Plan [p.250]
Team Manager Role Actions:

(Reviewer – review the Configuration Item Record(s) [p.240])
Project Assurance Role Actions:

Reviewer – review the Configuration Item Record(s) [p.240]
Reviewer – review the Stage Plan [p.250]
Project Support Role Actions:

Approver – Confirm the Configuration Item Record(s) [p.240]

Receive Work Package
Configuration Item Record(s) [A.5 – p.240]

Confirmed by Project Support
Reviewed by Project Assurance
(Reviewed by the Team Manager)
Approved by the Project Manager
Stage Plan [A.16 – p.250]

Updated by the Project Manager
Reviewed by Project Assurance

Review Stage Status
Project Board advice (from Directing a Project process)
Corrective Action (internally from Controlling a Stage process)

Review Stage Status
Stage Boundary approaching (sent to Managing a Stage Boundary process)
Project end approaching (sent to Closing a Project process)
Request for advice (sent to Directing a Project process)
Corrective Action (internally from Controlling a Stage process)
New Work Package (internally to Controlling a Stage process)
Tolerance threat (internally to Controlling a Stage process)

Review Stage Status
If the project is not checked on a timely basis, there is a danger that it will get out of control. There needs to be a balance between planning ahead and reacting to events.

In order to make informed decisions and exercise rational control, it is necessary to compare what has actually happened with what was expected to happen and what might happen next (including any issues and risks). It is therefore essential to have a steady flow of information that provides an overall view of progress and simple, robust monitoring systems to supply that information.

The objective of this activity, therefore, is to maintain an accurate and current picture of progress on the work being carried out and the status of resources.

This activity occurs at a frequency defined in the Stage Plan, may be triggered by Project Board advice, or forms part of the analysis of new issues and risks.

Review Stage Status
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – update the Risk Register [p.260
Producer – update the Issue Register [p.246]
Producer – update the Stage Plan [p.250]
Producer – update the Lessons Log [p.248]
Producer – update the Issue Report [p.247]
Project Assurance Role Actions:

Reviewer – review the Stage Plan [p.250]

Review Stage Status
Risk Register [A.25 – p.260]

Updated by the Project Manager
Issue Register [A.12 – p.246]

Updated by the Project Manager
Stage Plan [A.16 – p.250]

Updated by the Project Manager
Reviewed by Project Assurance
Lessons Log [A.14 – p.248]

Updated by the Project Manager
Issue Report [A.13 – p.247]

Updated by the Project Manager

Capture and Examine Issues and Risks
New Issue
New Risk

Capture and Examine Issues and Risks
Request for advice (sent to Directing a Project process)

Capture and Examine Issues and Risks
In the course of managing the project, various issues will occur and risks may be identified. They will arrive in an ad hoc manner and will need to be captured in a consistent and reliable way. Any member of the project, corporate or programme management, or other stakeholders may raise an issue or risk.

Before making a decision on a course of action, each issue or risk should be registered and then assessed for its impact.

For more details on risk management, see Chapters.

For more details on issue and change control procedures, see Chapter 9.

Capture and Examine Issues and Risks
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – update the Daily Log [p.242 ]
Producer – create the Issue Report [p.247]
Producer – update the Issue Register [p.246]
Producer – update the Risk Register [p.254]

Capture and Examine Issues and Risks
Producer – update the Daily Log [A.7 – p.242]

Updated by the Project Manager
Producer – create the Issue Report [A.13 – p.247]

Created by the Project Manager
Producer – update the Issue Register [A.12 – p.246]

Updated by the Project Manager
Producer – update the Risk Register [A.25 – p.260]

Updated by the Project Manager

Take Corrective Action
Corrective action (internally from Controlling a Stage process)

Changes and adjustments to the project need to be made in a considered and rational way, even when they appear to be easily manageable and within tolerances.

In taking corrective action, the objective is to select and, within the limits of the stage and project tolerances, implement actions that will resolve deviations from the plan. Corrective action is triggered during the review of the stage status (section 15.4.4) and typically involves dealing with advice and guidance received from the Project Board, and with issues raised by Team Managers.

For more details on planning, see Chapter 7. For more details on issue and change control, see Chapter9.

Take Corrective Action
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – update the Issue Register [p.246]
Producer – update the Risk Register [p.260]
Producer – update the Issue Report [p.247]
Producer – update the Stage Plan [p.250]
Producer – update the Configuration Item Record(s) [p.241] Producer – update the Daily Log [p.242]
Team Manager Role Actions:

(Reviewer – review the Configuration Item Record(s) [p.241])
Project Assurance Role Actions:

Reviewer – review the Issue Report [p.247]
Reviewer – review the Stage Plan [p.250]
Project Support Role Actions:

Reviewer – review the Configuration Item Record(s) [p.241]

Take Corrective Action
Issue Register [A.12 – p.246]

Updated by the Project Manager
Risk Register [A.25 – p.260]

Updated by the Project Manager
Issue Report [A.13 – p.247]

Updated by the Project Manager
Reviewed by Project Assurance
Stage Plan [A.16 – p.250]

Updated by the Project Manager
Reviewed by Project Assurance
Configuration Item Record(s) [A.6 – p.241]

Updated by the Project Manager
Reviewed by Project Support
(Reviewed by the Team Manager)
Daily Log [A.7 – p.242]

Updated by the Project Manager

Escalate Issues and Risks
Tolerance threat (internally to Controlling a Stage process)

Escalate Issues and Risks
Exception raised (sent to Directing a Project process)

A stage should not exceed the tolerances agreed with the Project Board. The Project Manager can only take corrective action or maintain the status quo as long as the stage (or project) is forecast to be completed within the tolerances set by the Project Board. This activity applies where any corrective action within the Project Manager’s control would not save the stage (or project) from going beyond the tolerances agreed. This applies to all types of issue and risk (or aggregation of them) that cannot be resolved within the tolerances set by the Project Board.

As it may take some time to gather the information to create an Exception Report, it is recommended that the Project Board be alerted as early as possible. Therefore, the Project Manager may wish to execute this activity in two steps: an early notification to the Project Board of the forecast exception situation in order to prepare them, followed by supporting information in the form of an Exception Report.

The Project Manager should execute any decision by the Project Board in response to the escalation.

Escalating issues and risks is good practice and should not be seen as failure. The earlier that issues are escalated, the more time is available to implement any corrective actions.

For more details on management of risk, see Chapters.

For more details on issue and change control, see Chapter 9.

For more details on exception management, see Chapter 10.

Escalate Issues and Risks
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – create the Exception Report [p.245]
Producer – update the Issue Register [p.246]
Producer – update the Risk Register [p.260]
Producer – update the Issue Report [p.247]
Project Assurance Role Actions:

Producer – create the Exception Report [p.245]
Senior User & Senior Supplier Role Actions:

(Reviewer – review the Exception Report)
Executive Role Actions:

(Approver – approve the Exception Plan)

Escalate Issues and Risks
Exception Report [A.10 – p.245]

Created by the Project Manager
Reviewed by Project Assurance
(Reviewed by the Senior User & Senior Supplier)
(Reviewed by the Executive)
Issue Register [A.12 – p.246]

Updated by the Project Manager
Risk Register [A.25 – p.260]

Updated by the Project Manager
Issue Report [A.13 – p.247]

Updated by the Project Manager

Report Highlights
The Project Manager must provide the Project Board with summary information about the status of the stage and project and distribute other information to stakeholders at a frequency documented in the Communication Management Strategy (as defined by the Project Board). For more details on progress controls, see Chapter 10.

Report Highlights
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – create the Highlight Report [p.245]
Project Assurance Role Actions:

Reviewer – review the Highlight Report [p.245]

Report Highlights
Highlight Report [A.11 – p.245]

Created by the Project Manager
Reviewed by Project Assurance


PRINCE2 RESEARCH – PART THREE (PROCESSES) Part Seven


Managing a Stage Boundary

17.1 Purpose

The purpose of the Managing a Stage Boundary process is to enable the Project Board to be provided with sufficient information by the Project Manager so that it can review the success of the current stage, approve the next Stage Plan, review the updated Project Plan, and confirm continued business justification and acceptability of the risks.

Therefore, the process should be executed at, or close to the end of, each management stage.
Projects do not always go to plan and in response to an Exception Report (if the stage or project is forecast to exceed its tolerances) the Project Board may request that the current stage (and possibly the project) is re-planned. The output from re-planning is an Exception Plan which is submitted or Project Board approval in the same way that a Stage Plan is submitted for approval.

16.2 Objective
The objective of the Managing a Stage Boundary process is to:

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

Prepare an Exception Plan as directed by the Project Board
Seek approval to replace the Project Plan or Stage Plan for the current stage with the Exception Plan.
Managing a Stage Boundary is not used towards the end of the final stage (unless there is a need to create an Exception Plan) because the activities to review the performance of the final stage are included in the activities to review the performance of the whole project as part of the Closing a Project process.

16.3 Context
The Managing a Stage Boundary process is predicated on dividing the project into management stages (see Chapter 10).

A project, whether large or small, needs to ensure that the products it creates will deliver the benefits being sought, either in their own right or as part of a larger programme. The continuing correct focus of the project should be confirmed at the end of each stage. If necessary, the project can be redirected or stopped to avoid wasting time and money.

It is also important to recognize that projects can go wrong or can be affected by external factors that invalidate the business justification. An early identifier of potential failure is the Project Manager’s forecast that any of the project or stage tolerances are likely to be exceeded. In such cases it is important to have a mechanism for corrective action in order to bring the project back into the right direction.

A positive decision not to proceed is not failure. However, providing insufficient information that prevents the Project Board from making an informed decision is itself a failure as it may lead to a wrong decision.

The Managing a Stage Boundary process provides a means by which an exception process can be implemented.

16.4 Activities
The activities within the Managing a Stage Boundary process are Project-Manager-oriented and are to:

Plan the next stage
Update the Project Plan
Update the Business Case
Report stage end
Produce an Exception Plan.
Input Triggers
Stage boundary approaching (from Controlling a Stage process or Initiating a Project process)
Exception Plan request (from Directing a Project process)
Output Triggers
Request to approve Exception Plan (sent to Directing a Project process)
Request to approve Stage Plan (sent to Directing a Project process)

Plan The Next Stage
Stage boundary approaching (from Controlling a Stage process or Initiating a Project process)

Plan The Next Stage
The Stage Plan for the next management stage is produced near the end of the current stage. Closure activities should be planned as part of the Stage Plan for the final stage.

Planning is not an activity undertaken in isolation. The Project Manager will need to consult with the Project Board, Project Assurance, Team Managers and possibly other stakeholders in order to create a viable plan. The more people involved in planning, the more robust the plan will be (so long as the right people are involved). See Chapter 7 for more details on planning.

Plan The Next Stage
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – update the Project Initiation Documentation [p.254]
Producer – create the Stage Plan [p.250]
Producer – create/update the Configuration Item Record(s) [p.240]
Producer – update the Risk Register [p.260]
Producer – update the Issue Register [p.246]
Reviewer – review the Quality Register [p.258]
Project Assurance Role Actions:

Reviewer – review the Project Initiation Documentation [p.254]
Reviewer – review the Stage Plan [p.250]
Reviewer – review the Configuration Item Record(s) [p.240]
Reviewer – review the Risk Register [p.260]
Reviewer – review the Issue Register [p.246]
Reviewer – review the Quality Register [p.258]
Project Board Role Actions:

(Approver – approve the Project Initiation Documentation)
(Approver – approve the Stage Plan)
Corporate/Programme Role Actions:

(Review – review the Project Initiation Documentation)
Project Support Role Actions:

Reviewer – review the Configuration Item Record(s) [p.240]
Producer – update the Quality Register [p.258]

Plan The Next Stage
Project Initiation Documentation [A.20 – p.254]

Updated by the Project Manager
Reviewed by Project Assurance
(Reviewed by Corporate/Programme management)
(Approved by the Project Board)
Stage Plan [A.16 – p.250]

Created by the Project Manager
Reviewed by Project Assurance
(Approved by the Project Board)
Configuration Item Record(s) [A.5 – p.240]

Created/Updated by the Project Manager
Reviewed by Project Assurance
Reviewed by Project Support
Risk Register [A.25 – p.260]

Updated by the Project Manager
Reviewed by Project Assurance
Issue Register [A.12 – p.246]

Updated by the Project Manager
Reviewed by Project Assurance
Quality Register [A.23 – p.258]

Updated by Project Support
Reviewed by the Project Manager
Reviewed by Project Assurance

The Project Board uses the Project Plan throughout the project to measure progress.

The Project Plan is updated to incorporate actual progress from the stage that is finishing, and to include forecast duration and costs from the Exception Plan or Stage Plan for the stage about to begin.

Details of any revised costs or end dates are used when updating the Business Case.

See Chapter 7 for more details on planning.

Update Project Plan
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – update the Project Plan [p.250]
Producer – update the Risk Register [p.260]
Producer – update the Issue Register [p.246]
Project Assurance Role Actions:

Reviewer – review the Project Plan [p.250]
Reviewer – review the Risk Register [p.260]
Reviewer – review the Issue Register [p.246]
Project Board Role Actions:

(Approver – approve the Project Plan)

Update Project Plan
Project Plan [A.16 – p.250]

Updated by the Project Manager
Reviewed by Project Assurance
(Approved by the Project Board)
Risk Register [A.25 – p.260]

Updated by the Project Manager
Reviewed by Project Assurance
Issue Register [A.12 – p.246]

Updated by the Project Manager
Reviewed by Project Assurance

Update Business Case
It is a PRINCE2 principle that projects have continued business justification.

The Project Board is ordinarily only authorized to continue while the project remains viable (that is, the benefits will be realized within the cost, time, quality, scope and risk parameters set out in the currently agreed Business Case).

Projects, however, do not take place in a static environment. The environment external to the project changes, as do the nature and timing of the project’s products. The Business Case needs to reflect these changes and must be reviewed and amended to keep it relevant to the project.

As the Executive is responsible for the Business Case, the Project Manager should consult with the Executive when reviewing and updating the Business Case in preparation for Project Board approval.

For further details on business justification, see Chapter 4.

Update Business Case
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – update the Business Case [p.237]
Producer – update the Benefits Review Plan [p.235]
Producer – update the Risk Register [p.260]
Producer – update the Issue Register [p.246]
Project Assurance Role Actions:

Reviewer – review the Business Case [p.237]
Reviewer – review the Benefits Review Plan [p.235]
Reviewer – review the Risk Register [p.260]
Reviewer – review the Issue Register [p.246]
Project Board Role Actions:

(Approver – approve the Business Case)
(Approver – approve the Benefits Review Plan)
Corporate/Programme Role Actions:

(Reviewer – review the Business Case)
(Reviewer – review the Benefits Review Plan)

Update Business Case
Business Case [A.2 – p.237]

Updated by the Project Manager
Reviewed by Project Assurance
(Reviewed by Corporate/Programme management)
(Approved by the Project Board)
Benefits Review Plan [A.1 – p.235]

Updated by the Project Manager
Reviewed by Project Assurance
(Reviewed by Corporate/Programme management)
(Approved by the Project Board)
Risk Register [A.25 – p.260]

Updated by the Project Manager
Reviewed by Project Assurance
Issue Register [A.12 – p.246]

Updated by the Project Manager
Reviewed by Project Assurance

Report Stage End
Request to approve Exception Plan (sent to Directing a Project process)
Request to approve Stage Plan (sent to Directing a Project process)

Report Stage End
The results of a stage should be reported back to the Project Board so that progress is clearly visible to the project management team.

The Project Manager gives a view on the continuing ability of the project to meet the Project Plan and Business Case, and assesses the overall risk situation.

This activity should happen as close as possible to the actual end of a stage.

Report Stage End
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – create the End Stage Report [p.244]
Producer – create the Lessons Report [p.249]
Producer – create the Follow-on-action-recommendations
Project Assurance Role Actions:

Reviewer – review the End Stage Report [p.244]
Reviewer – review the Lessons Report [p.249]
Reviewer – review the Follow-on-action-recommendations
Project Board Role Actions:

(Approver – approve the End Stage Report [p.244])
(Approver – approve the Lessons Report [p.249])
(Approver – approve the Follow-on-action-recommendations)

Report Stage End
End Stage Report [A.9 – p.244]

Created by the Project Manager
Reviewed by Project Assurance
(Reviewed by the Project Board)
Lessons Report [A.15 – p.249]

Created by the Project Manager
Reviewed by Project Assurance
(Reviewed by the Project Board)
Follow-on-action-recommendations

Created by the Project Manager
Reviewed by Project Assurance
(Reviewed by the Project Board)

Create Exception Plan
Exception Plan request (from Directing a Project process)

If a stage or the project is forecast to deviate beyond its agreed tolerances, it no longer has the approval of the Project Board.

Exception Plans are requested by the Project Board in response to an Exception Report. Although an Exception Plan will be produced prior to the planned stage boundary, its approval by the Project Board marks a stage boundary for the revised stage.

Planning is not an activity undertaken in isolation. The Project Manager will need to consult with Project Board members, Project Assurance, Team Managers and possibly other stakeholders in order to create a viable plan. The more people involved in planning, the more robust the plan will be. See Chapter 7 for more details on planning.

Create Exception Plan
Actions shown in brackets are actions that are actually carried out in another process.

Project Manager Role Actions:

Producer – update the Project Initiation Documentation [p.254]
Producer – create the Exception Plan [p.250]
Reviewer – review the Configuration Item Record(s) [p.240]
Producer – update the Risk Register [p.260]
Producer – update the Issue Register [p.246]
Reviewer – review the Quality Register [p.258]
Project Assurance Role Actions:

Reviewer – review the Project Initiation Documentation [p.254]
Reviewer – review the Exception Plan [p.250]
Reviewer – review the Configuration Item Record(s) [p.240]
Reviewer – review the Risk Register [p.260]
Reviewer – review the Issue Register [p.246]
Reviewer – review the Quality Register [p.258]
Project Board Role Actions:

(Approver – approve the Project Initiation Documentation [p.254])
(Approver – approve the Exception Plan [p.250])
Corporate/Programme Role Actions:

(Reviewer – review the Project Initiation Documentation [p.254])
Project Support Role Actions:

Producer – Create/Update the Configuration Item Record(s) [p.240]
Producer – update the Quality Register [p.258]
Team Manager Role Actions:

(Reviewer – review the Quality Register [p258])

Create Exception Plan
Project Initiation Documentation [A.20 – p.254]

Updated by the Project Manager
Reviewed by Project Assurance
(Reviewed by Corporate/Programme management)
(Approved by the Project Board)
Exception Plan [A.16 – p.250]

Created by the Project Manager
Reviewed by Project Assurance
(Approved by the Project Board)
Configuration Item Record(s) [A.5 – p.240]

Created/Updated by Project Support
Reviewed by Project Assurance
Reviewed by the Project Manager
Risk Register [A.25 – p.260]

Updated by the Project Manager
Reviewed by Project Assurance
Issue Register [A.12 – p.246]

Updated by the Project Manager
Reviewed by Project Assurance
Quality Register [A.23 – p.258]

Updated by Project Support
Reviewed by the Project Manager
Reviewed by Project Assurance
(Reviewed by the Team Manager)


%d bloggers like this: