Techniques Guide

• Overview and Guidance
• Managing Level 1 Projects
• Managing Level 2 Projects
• Techniques Guide
• Templates Guide

• Section 1 - Introduction
• Section 2 - Business Case
• Section 3 - Organisation
• Section 4 - Quality
• Section 5 - Plans
• Section 6 - Risk
• Section 7 - Change
• Section 8 - Progress
• Section 9 - Project Management Glossary
• Section 10 - Continued Improvement& Feedback

You should also seek help and advice from colleagues and mentors who have completed the PRINCE2®; training.

This information and Project Level thinking should be applied to develop a "Project Level" Business Case appropriate in detail to the project that is being started. The Project Manager should consider distinguishing between Project Outputs/Products, The resultant Change/Outcomes and the measurable Benefits to the Business.

The Business Case is then refined during the initiation stage, in the 'Initiating a project' process after producing the Project Plan, and assembled as part of the Project Initiation Documentation (PID). It is then submitted to the Project Board as part of the PID for approval at the end stage assessment. For Level 1 projects Start Up and Initiation can be combined as described in 'Managing Level 1 Projects Guide'.

Throughout each stage of the project, the Business Case will need to be reviewed, particularly when issues and risks are raised as these may have an impact on the benefits, costs, timescales and existing key risks. As a minimum, the Business Case should be updated by the Project Manager at the end of each management stage as part of the 'Managing a Stage Boundary' process. This will provide the Project Board with the information required to make a decision as to whether or not the projects remains worthwhile and viable.

At the end of the project, the Business Case is reviewed to assess the project's performance against its requirements and the likelihood that the outcomes will provide the expected benefits.

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).

The Project Board membership should be representative of the Stakeholders interests lead by the Executive Role representing the Business and ultimate ownership of the Project. Also the Project Board membership should be able to fulfil the Responsibilities and Competencies listed below.

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.

General responsibilities

During start-up and initiation:

• Confirm project tolerances with corporate or programme management
• Approve the Project Brief
• Approve the Stage Plan for the initiation stage
• Authorize project initiation
• Decide whether to use a Change Authority and, if so, agree the level of authority to be delegated
• Set the scale for severity ratings for issues
• Set the scale for priority ratings for requests for change and off-specifications
• Approve the supplier contract (if the relationship between the customer and supplier is a commercial one)
• Approve the Project Initiation Documentation (and its components)
• Authorize the start of the project.

• Set tolerances for each stage and approve Stage Plans
• Authorize each management stage and approve their Product Descriptions
• Approve Exception Plans when stage-level tolerances are forecast to be exceeded
• Communicate with stakeholders as defined in the Communication Management Strategy (including briefing corporate or programme management about project progress)
• Provide overall guidance and direction to the project, ensuring it remains viable and within any specified constraints
• Respond to requests for advice from the Project Manager
• Ensure that risks are being tracked and managed as effectively as possible
• Approve changes (unless delegated to a Change Authority)
• Make decisions on escalated issues
• Approve completed products.

• Provide assurance that all products have been delivered satisfactorily
• Provide assurance that all Acceptance Criteria have been met
• Confirm acceptance of the project product
• Approve the End Project Report and ensure that any issues, lessons and risks are documented and passed on to the appropriate body
• Authorize follow-on action recommendations and Lessons Report to be distributed to corporate or programme management
• Transfer responsibility of the updated Benefits Review Plan to corporate or programme management
• Authorize project closure and send project closure notification to corporate or programme management.

Competencies

• Have sufficient authority to make decisions, approve plans and authorize deviation from Stage Plans
• Have sufficient authority to allocate resources to the project
• Be capable of adequately representing the business, user and supplier interests
• Ideally be able to stay with the project throughout its life.

• Decision-making
• Delegation
• Leadership
• Negotiation and conflict resolution.

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.

Responsibilities

• Design and appoint the project management team (in particular the Project Manager)
• Oversee the development of the Project Brief and the outline Business Case ensuring that the project is aligned with corporate strategies (presenting the outline Business Case to corporate or programme management for approval where required)
• Oversee the development of the detailed Business Case
• Secure the funding for the project
• Approve any additional supplier contracts (if the relationship between the user and supplier is a commercial one)
• Hold the Senior Supplier to account for the quality and integrity of the specialist approach and specialist products created for the project
• Hold the Senior User to account for realizing the benefits defined in the Business Case, ensuring that benefits reviews take place to monitor the extent to which the Business Case benefits are achieved
• Transfer responsibility for post-project benefits reviews to corporate or programme management
• Monitor and control the progress of the project at a strategic level, in particular reviewing the Business Case regularly
• Escalate issues and risks to corporate or programme management if project tolerance is forecast to be exceeded
• Ensure that risks associated with the Business Case are identified, assessed and controlled
• Make decisions on escalated issues with particular focus on continued business justification
• Organize and chair Project Board reviews
• Ensure overall business assurance of the project - that it remains on target to deliver products that will achieve the expected business benefits, and that the project will be completed within its agreed tolerances. Where appropriate, delegate some business Project Assurance activities

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) specify the benefits and is held to account by demonstrating to corporate or programme management that the forecast benefits that were the basis of project approval are in fact realized. This is likely to involve a commitment beyond the end of the life of the project.

Responsibilities

• Provide the customer's quality expectations and define acceptance criteria for the project
• Ensure that the desired outcome of the project is specified
• Ensure that the project produces products which will deliver the desired outcomes, and meet user requirements
• Ensure that the expected benefits (derived from the project's outcomes) are realized
• Provide an actual versus forecast benefits statement at the benefits reviews
• Resolve user requirements and priority conflicts
• Ensure that any user resources required for the project are made available (e.g. to undertake user quality inspections and product approval)
• Make decisions on escalated issues with particular focus on safeguarding the expected benefits
• Brief and advise user management on all matters concerning the project
• Maintain business performance stability during transition from the project to business as usual
• Provide the user view on follow-on action recommendations
• Undertake Project Assurance from the user perspective (user assurance) and, where appropriate, delegate user Project Assurance activities.

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).

Responsibilities

• Assess and confirm the viability of the Project Approach
• Ensure that proposals for designing and developing the products are realistic
• Advise on the selection of design, development and acceptance methods
• Ensure that the supplier resources required for the project are made available
• Make decisions on escalated issues, with particular focus on safeguarding the integrity of the complete solution
• Resolve supplier requirements and priority conflicts
• Brief non-technical management on supplier aspects of the project
• Ensure quality procedures are used correctly, so that products adhere to requirements
• Undertake Project Assurance from the supplier perspective (supplier assurance) and, where appropriate, delegate supplier Project Assurance activities

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.

It is generally agreed and understood the Project Manager is an internally appointed individual with the requisite skill sets to perform this Role.

Specific responsibilities

• Prepare the following baseline Management Products, in conjunction with any Project Assurance roles, and agree them with the Project Board:
  • Project Brief, including the Project Product Description
  • Benefits Review Plan
  • Project Initiation Documentation(and its components)
  • Stage/Exception Plans and their Product Descriptions
  • Work Packages
  
  Prepare the following reports:
  • Highlight Reports
  • Issue Reports
  • End Stage Reports
  • Lessons Report
  • Exception Reports
  • End Project Report
  
  Maintain the following records:
  • Issue Register
  • Risk Register
  • Daily Log
  • Lessons Log
  
  
• Liaise with corporate or programme management to ensure that work is neither overlooked nor duplicated by related projects
• Liaise with any external suppliers or account managers
• Lead and motivate the project management team
• Ensure that behavioural expectations of team members are established
• Manage the information flows between the directing and delivering levels of the project
• Manage the production of the required products, taking responsibility for overall progress and use of resources and initiate corrective action where necessary
• Establish and manage the project's procedures - risk management, issue and change control, configuration management, and communication
• Establish and manage the project controls - monitoring and reporting
• Authorize Work Packages
• Advise the Project Board of any deviations from the plan
• Unless appointed to another person(s), perform the Team Manager role
• Unless appointed to another person (or corporate/programme function), perform the Project Support role
• Implement the Configuration Management Strategy
• Ensure project personnel comply with the Configuration Management Strategy
• Schedule configuration audits to check that the physical products are consistent with the Configuration Item Records and initiate any necessary corrective action.

Competencies

• Planning
• Time management
• People management
• Problem-solving
• Attention to detail
• Communication
• Negotiation
• Conflict management.

Team Managers need to be considered in line with size, nature and complexity of the work as well as specialist skills required and geographical implications of the project.

Team Managers should use Work Packages and Team Plans to capture scope and plan agreements of work that falls under their responsibility.

Responsibilities

• Prepare the Team Plan and agree it with the Project Manager
• Produce Checkpoint Reports as agreed with the Project Manager
• Plan, monitor and manage the team's work
• Take responsibility for the progress of the team's work and use of team resources, and initiate corrective action, where necessary, within the constraints laid down by the Project Manager
• Identify and advise the Project Manager of any issues and risks associated with a Work Package
• Advise the Project Manager of any deviations from the plan, recommend corrective action, and help to prepare any appropriate Exception Plans
• Pass back to the Project Manager products that have been completed and approved in line with the agreed Work Package requirements
• Liaise with any Project Assurance and Project Support roles
• Ensure that quality activities relating to the team's work are planned and performed correctly, and within tolerance
• Ensure that the appropriate entries are made in the Quality Register
• Manage specific issues and risks as directed by the Project Manager
• Assist the Project Manager in examining issues and risks
• Ensure that all assigned issues are properly reported to the person maintaining the Issue Register.

Competencies

Personnel involved in Project Assurance are also responsible for supporting the Project Manager by giving advice on such things as corporate standards, or correct personnel to involve in quality inspections or reviews.

Project Assurance should be involved through out all the processes in the project and as part of its function monitor all aspects of the projects performance and product delivery. They should provide Assurance in line with the required competencies listed below.

The Project Assurance role along with the PMO will also assist in ensuring projects follow the PRINCE2® Project Management Method.

Responsibilities

• Liaison is maintained between the business, user and supplier throughout the project
• Risks are controlled
• The right people are involved in writing Product Descriptions
• The right people are planned to be involved in quality inspection at the correct points in the products' development
• Staff are properly trained in the quality methods
• The quality methods are being correctly followed
• Quality control follow-up actions are dealt with correctly
• An acceptable solution is being developed
• The scope of the project is not changing unnoticed
• Internal and external communications are working
• Applicable standards are being used
• The needs of specialist interests (for example, security) are being observed.

Business assurance responsibilities

• Assist the Project Manager to develop the Business Case and Benefits Review Plan (if it is being prepared by the Project Manager)
• Advise on the selection of project management team members
• Advise on the Risk Management Strategy
• Review the Business Case for compliance with corporate or programme standards
• Verify the Business Case against external events and against project progress
• Check that the Business Case is being adhered to throughout the project
• Check that the project remains aligned to the corporate or programme strategy
• Review project finance on behalf of the customer
• Verify that the solution continues to provide value-for-money
• Periodically check that the project remains viable
• Assess that the aggregated risk exposure remains within project tolerance
• Check that any supplier and contractor payments are authorized
• Review issues and risks by assessing their impact on the Business Case
• Constrain user and supplier excesses
• Inform the project management team of any changes caused by a programme of which the project is part (this responsibility may be transferred if there is other programme representation on the project management team)
• Monitor stage and project progress against the agreed tolerances.

User assurance responsibilities

• Advise on stakeholder engagement
• Advise on the Communication Management Strategy
• Ensure that the specification of the user's needs is accurate, complete and unambiguous
• Assess whether the solution will meet the user's needs and is progressing towards that target
• Advise on the impact of potential changes from the user's point of view
• Monitor risks to the user
• Ensure that the quality activities relating to products at all stages has appropriate user representation
• Ensure that quality control procedures are used correctly to ensure that products meet user requirements
• Ensure that user liaison is functioning effectively.

Supplier assurance responsibilities

• Review the Product Descriptions
• Advise on the Quality Management Strategy and Configuration Management Strategy
• Advise on the selection of the development strategy, design and methods
• Ensure that any supplier and operating standards defined for the project are met and used to good effect
• Advise on potential changes and their impact on the correctness, completeness and integrity of products against their Product Description from a supplier perspective
• Monitor any risks in the production aspects of the project
• Assess whether quality control procedures are used correctly, so that products adhere to requirements

Competencies

• Be capable of adequately representing the business, user or supplier stakeholder interests
• Have sufficient credibility to ensure that advice and guidance are followed
• Have sufficient specialist knowledge of the business, user or supplier stakeholder areas
• Ideally be able to stay with the project throughout its lifecycle.

• Diplomacy
• Thoroughness
• Attention to detail
• Communication

The Project Manager could be assigned as the Change Authority for some aspects of the project.

Responsibilities

• Review and approve or reject all requests for change and off-specifications within the delegated limits of authority and change budget set by the Project Board
• Refer to the Project Board if any delegated limits of authority or allocated change budget are forecast to be exceeded.

Competencies

• Be capable of adequately representing the business, user and supplier stakeholder interests
• Have sufficient credibility to ensure that advice and guidance are followed
• Have sufficient specialist knowledge of the business, user or supplier stakeholder areas.

Key competencies include:

• Decision-making
• Planning
• Attention to detail
• Problem-solving

Project Guidance and Support

Whilst it is considered that Project Managers will manage and administer projects themselves they are not without guidance and support. The Project Management Office Role is recognised for providing guidance and support in areas that cross over many projects.

These areas fundamentally include Project Planning, Risk Management, Configuration Management and Change Control.

This Role also has Responsibility for this Project Management Guide and its contents.

Summary of PMO Responsibilities

• Ensure Project Management is being done under PRINCE2®
• Establish the project filing structure
• Maintain the Intranet available Lessons Reports
• Establish document control procedures and standards
• Collect actuals data and forecasts and assist with the production of reports
• Assist the quality review process
• Assist in Project Board meetings
  
• Provide Guidance on the Configuration Management procedure:
  • Identifying the process for the receipt, identification, versions, storage and issue of all project products
  • Gather information on the status of all products (by advising use of Product Status Accounts)
  • Establish an archive for superseded product copies
  • Ensure the security and preservation of the master copies of all project products
  • Conduct configuration audits
  
  
• Provide Guidance on Change Control:
  • Use of Repositories
  • Assist in establishing Change Budgets for projects
  • Ensure Changes are managed formally using Configuration Management
  
  
• Provide Guidance on the Risk Management procedure:
  • Advise in the use of Risk Management Processes
  • Develop and Evolve Risk Management processes for Project managers
  
  
• Contribute expertise in specialist tools and techniques for Planning projects
  • Establish plans structure
  • Develop and provide planning templates
  • Develop planning standards Help identify planning training requirements

Competencies

• Administration and organization
• Knowledge of specialist tools and techniques
• Knowledge of corporate or programme management standards applicable to the project.

Quality Planning begins with establishing the acceptance criteriafor the project during Start Up, and the Products are identified and defined using the Product based planning technique during Initiating and Stage Boundaries. The development and quality management of these products should then be planned in the appropriate level of plan, whether it is at project, stage or team level.

The level of quality applied to the project will depend on its size and nature. Delivery of products that meet quality criteria is paramount to the success of any project, which means that quality management needs to be applied correctly.

Acceptance Criteria

Information from the Customer Quality Expectations and acceptance criteria will be input to the Project Product Description so that a clear understanding of the overall project's requirements and criteria are documented and agreed, which in turn will feed into the development of the Quality Management Strategy during the Initiation Stage.

These Product Descriptions will form part of the Stage Plan, and will be baselined when the relevant Stage Plan is approved by the Project Board. Details of the quality criteria, quality checking methods and skills required are included in the Product Descriptions, giving clear definition of how the product should be checked.

The Quality Management Strategy is approved by the Project Board as part of the PID, and is then reviewed during each stage to reference the quality management procedures and methods. At the end of each stage, and at the end of the project, it is used to define how quality statistics are reported.

An informal Quality Review may take many forms.

• A simple test or visual inspection to check the Product may be both sensible and acceptable.
• A "desk-check" that might be performed by the author's line manager, or carried out by an expert Reviewer either within or outside the project.
• A physical test to assure compliance with the Quality Criteria; Design Review, Test Scripts, Unit Tests, Integration Tests, Formal Tests, Acceptance Tests

Step 1 - Review Preparation

Step 2 - The Review Meeting Agenda

Step 3 - Review Follow-up

Quality Assurance creates and maintains the Quality Management System, ensuring that corporate standards are applied to activities that occur in appropriate departments of an organization, whether those activities are within a project or not.

Project Assurance on the other hand is a role that ensures the project management approaches and standards are adhered to within the project.

There is some cross-over when corporate standards apply to projects. These should be defined in the Project's Quality Management Strategy. Quality Assurance has the responsibility to check that these standards are applied correctly within the project, while Project Assurance is responsible for ensuring that the corporate standards are defined in the Quality Management Strategy.

A plan provides information on how the products, timescales, costs and quality can be met, using the available resources within the given constraints. There will be a number of elements that make up a plan, including the products to be produced; the activities needed to create those products; the resources, time and budget needed for all activities (plus tolerances); dependencies between activities; planning assumptions; inherent risks and the points at which progress will be monitored and controlled.

Plans will be need to be written at the right level of detail, and at the appropriate time. For instance, planning the entire project in detail during the initiation stage would not be desirable or even possible. The length of time we can plan ahead in detail with some accuracy is known as the planning horizon. Plans should therefore be prepared at different levels of scope and detail. Detailed Stage Plans should be prepared near the end of the current stage to help counter the planning horizon issue.

The planning steps will primarily take place during initiation when planning the project, and towards the end of each management stage when producing Stage Plans.

If requested, Exception Plans may be produced to recover a project or stage from exceeding tolerances. The Exception Plan is seen to be on the same level as the Stage Plan, and is not used for recovering Work Package exceptions. Exception Plans would also be produced use the planning steps.

Optional Team Plans may also be needed, and could be created in parallel with the Stage Plan. If a Team Manager forecasts that the Work Package may exceed tolerances, they will notify the Project Manager by raising an issue which then if need be could become an exception.

Additional guidance on some of the planning techniques used can be found within this guide.

A plan is made up of many pieces of information, and therefore requires several different techniques to complete it. A template for a typical plan is in the Templates Guide. The table below shows each step required for creating the full plan. These steps of planning are iterative and are used each time a plan is created.

In order to develop consistent Plans/ Schedules the following planning steps should be considered:

The key benefit to having a product based approach to planning is that its initial focus is on deliverables, rather that activity. This will help you better understand the products that need creating.

There are four main steps to Product Based Planning:

• Product Description for the Project (Go to Quality in this guide)
• Product Breakdown Structure
• Product Descriptions for all other Products
• Product Flow Diagram

Example of a Product Breakdown Structure

The format of the PBS is often that of a diagram, where the products are broken down using a hierarchical approach, although you might prefer a more textual approach using Bullet Points for example. Some projects may require a workshop involving many people; for others the Project Manager may be able to complete this alone. Either way the outcome is the same – a list of products that need to be developed.

At the beginning of Level 2 projects, it is sensible to plan the project at high-level, identifying the main products first when creating your Project Plan. More detailed plans can be created for each stage as the project progresses.

The resultant list should be critically reviewed with the Project Management Team in the light of what is known about the proposed project, to produce an agreed list of the Products to be produced. This is known as a Product Breakdown Structure and contains a list of the Specialist Products and Management Products associated with the project.

Each Product identified in your PBS requires a Product Description. Content and advice on Product Descriptions can be found in the Templates Guide. Product Descriptions are key to ensuring the quality of products, and therefore need careful consideration when writing them.

The Quality section in this Techniques Guide explains how Product Descriptions are used to check that a product is “fit for purpose”. It is advisable to read the Quality chapter prior to writing the Product Descriptions to give yourself an understanding of how the information is used.

Example of a Product Flow Diagram

• Experience – speaking to people who have done it before
• Historical information – looking at project plans and files for similar work
• Best guess – making a judgement on expressed opinions

• A list of products that need to be developed
• A list of activities that need to be undertaken
• Estimates of how long each activity will take and how much it will cost.

A simple Logic Diagram

The above diagram is a simple “Logic Diagram” which shows the dependencies of each activity. Use this technique to place the activities in sequence. This will help to identify which activities are dependant on others.

Using the Logic Diagram, you can now apply the time estimates. This is easily done using a software tool such as MS Project. There is a manual technique for completing this known as the “Programme Evaluation Review Technique”. The PRINCE2®; Manual explains this technique.

When you have applied the estimates, you should have a better understanding of the total timeline of the plan, and a clear indication of what and when things will happen. This is usually presented in graphical form known as a Bar Chart or Gantt Chart (see below).

Example of a Bar Chart

• Product Breakdown Structure / Product Descriptions / Product Flow Diagram
• Activity List with Estimates
• Logic Diagram/Bar Chart/Gantt Chart
• Summary of Resource Requirements (the Resources Report)
• Summary of Plan, (the Plan Text)

Throughout the planning approach, the Project Manager will need to analyse the risks associated with the plan. This might include risks that have already been identified on the Risk Register, or new risks that have materialized as a result of creating the plan. Analysing risks during planning is iterative and may lead to previous steps of planning being revisited in order to make changes to the plan to lessen or remove the risks.

The final step of planning is to summarise the plan. Known as the Plan Text, it should include an explanation of the assumptions that have been made when creating the plan and the key risks that are associated with the plan.

In addition to the above list, you should always monitor the Business Case as costs will undoubtedly be affected by the work that is planned.

Throughout any project it is important to ensure that risks are identified, understood, tracked and managed. This will help prevent, or at least limit the impact of unforeseen circumstances.

A risk is defined as an uncertain event that will have an effect on the achievement of objectives if it occurs. People often confuse Risks and Issues, so it is important to understand the differences:

Risk is uncertainty, for example something that might happen.

An Issue is a certainty, for example an event that has, or will definitely occur.

This strategy is defined in the 'Initiating a project' process so that there is a clear understanding of the risk management procedures for the remainder of the project. It is then used throughout each stage of the project so that there is a consistent way of managing risk.

A Risk Budget is sum of money that is put aside specifically for funding risk responses. The Risk Budget should be defined during the Initiation Stage and recorded in the Risk Management Strategy. The overall project's risk exposure will help determine the value of the Risk Budget, but it is advisable that provision should also be made for risks that are identified later on in the project.

At the end of each management stage, the Risk Management Strategy should be used to ensure that risks are being managed in line with the defined strategy, as this is a key time for assessing new risks, as well as those already on the Risk Register.

Finally, the Risk Management Strategy is used during the 'Closing a Project' process to ensure that outstanding risks on the Risk Register are handled in the appropriate way when handing over products and completing follow-on action recommendations.

The 'Identify Context' step is used to obtain information about the project in order to understand the specific objectives that are at risk. This information is then used to formulate the Risk Management Strategy during the IP process.

The 'Identify Risks' step is to recognise the specific threats and opportunities that may affect the project's objectives. Each of these needs to be captured on the Risk Register.

Risks can be identified using the following approaches.

The Risk Register is used to capture information on risks and includes details of the probability and impact of the risk, the people assigned to manage the risk, the risk category, and the responses identified to resolve the risk. The information on each risk is updated regularly to record any changes in status of each risk.

The Risk Register should reflect the needs of the project, and can be managed in many different ways. In some projects there may be a need to use separate Risk Registers for the customer and supplier environments - this might be for commercial or technical reasons. There may also be a need for joint Risk Registers that cover a number of technical teams. However the Risk Register is managed, it needs to be clear that the Project Manager is ultimately responsible for identifying and managing risks throughout the project.

Produced in the Initiation Stage, the Risk Register is created in parallel to defining the Risk Management Strategy. It is worth remembering though that some risks might have already been identified during the Start Up. These risks will have been recorded in the Daily Log and would now be transferred onto the Risk Register. At the end of the initiation stage a summary of the risks will be entered into the End Stage Report, and these will be reviewed and approved by the Project Board.

Throughout each stage of the project the Project Manager will review the Risk Register and update it with details of new risks, as well as changes to existing risks. As issues are raised, the Risk Register will need reviewing and updating to reflect any impacts to risks.

At the end of each management stage, a summary of risks is entered into the End Stage Report in preparation for the Project Board approval. At the end of the project, the Risk Register is used to transfer details of any risks to operations and maintenance teams as part of handing over products in the CP process.

Risk Categories

The following categories can be used as a starting point for identifying your organisation's main areas of risk in relation to projects or programmes.

Strategic/commercial risks

• Under-performance to specification
• Management will under-perform against expectations
• Collapse of contractors
• Insolvency of promoter
• Failure of suppliers to meet contractual commitments, this could be in terms of quality, quantity, timescales or their own exposure to risk
• Insufficient capital revenues
• Market fluctuations
• Fraud/theft
• Partnerships failing to deliver the desired outcome
• The situation being non-insurable (or cost of insurance outweighs the benefit)
• Lack of availability of capital investment

• Exchange rate fluctuation
• Interest rate instability
• Inflation
• Shortage of working capital
• Failure to meet projected revenue targets
• Market developments will adversely affect plans

• New or changed legislation may invalidate assumptions upon which the activity is based
• Failure to obtain appropriate approval, e.g. planning, consent
• Unforeseen inclusion of contingent liabilities
• Loss of intellectual property rights
• Failure to achieve satisfactory contractual arrangements
• Unexpected regulatory controls or licensing requirements
• Changes in tax or tariff structure

• Management incompetence
• Inadequate corporate policies
• Inadequate adoption of management practices
• Poor leadership
• Key personnel have inadequate authority to fulfil their roles
• Poor staff selection procedures
• Lack of clarity over roles and responsibilities
• Vested interests creating conflict and compromising the overall aims
• Individual or group interests given unwarranted priority
• Personality clashes
• Indecision or inappropriate decision making
• Lack of operational support
• Inadequate or inaccurate information
• Health and safety constraints

• Change of government policy (national or international), e.g. approach to nationalisation
• Change of government
• War and disorder
• Adverse public opinion/media intervention

• Natural disasters
• Storms, flooding, tempests
• Pollution incidents
• Transport problems, including aircraft/vehicle collisions

• Inadequate design
• Professional negligence
• Human error/incompetence
• Infrastructure failure
• Operation lifetime lower than expected
• Residual value of assets lower than expected
• Increased dismantling/decommissioning costs
• Safety being compromised
• Performance failure
• Residual maintenance problems
• Scope 'creep'
• Unclear expectations
• Breaches in security/information security
• Lack or inadequacy of business continuity

The Evaluate step is concerned with understanding the net effect of all identified risks to assess the overall effect of these on the project risk tolerance. This step gives the Project Manager the foresight to escalate to the Project Board if necessary.

All identified risks need be assessed to establish their importance using the following two headings:

• Probability – How likely is it that the risk will happen?
• Impact – If the risk happens, what will be the consequence to the project?

1. 1 = Low
2. 2 = Medium
3. 3 = High
4. 4 = Very High

You should assess how the risk will affect the progression of the plan. Risks that require immediate action should be dealt with as an Issue (see the 'Change' section of this Techniques Guide).

If you need to put into place actions that will help prevent or reduce the impact or probability of the risk, then this should be planned and carried out, with authorisation sought from the Project Board.

The following Risk Responses should be used.

During this step, a Risk Owner and a Risk Actionee should be assigned to manage the risk. The Risk Owner is responsible for ensuring the responses are carried out, as well as monitoring that the responses are having the desired effect on the risk. The Risk Actionee is responsible for carrying out the specific risk response actions. Quite often these two roles will be carried out by the same person and can be the Project Manager, a team resource, a member of the Project Board, or any other Stakeholder.

The Communicate step is carried out continually to keep both the Project Management Team and external stakeholders informed. When handling such communication, it is important to use the Communication Management Strategy to ensure that the information being provided is in line with what has been agreed in the PID.

Throughout the life of the Project, risks will come and go. Should a risk happen, then the details should be transferred to an Issue Report and the Issue Register. As new risks are identified and other risks diminish, you will need to keep the information on risks up-to-date by updating the Risk Register.

The volatile nature of risks means that the Risk Register should be monitored on a regular basis. Details of risks should be communicated to project team members using the following management reports:

• Checkpoint Reports
• Highlight Reports
• End Stage Reports
• End Project Reports
• Lessons Reports

Consider the numerous other communication methods such as bulletins, notice boards, dashboards, discussion threads, briefings etc. Refer to the Communication Management Strategy for the most appropriate method.

More often than not changes lead to higher costs or more time to deliver the products. Without change control, changes will almost certainly lead to products being delivered that do not meet the customer's criteria. Therefore every project needs a systematic approach to handling change.

To ensure products are safeguarded, a Configuration Management procedure is also required. This will record information on all products, including identifiers and versions, copy holders, historical information and status. It also controls the products by triggering the change control procedure when necessary.

Where it is anticipated that there could be many changes during the project, the Project Board might look to appoint a Change Authority to authorize changes on its behalf. It is worth bearing in mind that the Change Authority role can be allocated to more than one person. For example, the Project Manager could be given authority for changes relating to Work Packages, while somebody in a Project Assurance role could decide on Stage or even Project level changes. The Project Board can also put restrictions on the number of changes to any products, or the value of the changes in any one stage.

A Change Budget is a sum of money that can be used by the Change Authority to fund changes. Details of the Change Authority and Change Budget should be established during the Initiation Stage and approved by the Project Board as part of approving the PID.

There are three types of Change or Issue that will be used by the Project Manager :

A Request for Change will usually come from the Customer or User environment and will affect a change to the agreed acceptance criteria or Product Description (ARQ's and ECN's). A Request for Change could also request a change to the scope of the project too, like an additional product.

An Off-Specification is a product that has failed to meet some criteria during quality activity. It could also be a product that should have been delivered, but has not been. Off-Specifications are typically raised by the Supplier or Team Manager, a Reviewer or Chair of the Quality Review Team, or by Project Assurance.

All other Issues are categorized as general problems or concerns. If an Issue is categorized as a concern (i.e. a potential risk), and is considered formal, then it will be transferred to the Risk Register and analyzed using the Risk Management procedure. All other Issues will be handled using the Issue and Change Control Procedure.

Issues can originate from anybody - the Project Board, the Project Manager, teams, or anybody else from any area within the authority or outside the authority. Issues may relate to anything about the project, and can be of any nature including

• Questions or concerns
• System Errors / Failures
• Overspends or Time overruns
• Good ideas
• Resource issues, including people resource
• Change or collapse of contracts

The standard approach for dealing with Issues is outlined below:

• a. An Issue sent to the Project Manager, who logs the details of the Issue in the Daily Log and then acknowledges the receipt of the Issue.
• b. The Project Manager assesses the issue and establishes what impact, if any, it will have on the stage and the project. Technical, User and Business impacts should be assessed.
• c. If the Issue can be handled informally, the Daily Log is used to record events based around the Issue. Any Issues that are to be handled formally should be recorded in the Issue Register.
• d. If you can process the issue within the agreed costs and timescales, then you should carry out the necessary actions. In some cases it may be necessary to seek advice from the Project Board if you do not feel comfortable with making a decision on the issue yourself.
• e. If at any time you require additional resources over and above what has already been agreed (i.e. money, people, equipment) then you MUST secure authorisation for this from the Project Board prior to proceeding.
• f. If the Issue is requesting a change to the agreed end product, then you MUST consult the Project Board (or designated Change Authority) for advice and authorisation.
• g. When the Issue has been either implemented, or a decision been made not to proceed with the Issue, then the originator should be updated on events, the Issue Register (or Daily Log) should be updated, and the Issue closed.

An Issue Report is created to formalise information about an Issue that needs to be managed formally. It will be created initially to record known information, and then updated after impact analysis has been carried out on the Issue to include details of the effect the Issue has on stage and project costs, time and risks, and impacts on other products. It will also contain information on the recommended actions required to resolve the Issue, and the decision that has been made.

The Issue Register provides a summary of all formal Issues that are being managed during the Project. Information from the Issue Reports will be used to generate a register that provides information on all Issues 'at a glance'. This helps the Project Manager to easily monitor all Issues.

The Configuration Management Strategy is created by the Project Manager during the Initiation Stage and defines the project's procedures for Configuration Management, Issues and Change. It will also define the responsibilities for these procedures, as well as reporting mechanisms, tools and techniques.

The Configuration Management Strategy forms part of the Project Initiation Documentation, and is therefore approved in DP by the Project Board. It is reviewed throughout the CS process when the Project Manager has issues to deal with. It will also be used when creating Work Packages so that the procedures can be written into these. The Project Manager will also need to refer to the procedures during the CP process when preparing for handing over products to the operations and maintenance teams.

Configuration Item Records (or C.I.R.s) are created for each product that is identified. They provide a full set of information for each product including the product names and version, who owns the product and who holds copies, which is important when needing to ensure that everyone is referring to the correct version.

A Product Status Account can be used to summarize the information that is held in the Configuration Item Records. By managing the information this way the Project Manager will be able to produce a report on a set of products, whether it be for the entire Project, a particular Stage, or for a set of products being delivered by a specific team.

Configuration Management therefore is basically a record of all products produced within the Project.  This includes details of the specialist products and Management Products. The five basic functions of Configuration Management are:

• Planning the level of configuration management that will be applied
• Identifying the products and giving these unique identifiers
• Controlling the products to ensure that nothing changes without triggering the Change Control steps if necessary
• Keeping all historical information of the products and their versions (known as "status accounting")
• Verifying that information kept in the Configuration Management records is consistent with the product of the project

Decisions need to be made during project initiation to:

• Establish the information required for each product
• type of product
• version number
• who "owns" the product
• dates
• Establish how copies of products are handled and issued
• "signed for" when issued
• security requirements
• return requirements
• Identify the links and reporting processes between yourself and those maintaining the system.
• who can access products
• can teams return products directly? (By-passing the Project Manager)
• how is the Project Manager informed of changes in status of products?
• reports issued for each stage to the Project Manager
• State the level of audits required to ensure the Configuration Management system is up-to-date
• How will this interface with the Filing Structure?
• Define the links to the Change Control Technique
• Ascertain who will "own" the Configuration Management system after the Project has closed and the products are supported in operational life.

• Identifying the individual items that are to be managed. These are referred to as Configuration Items (CIs)
• Recording, monitoring and reporting on the current status of each Configuration Item as it progresses through its own development lifecycle
• Filing all documentation produced during the project life of the CIs
• Distributing and recording copy holders of all project documentation for all CIs
• Managing Issues raised during the project
• Managing change to all CIs, from receipt of an Issue, through assessment of the impact of proposed changes, release of both the documentation and the Product itself

• Configuration Items must be able to be created, amended and deleted
• Configuration Items must be capable of being uniquely identified
• the owner of each Configuration Item must be identified
• the owner of a Configuration Item must be able to be changed, without necessarily changing the Configuration Item itself
• baselines must be capable of being established
• configuration audits must be able to be performed
• it should be possible to restore a Product (or related group of Products) to its state as at a previous baseline, either temporarily or permanently
• the placing of a Configuration Item in the system library must be documented
• Impact Analysis must be able to be carried out to help assess the ramifications involved in changing one or more configuration item
• Configuration Items which are of interest to more than one project must be able to be held centrally.

Overall responsibility for Configuration Management on individual projects will be exercised by each Project Manager.

PRINCE2®; describes configuration management as “Product Control”. This is because it is the Configuration Management system which ensures that all products which have been approved by the Performance Board, or have been signed off at Quality Review will become baselined by changing the status to “Approved”. This effectively protects those products from changes by ensuring that the formal change control method is triggered when changes are required.

The suggested documentation management or filing structure is based on three different types of file:

• The Project File
• The Stage File(s)
• The Quality File

• Customer’s Quality Expectations
• Acceptance Criteria
• Quality Management Strategy: the original and any subsequent versions of the Quality Management Strategy should be filed here
• Configuration Management Strategy
• Configuration records: there should be minimally a Product Description for every product in the project. As more information is created, a full configuration record for each product can be produced
• Issues: this should have the Issue Register, at the front to facilitate sequential numbering and to record the status and allocation. The master copies of each Issue should be stored in sequence.
• Quality inspection products: it is useful to head this section with the Quality Register, giving a number to each quality check carried out, the type of quality check or test (for example a quality review), the product and date. This is a quick reference to see or show how many checks have been held in a particular stage and a guide to where the appropriate documentation can be found

• invitations
• action lists
• result notifications

You should seek assistance from the Project Management Office for guidance on this.

Controls such as formality of meetings and reporting for the project should be established during the project initiation stage. The formality and type of controls to be used should be discussed with the Project Board. When deciding on the types and levels of controls to be used on the project, be sure to consider the costs of high formal controls against the risks of lower level informal controls. The result may be a balance which can be decided and approved by the Project Board.

As part of the 'Controlling a Stage' process the Project Manager will regularly review the progress of the stage and update the Stage Plan with actual progress achieved. Information from a number of Management Products is used for reviewing progress. When reviewing progress, the Project Manager will look at what has been achieved to date, and look at how this affects the remainder of the stage and project.

The Project Board will also require a statement of actual cost and duration against the approved plan, and any actual or proposed change in the organisation. A vital element is an up-dated Business Case and Risk Analysis. This document must be kept short and to the point. The up-dated Project Plan and Management Stage Plan must be available to the Project Board and, if deemed useful, a Management Stage Plan for the next stage of the work must accompany the Report.

A key aspect of progress monitoring and control is knowing when things are still on target; within plan; within tolerance.

Tolerance is the permissible deviation of an approved plan, without needing to report that deviation to the higher level. This is commonly known as "management-by-exception". The Project Manager should be in complete control of the project - enabling the Project Board to take a "back seat".

All projects levels are subject to Tolerance. Tolerance of +/- a percentage should be applied to all projects. The Project Board may vary tolerances and add additional tolerances, perhaps on specific packages of work or elements. Practically anything that can be measured can have Tolerance applied to it (e.g. benefits, risks, quality, scope, time and cost). All Level 2 projects and some Level 1 projects will have additional Tolerances applied to them in order to give the Project Board confidence in allowing the Project Manager to get on with managing the project.

For example, if a plan is approved with a predicted duration of 20 weeks and at an estimated cost of £50,000, using the standard tolerance of +5% (1 week) duration and +5% on cost, then the Project Manager can continue with the project without reference back to the Project Board, provided the predicted duration does not stretch further than 11 weeks, and the predicted cost does not exceed £52,500 (£50,000 + 5%). Any deviation beyond these tolerance figures must be reported to the Project Board immediately, using an Exception Report.

The Project Board may meet to consider an Exception Report, but a formal meeting is not always necessary. More likely, the Project Board will review the situation informally, by telephone or e-mail, and then give its response.

The Work Package is used to delegate work from the Project Manager in the CS process, to individual team members or Team Managers operating in the MP process. The Work Package could take the form of a legally binding contract with an external supplier, or could take the form of a discussion or briefing; especially true where the creation or modification of a Product is being carried out by internal staff from the customer's own organisation. The way in which it is authorized to the teams will be in keeping with the formality of the Work Package.

The Work Package will contain details of the work to be completed, including timescales and costs, quality procedures, reporting requirements and how problems should be handled. It is advisable to include a copy of all Product Descriptions which includes the Quality Criteria that relate to the Work Package.

The Team Manager will use the Team Plan, Issue Register, Risk Register and Quality Register to create the Checkpoint Report. It is also useful to have a checkpoint meeting with the teams prior to sending the Checkpoint Report so that any other useful information can be included.

On receiving the Checkpoint Report, the Project Manager will update the Stage Plan as part of Reviewing Progress.

accept (risk response)

A risk response to a threat where a conscious and deliberate decision is taken to retain the threat, having discerned that it is more economical to do so than to attempt a risk response action. The threat should continue to be monitored to ensure that it remains tolerable.

The formal act of acknowledging that the project has met agreed acceptance criteriaand thereby met the requirements of its stakeholders.

A prioritized list of criteria that the project product must meet before the customer will accept it, i.e. measurable definitions of the attributes required for the set of products to be acceptable to key stakeholders.

A process, function or task that occurs over time, has recognizable results and is managed. It is usually defined as part of a process or plan.

Advice and guidance passed from the Project Board to the Project Manager.

Principally, software development methods that apply the project approach of using short time-boxed iterations where products are incrementally developed. PRINCE2 is compatible with agile principles.

The formal confirmation that a product is complete and meets its requirements (less any concessions) as defined by its Product Description.

The person or group (e.g. a Project Board) who is identified as qualified and authorized to approve a (management or specialist) product as being complete and fit for purpose.

A statement that is taken as being true for the purposes of planning, but which could change later. An assumption is made where some facts are not yet known or decided, and is usually reserved for matters of such significance that, if they change or turn out not to be true, there will need to be considerable replanning.

All the systematic actions necessary to provide confidence that the target (system, process, organization, programme, project, outcome, benefit, capability, product output, deliverable) is appropriate. Appropriateness might be defined subjectively or objectively in different circumstances. The implication is that assurance will have a level of independence from that which is being assured. See also 'Project Assurance' and 'quality assurance'.

The right to allocate resources and make decisions (applies to project, stage and team levels).

The point at which an authority is granted.

A risk response to a threat where the threat either can no longer have an impact or can no longer happen.

Reference levels against which an entity is monitored and controlled.

A type of management product that defines aspects of the project and, once approved, is subject to change control.

The measurable improvement resulting from an outcome perceived as an advantage by one or more stakeholders.

A plan that defines how and when a measurement of the achievement of the project's benefits can be made. If the project is being managed within a programme, this information may be created and maintained at the programme level.

The permissible deviation in the expected benefit that is allowed before the deviation needs to be escalated to the next level of management. Benefits tolerance is documented in the Business Case. See also 'tolerance'.

The justification for an organizational activity (project), which typically contains costs, benefits, risks and timescales, and against which continuing viability is tested.

A corporate coordinating function for portfolios, programmes and projects providing standards, consistency of methods and processes, knowledge management, assurance and training.

A person or group to which the Project Board may delegate responsibility for the consideration of requests for change or offspecifications. The Change Authority may be given a change budget and can approve changes within that budget.

The money allocated to the Change Authority available to be spent on authorized requests for change.

The procedure that ensures that all changes that may affect the project's agreed objectives are identified, assessed and either approved, rejected or deferred.

A team-level, time-driven review of progress.

A progress report of the information gathered at a checkpoint, which is given by a team to the Project Manager and which provides reporting data as defined in the Work Package.

Advice from the Project Board to inform all stakeholders and the host sites that the project resources can be disbanded and support services, such as space, equipment and access, demobilized. It should indicate a closure date for costs to be charged to the project.

A recommendation prepared by the Project Manager for the Project Board to send as a project closure notification when the board is satisfied that the project can be closed.

A description of the means and frequency of communication between the project and the project's stakeholders.

An off-specification that is accepted by the Project Board without corrective action.

An entity that is subject to configuration management. The entity may be a component of a product, a product, or a set of products in a release.

A record that describes the status, version and variant of a configuration item, and any details of important relationships between them.

Technical and administrative activities concerned with the creation, maintenance and controlled change of configuration throughout the life of a product.

A description of how and by whom the project's products will be controlled and protected.

The set of processes, tools and databases that are used to manage configuration data. Typically, a project will use the configuration management system of either the customer or supplier organization.

The restrictions or limitations that the project is bound by.

Something that is held in reserve typically to handle time and cost variances, or risks. PRINCE2 does not advocate the use of contingency because estimating variances are managed by setting tolerances, and risks are managed through appropriate risk responses (including the fallback response that is contingent on the risk occurring).

These are over-arching standards that the project must adhere to. They will influence the four project strategies (Communication Management Strategy, Configuration Management Strategy, Quality Management Strategy and Risk Management Strategy) and the project controls.

A set of actions to resolve a threat to a plan's tolerances or a defect in a product.

The permissible deviation in a plan's cost that is allowed before the deviation needs to be escalated to the next level of management. Cost tolerance is documented in the respective plan. See also 'tolerance'.

The person or group who commissioned the work and will benefit from the end results.

A statement about the quality expected from the project product, captured in the Project Product Description.

Used to record problems/concerns that can be handled by the Project Manager informally.

See 'output'.

The relationship between products or activities. For example, the development of Product C cannot start until Products A and B have been completed. Dependencies can be internal or external. Internal dependencies are those under the control of the Project Manager. External dependencies are those outside the control of the Project Manager - for example, the delivery of a product required by this project from another project.

An outcome that is perceived as negative by one or more stakeholders. It is an actual consequence of an activity whereas, by definition, a risk has some uncertainty about whether it will materialize.

An agile project delivery framework developed and owned by the DSDM consortium. Atern uses a time-boxed and iterative approach to product development and is compatible with PRINCE2.

What an organization needs to do to adopt PRINCE2 as its corporate project management method. See also, in contrast, 'tailoring', which defines what a project needs to do to apply the method to a specific project environment.

A report given by the Project Manager to the Project Board, that confirms the handover of all products and provides an updated Business Case and an assessment of how well the project has done against the original Project Initiation Documentation.

The review by the Project Board and Project Manager of the End Stage Report to decide whether to approve the next Stage Plan. According to the size and criticality of the project, the review may be formal or informal. The authority to proceed should be documented as a formal record.

A report given by the Project Manager to the Project Board at the end of each management stage of the project. This provides information about the project performance during the stage and the project status at stage end.

A risk response to an opportunity where proactive actions are taken to enhance both the probability of the event occurring and the impact of the event should it occur.

A control that takes place when a specific event occurs. This could be, for example, the end of a stage, the completion of the Project Initiation Documentation, or the creation of an Exception Report. It could also include organizational events that may affect the project, such as the end of the financial year. exception A situation where it can be forecast that

A situation where it can be forecast that there will be a deviation beyond the tolerance levels agreed between Project Manager and Project Board (or between Project Board and corporate or programme management).

This is a review by the Project Board to approve (or reject) an Exception Plan.

This is a plan that often follows an Exception Report. For a Stage Plan exception, it covers the period from the present to the end of the current stage. If the exception were at project level, the Project Plan would be replaced.

A description of the exception situation, its impact, options, recommendation and impact of the recommendation. This report is prepared by the Project Manager for the Project Board.

The single individual with overall responsibility for ensuring that a project meets its objectives and delivers the projected benefits. This individual should ensure that the project maintains its business focus, that it has clear authority, and that the work, including risks, is actively managed. The Executive is the chair of the Project Board. He or she represents the customer and is responsible for the Business Case.

A risk response to an opportunity by seizing the opportunity to ensure that it will happen and that the impact will be realized.

A risk response to a threat by putting in place a fallback plan for the actions that will be taken to reduce the impact of the threat should the risk occur.

Recommended actions related to unfinished work, ongoing issues and risks, and any other activities needed to take a product to the next phase of its life. These are summarized and included in the End Stage Report (for phased handover) and End Project Report.

The ongoing activity of maintaining a sound system of internal control by which the directors and officers of an organization ensure that effective management systems, including financial monitoring and control systems, have been put in place to protect assets, earning capacity and the reputation of the organization.

Those areas of corporate governance that are specifically related to project activities. Effective governance of project management ensures that an organization's project portfolio is aligned to the organization's objectives, is delivered efficiently and is sustainable.

The transfer of ownership of a set of products to the respective user(s). The set of products is known as a release. There may be more than one handover in the life of a project (phased delivery). The final handover takes place in the Closing a Project process.

A time-driven report from the Project Manager to the Project Board on stage progress.

A site where project work is being undertaken (for example, an office or construction site).

The result of a particular threat or opportunity actually occurring, or the anticipation of such a result.

The exposure arising from a specific risk before any action has been taken to manage it.

The period from when the Project Board authorizes initiation to when they authorize the project (or decide not to go ahead with the project). The detailed planning and establishment of the project management infrastructure is covered by the Initiating a Project process.

A relevant event that has happened, was not planned, and requires management action. It can be any concern, query, request for change, suggestion or off-specification raised during a project. Project issues can be about anything to do with the project.

A register used to capture and maintain information on all of the issues that are being managed formally. The Issue Register should be monitored by the Project Manager on a regular basis.

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

An informal repository for lessons that apply to this project or future projects.

A report that documents any lessons that can be usefully applied to other projects. The purpose of the report is to provoke action so that the positive lessons from a project become embedded in the organization's way of working and that the organization is able to avoid the negative lessons on future projects.

Informal repositories managed by the Project Manager that do not require any agreement by the Project Board on their format and composition. PRINCE2 has two logs: the Daily Log and the Lessons Log.

A product that will be required as part of managing the project, and establishing and maintaining quality (for example, Highlight Report, End Stage Report etc.). The management products stay constant, whatever the type of project, and can be used as described, or with any relevant modifications, for all projects. There are three types of management product: baselines, records and reports.

The section of a project that the Project Manager is managing on behalf of the Project Board at any one time, at the end of which the Project Board will wish to review progress to date, the state of the Project Plan, the Business Case and risks, and the next Stage Plan in order to decide whether to continue with the project.

A significant event in a plan's schedule, such as completion of key Work Packages, a technical stage, or a management stage.

Something that should be provided by the project, but currently is not (or is forecast not to be) provided. This might be a missing product or a product not meeting its specifications. It is one type of issue.

A specific type of acceptance by the person or group who will support the product once it is handed over into the operational environment.

The result of change, normally affecting real-world behaviour and/or circumstances. Outcomes are desired when a change is conceived. They are achieved as a result of the activities undertaken to effect the change.

A specialist product that is handed over to a user(s). Note that management products are not outputs but are created solely for the purpose of managing the project.

A plan's goals for time, cost, quality, scope, benefits and risk.

A detailed proposal for doing or achieving something which specifies the what, when, how and by whom. In PRINCE2 there are only the following types of plan: Project Plan, Stage Plan, Team Plan, Exception Plan and Benefits Review Plan.

The PRINCE2 activity to close a project.

The period of time for which it is possible to accurately plan.

All the programmes and stand-alone projects being undertaken by an organization, a group of organizations, or an organizational unit.

The PRINCE2 activity to close a project before its planned closure. The Project Manager must ensure that work in progress is not simply abandoned, but that the project salvages any value created to date, and checks that any gaps left by the cancellation of the project are raised to corporate or programme management.

Any fundamental aspects that must be in place, and remain in place, for a plan to succeed.

A method that supports some selected aspects of project management. The acronym stands for PRojects IN a Controlled Environment.

The guiding obligations for good project management practice that form the basis of a project being managed using PRINCE2.

A project that applies the PRINCE2 principles.

This is the evaluated likelihood of a particular threat or opportunity actually happening, including a consideration of the frequency with which this may arise.

A type of issue (other than a request for change or off-specification) that the Project Manager needs to resolve or escalate.

A series of actions for a particular aspect of project management established specifically for the project - for example, a risk management procedure.

A structured set of activities designed to accomplish a specific objective. A process takes one or more defined inputs and turns them into defined outputs.

The person or group responsible for developing a product.

An input or output, whether tangible or intangible, that can be described in advance, created and tested. PRINCE2 has two types of products - management products and specialist products.

A hierarchy of all the products to be produced during a plan.

A list of the major products of a plan, plus key dates in their delivery.

A description of a product's purpose, composition, derivation and quality criteria. It is produced at planning time, as soon as possible after the need for the product is identified.

A diagram showing the sequence of production and interdependencies of the products listed in a product breakdown structure.

A report on the status of products. The required products can be specified by identifier or the part of the project in which they were developed.

A technique leading to a comprehensive plan based on the creation and delivery of required outputs. The technique considers prerequisite products, quality requirements and the dependencies between products.

A temporary flexible organization structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organization's strategic objectives. A programme is likely to have a life that spans several years.

A temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case.

A description of the way in which the work of the project is to be approached. For example, are we building a product from scratch or buying in a product that already exists?

The Project Board's responsibilities to assure itself that the project is being conducted correctly. The Project Board members each have a specific area of focus for Project Assurance, namely business assurance for the Executive, user assurance for the Senior User(s), and supplier assurance for the Senior Supplier(s).

Advice from the Project Board to inform all stakeholders and the host sites that the project has been authorized and to request any necessary logistical support (e.g. communication facilities, equipment and any project support) sufficient for the duration of the project.

Statement that describes the purpose, cost, time and performance requirements, and constraints for a project. It is created pre-project during the Starting up a Project process and is used during the Initiating a Project process to create the Project Initiation Documentation and its components. It is superseded by the Project Initiation Documentation and not maintained.

A logical set of documents that brings together the key information needed to start the project on a sound basis and that conveys the information to all concerned with the project.

Advice from the Project Board to inform all stakeholders and the host sites that the project is being initiated and to request any necessary logistical support (e.g. communication facilities, equipment and any project support) sufficient for the initiation stage.

The period from the start-up of a project to the acceptance of the project product.

The planning, delegating, monitoring and control of all aspects of the project, and the motivation of those involved, to achieve the project objectives within the expected performance targets for time, cost, quality, scope, benefits and risks.

The entire management structure of the Project Board, and Project Manager, plus any Team Manager, Project Assurance and Project Support roles.

An organization chart showing the people assigned to the project management team roles to be used, and their delegation and reporting relationships.

The person given the authority and responsibility to manage the project on a day-to-day basis to deliver the required products within the constraints agreed with the Project Board.

An external product generated by the authority commissioning the project that forms the trigger for Starting up a Project.

A temporary office set up to support the delivery of a specific change initiative being delivered as a project. If used, the project office undertakes the responsibility of the Project Support role.

A high-level plan showing the major products of the project, when they will be delivered and at what cost. An initial Project Plan is presented as part of the Project Initiation Documentation. This is revised as information on actual progress appears. It is a major control document for the Project Board to measure actual progress against expectations.

What the project must deliver in order to gain acceptance.

A special type of Product Description used to gain agreement from the user on the project's scope and requirements, to define the customer's quality expectations, and to define the acceptance criteria for the project.

An administrative role in the project management team. Project Support can be in the form of advice and help with project management tools, guidance, administrative services such as filing, and the collection of actual data.

The time factor of risk, i.e. when the risk may occur. The impact of a risk may vary in severity depending on when the risk occurs.

The totality of features and inherent or assigned characteristics of a product, person, process, service and/or system that bears on its ability to show that it meets expectations or satisfies stated needs, requirements or specifications.

An independent check that products will be fit for purpose or meet requirements.

The process of monitoring specific project results to determine whether they comply with relevant standards and of identifying ways to eliminate causes of unsatisfactory performance.

A description of the quality specification that the product must meet, and the quality measurements that will be applied by those inspecting the finished product.

A systematic, structured assessment of a product carried out by two or more carefully selected people (the review team) in a planned, documented and organized fashion.

The coordinated activities to direct and control an organization with regard to quality.

A strategy defining the quality techniques and standards to be applied, and the various responsibilities for achieving the required quality levels, during a project.

The complete set of quality standards, procedures and responsibilities for a site or organization. In the project context, 'sites' and 'organizations' should be interpreted as the permanent or semi-permanent organization(s) sponsoring the project work, i.e. they are 'external' to the project's temporary organization. A programme, for instance, can be regarded as a semi-permanent organization that sponsors projects - and it may have a documented quality management system.

Evidence kept to demonstrate that the required quality assurance and quality control activities have been carried out.

A register containing summary details of all planned and completed quality activities. The Quality Register is used by the Project Manager and Project Assurance as part of reviewing progress.

See 'quality inspection'.

A quality inspection technique with defined roles and a specific structure. It is designed to assess whether a product that takes the form of a document (or similar, e.g. a presentation) is complete, adheres to standards and meets the quality criteria agreed for it in the relevant Product Description. The participants are drawn from those with the necessary competence to evaluate its fitness for purpose.

The tolerance identified for a product for a quality criterion defining an acceptable range of values. Quality tolerance is documented in the Project Product Description (for the project-level quality tolerance) and in the Product Description for each product to be delivered.

Dynamic management products that maintain information regarding project progress.

A response to a risk where proactive actions are taken to reduce the probability of the event occurring by performing some form of control, and/or to reduce the impact of the event should it occur.

Formal repositories managed by the Project Manager that require agreement by the Project Board on their format, composition and use. PRINCE2 has three registers: Issue Register, Risk Register and Quality Register.

A response to a risk (opportunity) where a conscious and deliberate decision is taken not to exploit or enhance an opportunity, having discerned that it is more economical to do so than to attempt a risk response action. The opportunity should continue to be monitored.

The set of products in a handover. The contents of a release are managed, tested and deployed as a single entity. See also 'handover'.

Management products providing a snapshot of the status of certain aspects of the project.

A proposal for a change to a baseline. It is a type of issue.

The risk remaining after the risk response has been applied.

The person or group commissioning the project (typically corporate or programme management) who has the authority to commit resources and funds on behalf of the commissioning organization.

A person or group independent of the producer who assesses whether a product meets its requirements as defined in its Product Description.

An uncertain event or set of events that, should it occur, will have an effect on the achievement of objectives. A risk is measured by a combination of the probability of a perceived threat or opportunity occurring, and the magnitude of its impact on objectives.

A nominated owner of an action to address a risk. Some actions may not be within the remit of the Risk Owner to control explicitly; in that situation there should be a nominated owner of the action to address the risk. He or she will need to keep the risk owner apprised of the situation.

An organization's unique attitude towards risk taking that in turn dictates the amount of risk that it considers is acceptable.

The estimation of probability and impact of an individual risk, taking into account predetermined standards, target risk levels, interdependencies and other relevant factors.

The process of understanding the net effect of the identified threats and opportunities on an activity when aggregated together.

The systematic application of principles, approaches and processes to the tasks of identifying and assessing risks, and then planning and implementing risk responses.

A strategy describing the goals of applying risk management, as well as the procedure that will be adopted, roles and responsibilities, risk tolerances, the timing of risk management interventions, the tools and techniques that will be used, and the reporting requirements.

A named individual who is responsible for the management, monitoring and control of all aspects of a particular risk assigned to them, including the implementation of the selected responses to address the threats or to maximize the opportunities.

A description of the types of risk that are faced by an organization and its exposure to those risks.

A record of identified risks relating to an initiative, including their status and history.

Actions that may be taken to bring a situation to a level where exposure to risk is acceptable to the organization. These responses fall into a number of risk response categories.

A category of risk response. For threats, the individual risk response category can be avoid, reduce, transfer, accept or share. For opportunities, the individual risk response category can be exploit, enhance, reject or share.

The threshold levels of risk exposure which, when exceeded, will trigger an Exception Report to bring the situation to the attention of the Project Board. Risk tolerances could include limits on the plan's aggregated risks (e.g. cost of aggregated threats to remain less than 10% of the plan's budget), or limits on any individual threat (e.g. any threat to operational service). Risk tolerance is documented in the Risk Management Strategy.

A line drawn on the summary risk profile. Risks that appear above this line cannot be accepted (lived with) without referring them to a higher authority. For a project, the Project Manager would refer these risks to the Project Board.

A description of the set of responsibilities specific to a role.

Graphical representation of a plan (for example, a Gantt chart), typically describing a sequence of tasks, together with resource allocations, which collectively deliver the plan. In PRINCE2, project activities should only be documented in the schedules associated with a Project Plan, Stage Plan or Team Plan. Actions that are allocated from day-to-day management may be documented in the relevant project log (i.e. Risk Register, Daily Log, Issue Register, Quality Register) if they do not require significant activity.

For a plan, the sum total of its products and the extent of their requirements. It is described by the product breakdown structure for the plan and associated Product Descriptions.

The permissible deviation in a plan's scope that is allowed before the deviation needs to be escalated to the next level of management. Scope tolerance is documented in the respective plan in the form of a note or reference to the product breakdown structure for that plan. See 'tolerance'.

A UK government term for the individual responsible for ensuring that a project or programme of change meets its objectives and delivers the projected benefits. The person should be the owner of the overall business change that is being supported by the project. The Senior Responsible Owner (SRO) should ensure that the change maintains its business focus, that it has clear authority, and that the context, including risks, is actively managed. This individual must be senior and must take personal responsibility for successful delivery of the project. The SRO should be recognized as the owner throughout the organization. The SRO appoints the project's Executive (or in some cases may elect to be the Executive).

The Project Board role that provides knowledge and experience of the main discipline(s) involved in the production of the project's deliverable(s). The Senior Supplier represents the supplier interests within the project and provides supplier resources.

The Project Board role accountable for ensuring that user needs are specified correctly and that the solution meets those needs.

A risk response to either a threat or an opportunity through the application of a pain/gain formula: both parties share the gain (within pre-agreed limits) if the cost is less than the cost plan; and both share the pain (again within pre-agreed limits) if the cost plan is exceeded.

A product whose development is the subject of the plan. The specialist products are specific to an individual project (for example, an advertising campaign, a car park ticketing system, foundations for a building, a new business process etc.) Also known as a deliverable or output.

The main driving force behind a programme or project. PRINCE2 does not define a role for the sponsor, but the sponsor is most likely to be the Executive on the Project Board, or the person who has appointed the Executive.

See 'management stage' or 'technical stage'.

A detailed plan used as the basis for project management control throughout a stage.

Any individual, group or organization that can affect, be affected by, or perceive itself to be affected by, an initiative (programme, project, activity, risk).

The pre-project activities undertaken by the Executive and the Project Manager to produce the outline Business Case, Project Brief and Initiation Stage Plan.

An approach or line to take, designed to achieve a long-term aim. Strategies can exist at different levels - at the corporate, programme and project level. At the project level, PRINCE2 defines four strategies: Communication Management Strategy, Configuration Management Strategy, Quality Management Strategy and Risk Management Strategy.

The person, group or groups responsible for the supply of the project's specialist products.

The appropriate use of PRINCE2 on any given project, ensuring that there is the correct amount of planning, control, governance and use of the processes and themes (whereas the adoption of PRINCE2 across an organization is known as 'embedding').

The person responsible for the production of those products allocated by the Project Manager (as defined in a Work Package) to an appropriate quality, timescale and at a cost acceptable to the Project Board. This role reports to, and takes direction from, the Project Manager. If a Team Manager is not assigned, then the Project Manager undertakes the responsibilities of the Team Manager role.

An optional level of plan used as the basis for team management control when executing Work Packages.

A method of grouping work together by the set of techniques used, or the products created. This results in stages covering elements such as design, build and implementation. Such stages are technical stages and are a separate concept from management stages.

An aspect of project management that needs to be continually addressed, and that requires specific treatment for the PRINCE2 processes to be effective.

The permissible deviation in a plan's time that is allowed before the deviation needs to be escalated to the next level of management. Time tolerance is documented in the respective plan. See also 'tolerance'.

A management control that is periodic in nature, to enable the next higher authority to monitor progress - e.g. a control that takes place every two weeks. PRINCE2 offers two key time-driven progress reports: Checkpoint Report and Highlight Report.

The permissible deviation above and below a plan's target for time and cost without escalating the deviation to the next level of management. There may also be tolerance levels for quality, scope, benefit and risk. Tolerance is applied at project, stage and team levels.

A programme management term describing a group of projects structured around distinct step changes in capability and benefit delivery.

A response to a threat where a third party takes on responsibility for some of the financial impact of the threat (for example, through insurance or by means of appropriate clauses in a contract).

An event or decision that triggers a PRINCE2 process.

A specific type of acceptance by the person or group who will use the product once it is handed over into the operational environment.

The person or group who will use one or more of the project's products.

A variation on a baselined product. For example, an operations manual may have an English variant and a Spanish variant.

A specific baseline of a product. Versions typically use naming conventions that enable the sequence or date of the baseline to be identified. For example, Project Plan version 2 is the baseline after Project Plan version 1.

A development approach that is linear and sequential with distinct goals for each phase of development. Once a phase of development is completed, the development proceeds to the next phase and earlier phases are not revisited (hence the analogy that water flowing down a mountain cannot go back).

The set of information relevant to the creation of one or more products. It will contain a description of the work, the Product Description(s), details of any constraints on production, and confirmation of the agreement between the Project Manager and the person or Team Manager who is to implement the Work Package that the work can be done within the constraints.

To help you to provide input to the guidance, you should create and maintain a Lessons Log. This log should be used to record events, actions and techniques that assisted or enhanced the project; and those that did not. At project closure, lessons should be disseminated and passed to the Project Management Office.

General feedback on the Project Management Guides should be sent to the Project Management Office.

Lessons Reports should be available centrally in order to benefit future projects. Electronic project files available to all PM's and Project Boards would allow continuous improvement on project performance.