The 7 Practices
The seven practices provide detailed guidance on how the PRINCE2 principles should be put into practice. In earlier versions they were referred to as ‘Themes’ but have been renamed to ‘Practices’ to better reflect the need for their consistent application rather than being viewed as static topics. Like other elements of PRINCE2, the application of these practices should be tailored to the specific context and complexity of the project.
These practices collectively form the control framework of PRINCE2. They are not merely areas of interest but active management disciplines through which the project manager and the Project Board ensure the project remains aligned with its objectives (Business Case, Quality, Plans), effectively manages uncertainty (Risk, Change), monitors performance against baselines (Progress), and maintains the necessary structure for governance (Organisation). They are the mechanisms that operationalize the principles and enable the structured control central to the PRINCE2 philosophy.
1. Business Case
Purpose: This practice establishes and maintains the justification for the project. It provides the mechanism to assess whether the project remains desirable, viable, and achievable throughout its lifecycle, supporting informed investment decisions. It directly supports the ‘Continued Business Justification’ principle.
Application: This involves the initial development of the Business Case, its ongoing verification against events and progress, and its maintenance throughout the project. The Business Case document details the reasons for the project, expected benefits, costs, timescales, and risks. A key associated management product is the Business Case itself. Another is the Benefits Management Approach, which outlines how and when the project’s benefits will be measured and reviewed, often extending beyond the project’s closure.
2. Organisation
Purpose: This practice defines and establishes the project’s management structure, clarifying roles, responsibilities, accountabilities, and communication lines (the ‘who?’). It ensures that the project has the right people involved in the right capacity for effective governance and decision-making. This practice underpins the ‘Defined Roles and Responsibilities’ principle.
Application: It involves defining the project management team structure, including the different levels (Directing, Managing, Delivering) and specific roles (e.g., Project Board, Executive, Senior User, Senior Supplier, Project Manager, Team Manager, Project Assurance, Project Support). It also includes defining the strategy for communicating with all stakeholders. The Project Initiation Documentation (PID) is a key output, as it contains the definitive project management team structure and role descriptions. The Communication Management Approach details how communication will be handled.
3. Quality
Purpose: This practice focuses on ensuring that the project’s products meet business expectations and are ultimately ‘fit for purpose’. It defines and implements the system through which the project will verify that deliverables meet the required standards and satisfy stakeholder requirements. This practice supports the ‘Focus on Products’ principle.
Application: Quality management in PRINCE2 involves defining the customer’s quality expectations and acceptance criteria early on. Specific, measurable quality criteria are then defined for each product within its Product Description. The practice guides the planning and execution of quality control (testing, inspection) and quality assurance activities, with results and activities tracked. Key management products include the Quality Management Approach (defining the strategy and procedures) , Product Descriptions (containing quality criteria), and the Quality Register (logging planned and actual quality activities and results).
4. Plans
Purpose: This practice provides the framework for designing, developing, and maintaining the project’s plans. Plans facilitate communication and control by defining how the project’s objectives and products will be delivered – answering the questions of how, where, when, by whom, and at what cost. It supports the ‘Manage by Stages’ and ‘Focus on Products’ principles. PRINCE2 7 emphasizes that planning is about building consensus and establishing a “social contract” among stakeholders, not merely creating documents.
Application: PRINCE2 advocates different levels of plans tailored to the needs of different management levels: the high-level Project Plan (used by the Project Board), detailed Stage Plans for each management stage (used by the Project Manager for day-to-day control), and optional Team Plans (used by Team Managers to outline how Work Packages will be delivered). The methodology prescribes a specific technique, product-based planning, which starts by identifying the required products before planning the activities needed to create them. Key management products are the Plan documents themselves, the Product Description for each planned product, and the overall Project Product Description which defines the final output of the project.
5. Risk
Purpose: This practice aims to improve the project’s chances of success by systematically identifying, assessing, and controlling uncertainty. Risk in PRINCE2 refers to any uncertain event that, if it occurs, could have a positive (opportunity) or negative (threat) effect on the project’s objectives.
Application: Effective risk management involves defining a clear approach (how risk will be managed), identifying potential risks, assessing their probability and potential impact, planning appropriate responses (to avoid, reduce, transfer, or accept threats; or to exploit, enhance, share, or reject opportunities), implementing these responses, and continuously monitoring and communicating the risk status. The primary management products for this practice are the Risk Management Approach (detailing the procedure) and the Risk Register (a log of all identified risks, their analysis, planned responses, and current status).
6. Change
Purpose: This practice deals with how the project handles modifications to its agreed baseline (e.g., changes to scope, schedule, cost, or products). Its aim is to ensure that all potential changes are identified, assessed, and controlled in a consistent manner, preventing uncontrolled ‘scope creep’.
Application: This involves establishing a formal change control procedure. Issues (which include requests for change, identified problems, or products failing to meet specifications, known as off-specifications) are captured, typically in an Issue Register. Each issue is assessed for its potential impact on the project’s objectives (time, cost, quality, scope, risk, benefits). Decisions on whether to approve, reject, or defer the change are made by the appropriate level of authority (Project Board or delegated Change Authority). Key management products include the Change Control Approach (defining the process, including configuration management procedures for tracking product versions), the Issue Register (logging all formal issues), and potentially Issue Reports providing detailed analysis of specific issues.
7. Progress
Purpose: This practice establishes the mechanisms for monitoring actual achievements against planned targets, forecasting the project’s future performance and continued viability, and controlling any unacceptable deviations. It supports the ‘Manage by Stages’ and ‘Manage by Exception’ principles.
Application: Progress control involves setting baselines for performance (defined in the Plans), monitoring actual progress and performance against these baselines across all six tolerance areas (time, cost, quality, scope, benefits, risk), and regularly reporting this progress to relevant stakeholders. If forecasts predict that tolerances will be exceeded, the exception procedure is triggered. Key management products associated with this practice are primarily reports, such as Checkpoint Reports (Team Manager to Project Manager updates on Work Package progress), Highlight Reports (Project Manager to Project Board summaries of stage progress), End Stage Reports, the final End Project Report, and Exception Reports (escalating tolerance deviations). Records like the Daily Log (PM’s diary) and Lessons Log also support progress tracking and control.
Summary Tables
The following tables summarize the purpose of each practice and the key management products associated with them:
Table 1: Summary of PRINCE2 Practices and Purpose
| Practice | Purpose |
|---|---|
| Business Case | Ensure continued justification and alignment with business objectives. |
| Organisation | Define and establish the project’s structure of accountability and responsibilities. |
| Quality | Define and verify that products are fit for purpose and meet requirements. |
| Plans | Define how, when, where, by whom, and for how much the project’s products will be delivered. |
| Risk | Identify, assess, and control uncertainty (threats and opportunities). |
| Change | Identify, assess, and control potential and approved changes to project baselines. |
| Progress | Monitor and compare actual achievements against plan, forecast viability, and control deviations. |
Table 2: Key Management Products per Practice
| Practice | Key Associated Management Products |
|---|---|
| Business Case | Business Case, Benefits Management Approach |
| Organisation | Project Initiation Documentation (PID) (containing structure/roles), Communication Management Approach |
| Quality | Quality Management Approach, Product Description(s), Quality Register |
| Plans | Plan (Project/Stage/Team), Product Description(s), Project Product Description |
| Risk | Risk Management Approach, Risk Register |
| Change | Change Control Approach, Issue Register, Issue Report, Configuration Item Record |
| Progress | Reports (Checkpoint, Highlight, End Stage, End Project, Exception, Lessons), Daily Log, Lessons Log |