PRINCE2 practices

Introduction

The seven practices of PRINCE2 form a central part of the PRINCE2 guidance. This article will explore each of the seven practices (formerly known as themes) of PRINCE2.

What are the 7 practices of PRINCE2?

The 7 practices of PRINCE2 are key aspects of project management that must be addressed throughout the project life cycle^[1]. The practices describe how the 7 PRINCE2 principles should be applied on a project.

The 7 practices are:

1. Business case
2. Organization
3. Quality
4. Plans
5. Risk
6. Change
7. Progress.

The 7 practices form a large part of PRINCE2 training courses. For the PRINCE2 exams, PRINCE2 Foundation students are required to learn the purpose and objectives of the 7 practices and the purpose of the related management products. PRINCE2 Practitioner students are required to apply and tailor relevant aspects of the 7 practices in context.

The practices are also one of the main components (along with the processes) which should be tailored to the project environment.

1. Business case

The primary objective of the business case theme is to implement mechanisms that aid key decision-makers in determining whether a project is, and continues to be, a valuable investment. It embodies the ‘continued business justification’ principle. A business case guides the project’s decision-making process, and it is evaluated stage-by-stage to decide on the viability of ongoing investment in the project.

The customer funding the project and the supplier serving the project each have their own business case. Each is constructed to validate its respective participation in the project. Note: PRINCE2 operates within a customer-supplier framework, wherein the customer defines the project’s required products, finances the project, and expects certain benefits in return. The supplier – any individual, team, or organization – delivers these products to the customer.

If the supplier is an internal department of the customer organization, then both customer and supplier rely on a common business case.

A business case serves as both a theme and a management product, and the executive is responsible for it. The executive ensures an acceptable business case exists; otherwise, the project manager is instructed to terminate the project. Opting to cease spending resources on a project is more desirable than persisting with a project that no longer offers value.

The initial (outline) version of the business case is supplied by the executive during the starting up a project process, although it may sometimes come from corporate/programme management as part of the project brief. The outline version is then expanded with additional details during the project’s initiation stage.

Each project is designed to produce one or more ‘specialist’ products (referred to as outputs), which are then utilized by the customer organization either during and/or after the project closes. The implementation of these products results in a change (outcome) in their usual (business-as-usual) operations. The quantifiable improvements which result to the customer organization are recognized as benefits. For instance, a company investing in a new business information system establishes a project. The project’s output is the new IT system. The outcome is improved operational efficiency among staff. The benefit is a reduction in the company’s salary costs.

The senior user role specifies the project’s benefits and ensures their realisation during and after the project’s closure. Consequently, individuals assuming the senior user role are derived from those areas of the customer organization that are most significantly affected by the outcomes.

The method for measurement benefits, the timing, and the responsible parties are documented in a benefits management approach. This is updated as benefits materialize, which typically occurs after the project’s conclusion for most projects.

This is because, at the project’s end, the specialist products are handed over to the users and the operational or support teams. These teams then utilize the products within the business-as-usual framework, realizing the anticipated benefits.

For many commercial organizations, the business justification for projects is financial, i.e., whether the project will yield a return on its financial investment. However, PRINCE2 asserts that business justification can be evaluated through other means as well.

Take, for example, a project to fit a residential apartment complex with a fire sprinkler system. Such a project would offer clear benefits (saving lives in case of fire) but may not product a financial return on investment. The decision to fund such a project should, therefore, factor in the broader societal benefits of safeguarding its residents.

Minimum requirements for this theme include:

1. Every project must create and maintain a business justification in the form of a business case.
2. The business case must be assessed and updated throughout the project’s duration.
3. Management actions are devised to ensure the anticipated outcomes are achieved, and the benefits are realised.

2. Organization

The organization theme aims to establish a project management team structure, outlining the accountabilities and responsibilities within the project.

PRINCE2 operates within a ‘customer/supplier environment’, where the customer organization outlines the desired result (the specialist products), funds the project, and anticipates that the project will yield sufficient future benefits to justify the investment. The supplier – be it a person, team, or organization – delivers the products as specified by the customer. For projects conducted entirely in-house, both the customer and supplier belong to the same organization.

The primary decision-making role on the project is called the project board, comprising three other roles: the executive and senior user (both from the customer) and the senior supplier (from the supplier). The project board does not operate on a democratic basis, and the executive, advised and supported by the other two roles, ultimately makes the decisions. The project board performs the directing a project process.

The executive role is a single-person responsibility, representing the business aspect of the customer organization financing the project. This role holds ultimate accountability for the project. The senior user role is tasked with specifying and realizing benefits and defining the project’s requirements and products. The senior supplier is responsible for the quality of the specialist products they deliver to the project.

The project assurance role independently assures the project board, separate from the project manager, that the project is being managed correctly. It also provides advice to the project manager and reviews documents before their approval by the project board. Given the time-consuming nature of reviewing project documentation like plans and the business case, PRINCE2 advises the delegation of project assurance to others by the project board members.

The project manager performs the day-to-day project management. This role provides regular progress reporting to the project board via highlight reports. The project manager manages issues and risks, tracks progress, implements corrective actions when there is a deviation from the plan, and reports exceptions to the project board.

Team managers oversee specialist teams with the necessary skills to design and deliver the products specified by the customer. They ensure timely delivery of specialist products within the agreed tolerances and provide regular updates to the project manager through checkpoint reports.

The change authority role is tasked with making decisions about requests for change (RFCs) and off-specifications (to be discussed in more detail in the change theme). The project support role aids project and team managers with administrative tasks, report writing, progress monitoring, and tool administration.

Several of these roles can be shared (i.e., multiple people can perform a role). In PRINCE2, all roles can be shared EXCEPT for the executive and project manager roles. Some roles can be combined (i.e., a person can perform multiple roles). However, the project assurance role cannot be shared with the project manager, team manager, or project support roles to ensure their independence from the project manager.

These roles make up the project management team, all of whom are stakeholders in the project. Yet, stakeholders aren’t limited to the project management team; they can be anyone affected by, or who perceives themselves to be affected by, the project. PRINCE2 recommends the creation of a communication management approach to identify all project stakeholders, their information needs, and the methods and frequency of communication.

The minimum requirements of this theme are as follows:

1. Fulfil all responsibilities as per PRINCE2’s suggested role descriptions.
2. Document and maintain the project’s approach to stakeholder communication and engagement within a communication management approach.

3. Quality

The purpose of the quality theme is to establish and implement mechanisms to ensure project products are ‘fit for purpose’.

PRINCE2 determines quality by assessing whether a product is ‘fit for purpose’, meaning it meets the agreed and defined requirements. The project manager documents the project’s approach to quality management in a quality management approach.

Many organizations employ a quality management system (QMS), an organization-wide framework comprising quality policies, procedures, and standards. A corporate role known as quality assurance (QA) is tasked with developing and maintaining the QMS and verifying project compliance. QA typically conducts quality audits to find evidence of project compliance.

The QA role operates outside of the project, whereas project assurance functions within the project. Project assurance reassures the project board about the project’s proper conduct, while QA assures corporate management of the project’s adherence to corporate standards, policies, and procedures.

Quality control, distinct from QA, involves implementing quality methods to verify if a product is ‘fit for purpose’, maintaining quality and approval records, and securing acceptance. During quality methods, quality records, such as test results, are kept. Based on the results, the product is deemed fit for purpose or not. If deemed fit, the product can be approved, necessitating approval records, often in the form of a signed document or email.

Once approved, the product becomes a baseline, typically assigned a version number, and from that point is subjected to change control. This means it cannot be altered without approval following a request for change (RFC). If a product does not meet the required standard, the supplier carries out additional work to improve it, after which quality control is reapplied.

The project manager handles quality planning during the managing a stage boundary process, which involves defining quality control methods and the project’s acceptance criteria (the measurable features of the final product, which determine its acceptability to the customer). These acceptance criteria stem from the customer’s quality expectations (the project’s high-level business requirements) and are agreed upon before the project starts.

Certain methods (acceptance methods) are executed to confirm the final product meets these criteria. If it does, the project can conclude, having delivered its objectives. Acceptance records encapsulate the formal acceptance of the final product by various stakeholders.

PRINCE2 stipulates a quality register for recording the outcomes of quality methods. This register allows the project manager to oversee all quality control activities on a project.

The Quality theme’s minimum requirements are as follows:

1. Create and maintain a project quality management approach that covers quality control and project assurance, specifying roles and responsibilities for quality management.
2. Clearly define quality criteria for products and keep relevant quality records.
3. Document quality activities in a quality register.
4. Outline the customer’s quality expectations and prioritized acceptance criteria in a project product description.
5. Use lessons learned to inform quality planning on the project.

4. Plans

The purpose of the plans theme is to identify how, when, by whom, where, and at what cost the project will deliver its products.

To assist with planning, a PRINCE2 project has three levels of plan, each corresponding to the informational needs of the three tiers of the project management team. These include:

1. The project plan (utilized by the project board), which includes project level costs, timelines, and control points. An updated version is produced at the conclusion of each stage to capture actual progress and revised forecasts.
2. The stage plan (utilized by the project manager) for daily project management. One is devised for each management stage.
3. The team plan (used by a team manager) that encompasses all the work a team undertakes. The team plan is created by the team manager during the managing product delivery process.

Exception plans do not constitute a plan level. They are new plans (not revised versions of existing plans) that can supplant stage plans or the project plan. In the latter scenario, corporate management must authorize exception plans.

Plans not only designate the products to be delivered within the plan’s scope but also the necessary timescales and costs. PRINCE2 suggests including the following in a plan’s budget:

1. Funding for the activities to create specialist products (and management activities).
2. Funding for responses to risks (risk budget).
3. Funding for authorized alterations to baseline products (change budget).
4. Cost tolerance.

PRINCE2 endorses an approach called product-based planning for creating all plan levels. A crucial step is product definition and analysis, involving four steps:

1. Drafting a project product description to specify what the project must deliver for acceptance.
2. Constructing a product breakdown structure to illustrate the products within scope (note: external products exist already or are being created outside the plan’s scope).
3. Writing product descriptions for the major products.
4. Constructing a product flow diagram to determine the sequence of product development.

Several factors should be considered when determining the number and duration of management stages:

1. The planning horizon at any point, which may depend on the nature of the work.
2. The delivery steps, where it is advantageous if management stages align with delivery steps’ end.
3. Alignment with programme activities.
4. The level of risk.

The minimum requirements of the plans theme are:

1. Make sure that plans facilitate the realization of the business case.
2. A minimum of two management stages.
3. Generate and maintain a project plan, a stage plan for each management stage, and exception plans when necessary.
4. Apply product-based planning in all plan creation.
5. Specify the roles and responsibilities for planning.
6. Use lessons learned to inform all planning efforts.
7. Develop and maintain a project product description, a product description for each product, and a product breakdown structure.

5. Risk

The purpose of the risk theme is to identify, assess, and manage uncertainty, thereby increasing the likelihood of project success.

In the PRINCE2 framework, a risk is an uncertain event that could impact the project’s objectives either positively or negatively. It is essential not to confuse a risk with a project issue, which is an unplanned event that has already occurred. However, when a risk materializes, it becomes a project issue.

Risks can be classified into:

1. Threats, which can have a negative impact, or
2. Opportunities, which can have a positive impact.

Every organization possesses its distinctive view towards risk-taking, known as risk appetite. In PRINCE2, every plan contains a risk budget, which is allocated to manage risk responses. Risk tolerance defines the level of risk that, when forecasted to be exceeded, initiates an exception report, indicating an exception has occurred.

Details about project risks are compiled in a risk register, and a risk management approach is prepared to outline the project’s overall risk management strategy. This approach includes a five-step risk management procedure which is performed during the controlling a stage process:

1. Identify – threats and opportunities are pinpointed and described in terms of the cause (the source of risk), event (area of uncertainty), and effect (the impact).
2. Assess – estimate the probability (likelihood), impact, proximity (when it might occur), and evaluate the cumulative net effect of all risks.
3. Plan – devise one or more specific risk responses.
4. Implement – execute the selected risk responses and assign:
   (a) A risk owner – the person tasked with managing the risk.
   (b) The risk actionee/s – the individual(s) responsible for executing the risk responses
5. Communicate – communicate the risk status to stakeholders using various PRINCE2 reports.

PRINCE2 prescribes six responses to threats: avoidance, reduction, acceptance, transfer, sharing, and preparing contingent plans, and six responses to opportunities: exploiting, enhancing, rejecting, transferring, sharing, and preparing contingent plans.

After responding to primary risks, some level of risk often remains. This is referred to as residual risk. Any risks generated because of risk responses are called secondary risks.

Minimum requirements for this theme include:

1. Using a risk management approach that includes the risk management procedure to be employed.
2. Defining the roles and responsibilities for risk management.
3. Setup and maintain a risk register to document and manage risks.
4. Use lessons from previous projects to inform risk identification and management.

6. Change

The objective of the change theme is to identify, assess, and control any prospective and approved alterations to baseline products.

A baseline is a product that has passed its quality checks, been deemed ‘suitable’, and received approval from those with authority. The product is typically assigned a version number (for instance, version 1.0) at this point.

A project issue is an unplanned event that has occurred, necessitating management action. The three types are:

1. Requests for change (RFC) – an appeal to alter a baseline.
2. Off-specifications – a requirement/product that has not been or cannot be delivered.
3. Problems/concerns – any other issue.

If a project issue is predicted to breach a tolerance limit (concerning time, cost, quality, scope, benefits, or risk), it’s classified as an exception. Project issues can be managed in two ways:

1. Formally – the project board must give formal advice – the issue is noted in the issue register, and an issue report is compiled.
2. Informally – the issue is noted in the daily log.

The project’s approach to handling issues and changes is outlined in a change control approach. It includes an issue & change control procedure, which explains how all project issues will be handled. It contains 5 steps:

1. Capture – record the issue in the issue register or daily log.
2. Examine – conduct an impact analysis (impact on cost, time, quality, scope, benefits, risks).
3. Propose – contemplate alternative response options.
4. Decide – determine which option offers the best overall value for money.
5. Implement – execute the recommended option(s).

A change authority, typically the project board, reviews and approves RFCs and off-specifications. A change budget funds these changes. To effectively change a baseline product, a project must be able to identify the different versions of products. A configuration item record, which logs the status and version of a product, achieves this. It is updated whenever a product’s status changes.

A product status account can be requested to determine a product’s status at any given moment. This report details the status of one or more products and can help the project manager determine whether a product has been approved or whether a product has undergone its quality procedures.

The change theme’s minimum requirements include:

1. Define a change control approach to outline the project’s issue and change control procedure, and the roles and responsibilities for change control.
2. Define the creation, maintenance, and control of product baselines.
3. Ensure that all issues are identified and managed throughout the project.
4. Maintain some form of issue register to document issues and their corresponding decisions.
5. Use lessons to inform the identification and management of issues.

7. Progress

The purpose of the progress theme is to establish controls for monitoring and comparing actual project outcomes against planned outcomes, managing deviations from the baseline, and providing forecasts for the remainder of the project. The project’s controls are outlined in the project initiation documentation which is developed during the initiating a project process.
Progress control is attained through:

1. Delegating authority from one management level to the next lower one.
2. Segmenting the project into management stages and authorising the project one management stage at a time.
3. Time-driven and event-driven progress reporting and evaluations.
4. Highlighting exceptions.

Implementing tolerances allows for control throughout the project at all levels. Tolerances refer to allowable deviations from the plan before alerting the next higher authority. Corporate management sets project tolerances, the project board determines stage tolerances, and the project manager aligns work package tolerances with a team manager.

If project tolerances are predicted to be breached, the project board escalates (using an exception report) to corporate management for a decision. If stage tolerances are projected to be breached, the project manager escalates (using an exception report) to the project board for a decision. If work package tolerances are predicted to be breached, the team manager escalates (using a project issue) to the project manager for a decision.

Monitoring and reporting require a time-based approach, while project control (i.e., decision-making) requires an event-based approach. PRINCE2 defines 2 types of progress control:

1. Time-driven controls – created at agreed intervals (e.g., highlight reports and checkpoint reports).
2. Event-driven controls – triggered when a specific event occurs (e.g., exception report or issue report).

Other instances of event-driven controls include:

1. Work package – authorized by a project manager to initiate teamwork.
2. Lessons log – contains lessons typically learned in the review of progress, e.g., checkpoint report.
3. Lessons report – used by corporate management to improve standards and to gather statistics to aid future estimation.
4. End stage report – used by the project board to assess the project’s ongoing viability at the conclusion of a stage.
5. End project report – written by the project manager during the closing a project process, it is used by the project board to evaluate the project and authorize closure.

The progress controls utilized by a project manager consist of:

1. Baselines: project plan, stage plan, exception plan, work package.
2. Reviewing progress: issue register, risk register, quality register, product status account, daily log.
3. Capturing/reporting lessons: lessons log, lessons report.
4. Reporting progress: checkpoint report, highlight report, end stage report, end project report.

The progress theme’s minimum requirements include:

1. Define the project’s approach to controlling progress in the project initiation documentation.
2. Manage the project by stages, establish tolerances, and manage by exception against these tolerances.
3. Review the business justification when exceptions are raised and learn lessons throughout the project.

Reference

[1] Stationery Office (2017) Managing Successful Projects with PRINCE2. 6th edn. Stationery Office.