7.1 Quality Planning, Quality Control & Quality Assurance

Quality Planning, Quality Control & Quality Assurance in PRINCE2 7

Practitioner Core Mandate: In PRINCE2, quality is never an afterthought, a cosmetic polish, or a subjective assessment made at project closure; it is a proactive, end-to-end management discipline directly rooted in the Focus on Products principle. Delivering a project strictly on time and within budget provides zero business value if the resulting specialist products fail to perform as required by business operations. PRINCE2 7 establishes a structured quality regime that integrates upfront planning, operational verification, and independent process assurance to safeguard investment justification and ensure fit-for-purpose delivery.

---

1. Purpose & Strategic Value of the Quality Practice

The purpose of the Quality practice in PRINCE2 7 is to establish the mechanisms by which the project will ensure that the products delivered meet business expectations and enable the realization of forecast benefits set out in the Business Case.

                  THE VALUE CHAIN OF THE QUALITY PRACTICE

   ┌────────────────┐      ┌─────────────────┐      ┌─────────────────┐
   │ FOCUS ON       │ ───► │ QUALITY         │ ───► │ BENEFITS        │
   │ PRODUCTS       │      │ PRACTICE        │      │ REALIZATION     │
   │ (Principle:    │      │ (Plan, Control, │      │ (Operational    │
   │  Explicit      │      │  Assure Fitness │      │  Value in       │
   │  Criteria)     │      │  for Purpose)   │      │  Business Case) │
   └────────────────┘      └─────────────────┘      └─────────────────┘

Without an effective Quality practice, project governance collapses into activity tracking without product verification. Quality failures directly compromise the project's Continued Business Justification:

1. Unusable Products: An enterprise e-commerce portal delivered on schedule that suffers database locking under 500 concurrent transactions cannot deliver its forecast revenue growth.
2. Rework and Cost Escalation: The cost of identifying and rectifying defects increases exponentially the later they are discovered in the project lifecycle. Rectifying an architectural defect during operational rollout costs up to 100 times more than resolving it during upfront quality planning.
3. Reputational and Regulatory Exposure: In safety-critical or heavily regulated sectors (e.g., healthcare, financial services, aerospace), delivering products that breach compliance standards exposes the commissioning organization to severe legal sanctions and commercial loss.

---

2. Core Definitions: Quality, Scope & Quality Management

To apply the Quality practice effectively, candidates must master the precise boundaries separating quality, scope, and quality management.

Defining Quality

PRINCE2 7 aligns its definition of quality with the international standard ISO 9000:

Quality is the degree to which a set of inherent characteristics of a product, service, process, person, organization, system, or resource fulfills requirements.

In practical terms, quality in PRINCE2 represents "fitness for purpose." A product is not high quality because it is luxurious, gold-plated, or engineered with unnecessary features; a product is of high quality when it satisfies all the requirements, standards, and acceptance criteria agreed upon by the business, users, and suppliers.

Scope vs. Quality: The Fundamental Distinction

One of the most frequent examination traps involves confusing project scope with product quality:

• Scope defines what is to be delivered. It encompasses the totality of the products to be produced and the boundaries of the work required to create them. Scope addresses questions of quantity, functional coverage, and physical deliverables (e.g., constructing a 5-story office building with 150 workstations and a basement parking facility).
• Quality defines how well those products perform and whether they satisfy explicit standards. It encompasses the attributes, specifications, tolerances, and performance thresholds that each deliverable must meet (e.g., thermal insulation ratings, acoustic dampening thresholds, fire-suppression trigger times, and energy consumption limits).

┌─────────────────────────────────────────────────────────────────────────────┐
│                     SCOPE VERSUS QUALITY IN PRINCE2 7                       │
├─────────────────────────────────────────────────────────────────────────────┤
│ SCOPE: The Boundaries of Delivery                                           │
│ • What specialist products are in scope vs out of scope                     │
│ • The breadth and range of functional capabilities                          │
│ • The work packages required to execute the deliverable                     │
│                                                                             │
│ QUALITY: The Standard of Execution & Fitness for Purpose                    │
│ • Performance metrics, durability, and reliability thresholds               │
│ • Conformance to industrial, regulatory, and corporate standards            │
│ • Explicit quality specifications and allowable quality tolerances          │
└─────────────────────────────────────────────────────────────────────────────┘

Scope vs. Quality Comparative Matrix

Defining Quality Management

Quality Management refers to the coordinated activities to direct and control an organization with regard to quality. In a project environment, it encompasses the overarching strategy, organizational roles, procedural guidelines, verification techniques, and record-keeping mechanisms utilized throughout the project lifecycle.

---

3. The Quality Triad: Planning, Control, and Assurance

PRINCE2 7 organizes quality management into three continuous, interrelated disciplines: Quality Planning, Quality Control, and Quality Assurance.

                         THE PRINCE2 QUALITY TRIAD

   ┌─────────────────────────────────────────────────────────────────────┐
   │                         QUALITY PLANNING                            │
   │  • Defines quality standards, procedures, and responsibilities      │
   │  • Establishes Quality Management Approach                          │
   │  • Formulates Project Product Description & Product Descriptions    │
   └──────────────────┬───────────────────────────────▲──────────────────┘
                      │                               │
                      │ Sets Baselines                │ Feedback for
                      ▼ & Criteria                    │ Continuous Improvement
   ┌──────────────────────────────────┐   Audits      ┌──────────────────┐
   │         QUALITY CONTROL          │◄──────────────┤QUALITY ASSURANCE │
   │ • Executes tests & inspections   │   Compliance  │ • Corporate audit│
   │ • Verify / validate / test       │   with QMS    │ • Independent of │
   │ • Tracks defects & rework        │               │   PM Team        │
   │ • Updates Quality Register       │               │ • Checks process │
   └──────────────────────────────────┘               └──────────────────┘

1. Quality Planning (Setting the Baseline)

Quality Planning is the proactive activity of determining which quality standards, practices, and criteria apply to the project, its management processes, and its specialist deliverables.

• Timing: Primarily conducted during Starting Up a Project (SU) (identifying customer expectations) and Initiating a Project (IP) (creating the Quality Management Approach and Project Product Description), with detailed planning recurring in Managing a Stage Boundary (SB) for each upcoming stage.
• Core Activities:
  • Understanding the user's quality expectations and establishing prioritized acceptance criteria.
  • Defining the project's Quality Management Approach (procedures, standards, tools, roles).
  • Writing granular Product Descriptions for all specialist products, detailing measurable quality specifications, tolerances, methods, and review responsibilities.
  • Setting up the Quality Register to track all upcoming quality events.

2. Quality Control (Operational Verification & Defect Management)

Quality Control comprises the operational techniques and activities used to fulfill quality requirements. It focuses on the inspection, testing, and verification of intermediate and final products during stage execution.

• Timing: Conducted continuously during Controlling a Stage (CS) and Managing Product Delivery (MP).
• Core Activities:
  • Carrying out planned quality inspections, peer reviews, automated regression suites, laboratory tests, and user acceptance trials.
  • Executing the PRINCE2 7 quality techniques — verification, validation, prototyping, testing, inspection, and certification — on the products named in the stage plan.
  • Logging defects, tracking required rework, and re-inspecting corrected deliverables.
  • Recording the actual dates, outcomes, and formal approval sign-offs in the Quality Register.
  • Preventing defective deliverables from passing to subsequent stages or operational users without authorized concessions.

3. Quality Assurance (Independent Systemic Oversight)

Quality Assurance provides independent verification that the project's quality processes, management controls, and operational techniques comply with corporate quality policies, regulatory mandates, and industry standards.

• Timing: Conducted periodically across the project lifecycle according to corporate audit schedules or stage gates.
• Core Activities:
  • Auditing whether the project team is actively adhering to its approved Quality Management Approach.
  • Evaluating whether quality control methods (inspections, test suites) are being executed rigorously and recorded accurately in the Quality Register.
  • Verifying that corporate Quality Management Systems (QMS), such as ISO 9001, are maintained throughout project execution.
  • Reporting findings directly to corporate, programme, or portfolio management, independent of project management pressures.

---

4. Project Assurance vs. Quality Assurance: The Critical Governance Divide

A central focus of the PRINCE2 7 Practitioner examination is the distinction between Project Assurance and Quality Assurance. While both provide independent scrutiny, they operate at completely different governance tiers and answer to different authorities.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     GOVERNANCE HIERARCHY OF ASSURANCE                       │
├─────────────────────────────────────────────────────────────────────────────┤
│ CORPORATE, PROGRAMME OR PORTFOLIO MANAGEMENT                                │
│ └─ QUALITY ASSURANCE (Independent corporate audits, QMS compliance)         │
│    │                                                                        │
│    ▼ Reports corporate non-compliance outside the project team              │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ PROJECT MANAGEMENT TEAM                                                 │ │
│ │                                                                         │ │
│ │ PROJECT BOARD (Project Exec., Senior User, Senior Supplier)             │ │
│ │ └─ PROJECT ASSURANCE (Business, User, Supplier Assurance)               │ │
│ │    │ (Internal to project governance; monitors PM and stage health)     │ │
│ │    ▼                                                                    │ │
│ │ PROJECT MANAGER                                                         │ │
│ │ └─ Oversees Quality Control execution & Quality Register maintenance    │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘

Key Differences Between the Two Assurances

1. Organizational Positioning & Reporting Lines:
   • Project Assurance: Is an integral responsibility of the Project Board. Board members may perform it personally or delegate it to dedicated assurance roles (Business Assurance, User Assurance, Supplier Assurance). It reports directly to the Project Board members and is internal to the Project Management Team structure.
   • Quality Assurance: Is strictly external to the Project Management Team. It reports to the business layer, Programme Management, or a corporate Quality Director, ensuring complete organizational independence from project delivery targets.
2. Mandate & Focus:
   • Project Assurance: Focuses on the viability and delivery of this specific project. It monitors whether the Project Manager is managing within tolerances, whether the Business Case remains viable, whether user needs are satisfied, and whether supplier resources are appropriate.
   • Quality Assurance: Focuses on organizational standards and process integrity. It evaluates whether the project's quality management processes comply with corporate policies, statutory regulations, and industry benchmarks.
3. Independence from the Project Manager:
   • Both forms of assurance must be independent of the Project Manager.
   • The Project Manager cannot perform Project Assurance (as one cannot objectively assure one's own work) and cannot perform Quality Assurance.

Comprehensive Comparison Matrix: Project Assurance vs. Quality Assurance

---

5. The Quality Management Approach: Architecture & Core Components

The Quality Management Approach is a mandatory management product formulated during the Initiating a Project (IP) process by the Project Manager and approved by the Project Board. It becomes part of the Project Initiation Documentation (PID).

Purpose

The Quality Management Approach describes how quality will be managed on the project. It outlines the specific quality standards, procedures, techniques, tools, and responsibilities required to satisfy the user's quality expectations.

Key Components of the Quality Management Approach

1. Introduction & Quality Principles: Explains the project context, quality philosophy, and how the Quality practice aligns with project objectives.
2. Quality Management Procedures:
   • Quality Planning Procedures: How product descriptions are created, reviewed, and baselined.
   • Quality Control Procedures: The testing methods, inspection techniques, and formal quality reviews to be deployed.
   • Quality Assurance Procedures: The schedule, scope, and coordination mechanisms for corporate/external audits.
3. Applicable Standards & Regulations: Explicit listing of corporate quality policies, national/international standards (e.g., ISO/IEC 27001 for data security, ISO 9001, BREEAM for construction), statutory environmental rules, and corporate design systems.
4. Tools, Techniques & Systems: Software tools used for test automation (e.g., Selenium, JUnit), static code analyzers, defect tracking systems (e.g., Jira), and document management repositories.
5. Quality Records & Audit Trails: How quality activities will be documented, where test logs are archived, and how the Quality Register will be maintained and updated.
6. Timing & Resource Allocation: Schedule of major quality gates, testing phases (e.g., factory acceptance testing, integration testing, operational soak testing), and budget allocations for quality equipment or third-party inspectors.
7. Roles & Responsibilities: Explicit definition of who is responsible for quality planning, quality control execution, assurance oversight, and defect remediation across the Project Board, Project Manager, Team Managers, Project Assurance, and corporate quality staff.

---

6. Guidance for Effective Management for Applying the Quality Practice

To claim compliance with PRINCE2 7, a project must satisfy the PRINCE2 7 guidance for effective quality management. These points guarantee that quality governance remains rigorous regardless of how the project is tailored.

┌─────────────────────────────────────────────────────────────────────────────┐
│            PRINCE2 7 MINIMUM REQUIREMENTS: THE QUALITY PRACTICE             │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. Define the Quality Management Approach                                   │
│    └─ Must document procedures, standards, techniques, and responsibilities │
│                                                                             │
│ 2. Define the Project Product Description                                   │
│    └─ Must capture user's quality expectations & prioritized acceptance     │
│                                                                             │
│ 3. Formulate Product Descriptions for all specialist products               │
│    └─ Must specify quality specifications, quality tolerances, and methods  │
│                                                                             │
│ 4. Maintain a Quality Register                                              │
│    └─ Must record all planned and executed quality activities               │
│                                                                             │
│ 5. Allocate Explicit Quality Roles                                          │
│    └─ Must assign producers, reviewers, approvers, and assurance delegates  │
│                                                                             │
│ 6. Apply Lessons & Maintain Traceability                                    │
│    └─ Must capture quality lessons and retain an auditable verification path│
└─────────────────────────────────────────────────────────────────────────────┘

Tailoring Considerations

While these six requirements are mandatory, the manner in which they are implemented scales with project scale and delivery method:

• On a small internal project, the Quality Management Approach may consist of a two-page section within a simplified PID, and the Quality Register may be a collaborative spreadsheet.
• On a large commercial contract, the Quality Management Approach will be an extensive formal document referencing multi-volume corporate QMS procedures, with the Quality Register embedded inside an enterprise ERP or automated compliance pipeline.

---

7. Practical Scenario Evaluations

Scenario A: Corporate Quality Assurance Overstepping Governance Boundaries

During Stage 3 of the MedTech Diagnostics Scanner project, a corporate Quality Assurance auditor inspects the project's software verification test logs. The auditor discovers that automated testing coverage is at 88% instead of the 95% recommended by corporate IT guidelines. Without consulting the Project Board, the corporate auditor issues a binding instruction directly to the third-party software development team to halt all work, rewrite existing unit test scripts, and refuse to accept any further Work Packages from the Project Manager.

Practitioner Evaluation:

• Governance Flaw: The corporate Quality Assurance auditor has breached the governance boundaries between the business layer and the project management team.
• Impact: Quality Assurance is an independent compliance auditing function; it does not possess executive command authority over project resources or contractual work packages. Halting work unilaterally disrupts stage delivery, creates contractual liability with the vendor, and undermines the Project Board's accountability.
• Correct PRINCE2 Action: The QA auditor must document the discrepancy in an audit report and submit it directly to the business layer and the Project Board. The Project Board, exercising its directing authority, reviews the finding alongside the Project Manager, assesses the impact on stage tolerances and product descriptions, and directs the Project Manager on appropriate corrective action.

Scenario B: Project Assurance Conducting Quality Control Work

On the CityMetro Light Rail project, the Senior User delegates User Assurance to an experienced transit operations manager. When the contractor submits the draft Station Operations Manual, the User Assurance delegate spends three weeks personally redrafting the procedural chapters, rewriting emergency evacuation checklists, and formatting the manual before issuing it to operations staff.

Practitioner Evaluation:

• Governance Flaw: The User Assurance delegate has conflated Project Assurance with product production and quality control rework.
• Impact: Project Assurance must remain independent of production and day-to-day execution. By actively rewriting the deliverable, the assurance delegate has become a co-author of the product, destroying their objectivity. They can no longer provide independent assurance to the Senior User regarding whether the product meets operational criteria.
• Correct PRINCE2 Action: If the manual failed to meet user quality specifications, the user assurance delegate should have recorded the deficiencies as the result of the quality activity in the quality register and reported them to the senior user and project manager. The Project Manager would then instruct the original producer (or Team Manager) to execute the necessary rework under the existing Work Package.

Scenario C: Scope Expansion Disguised as Quality Rectification

During quality testing of a newly developed Customer Billing Engine, business users discover that the software lacks an automated currency conversion feature for cross-border transactions. The Project Manager instructs the development team to build the currency converter immediately, categorizing the work as 'quality defect rectification' to avoid seeking Project Board approval for a change in scope.

Practitioner Evaluation:

• Governance Flaw: The Project Manager has disguised a scope expansion (new functionality) as a quality defect, violating both the Manage by Exception and Focus on Products principles.
• Impact: Quality defect rectification applies only when a product fails to satisfy its approved, baselined Product Description. Adding currency conversion represents a new functional deliverable that was never included in the original scope or Product Description. Bypassing change control distorts the stage budget and masks tolerance consumption.
• Correct PRINCE2 Action: The Project Manager must log the user request as a formal Issue (Request for Change - RFC) in the Issue Register. If incorporating currency conversion threatens stage cost or time tolerances, the Project Manager must escalate the issue to the Project Board via an Exception Report.