8.2 Quality Techniques & Management Products

Quality Techniques

PRINCE2 does not mandate a single quality technique — it expects the project to choose techniques proportionate to the product and the risk. The signature technique, and the one most heavily tested, is the quality review.

The Quality Review

A quality review is a structured, role-based review of a product against its quality criteria. It is not a general discussion or a show-and-tell; it is a controlled meeting with defined inputs, defined roles, and defined outputs. The product's Product Description supplies the criteria, and the reviewers assess the product against those criteria. The result is a confirmed outcome — the product is approved, conditionally approved with an action list, or rejected — plus a documented action list of clarifications or corrections.

The four roles within a quality review are deliberately separated so that no single person both produces and approves a product:

A common scenario trap is to confuse the chair and the presenter. The presenter is the producer of the product and is there to explain it; the chair is the independent facilitator who judges whether the criteria are met. If a question describes the author running the meeting and approving their own work, that is a malformed review — the chair must be independent of the author.

Other Quality Techniques

Beyond the formal quality review, PRINCE2 recognises a range of techniques, each suited to different products and risk levels:

• Inspections — formal, documented examinations against a checklist, often used for compliance-driven products.
• Peer reviews — lighter-weight, colleague-led reviews of a product; less formal than a quality review but still produce comments.
• Testing — execution of the product to observe behaviour, central to software, machinery, and processes.
• In-process checks — verifications carried out during production rather than at the end, supporting the 'quality is built in' philosophy.

The choice of technique is itself a planning decision, recorded in the Product Description under the quality method field. A high-risk, externally regulated product will warrant a full quality review; a low-risk internal document may warrant only a peer review. Tailoring the technique to the product is itself an exam scenario.

Quality Management Products

Quality Management Approach

The Quality Management Approach is the project-level document that defines how quality will be managed and applied across the project. It is produced during initiation and included in the Project Initiation Documentation (PID), where the Project Board approves it. It typically defines the quality techniques to be used, the standards to be applied, the roles and responsibilities for quality, the quality records to be kept, and how quality reporting will work. It does not define the criteria for individual products — those live in the Product Descriptions — but it sets the framework within which those criteria are produced and verified.

Product Description

Every product managed under PRINCE2 has a Product Description that specifies, at minimum, its identifier, purpose, composition, derivation, format, quality criteria, quality methods, and quality tolerance. The quality criteria are the testable statements of what the product must achieve; the quality method says how conformance will be checked; the quality tolerance defines the permissible deviation. A Product Description without quality criteria is a planning defect — there is no way to know whether the product is done.

Project Product Description

The Project Product Description is the single, top-level Product Description for the entire project product. It captures the customer's quality expectations and the acceptance criteria for the project as a whole, along with the project-level quality methods and the user/stakeholders responsible for acceptance. It is created in Starting Up, refined in initiation, and used by the Project Board at project closure to confirm acceptance.

Quality Register and the v7 Project Log

In earlier versions of PRINCE2, the Quality Register was a standalone log recording every quality check carried out on the project — what was checked, when, by whom, against which criteria, and with what result. In PRINCE2 v7, the Quality Register is consolidated into the Project Log, the single evolving record that also captures issues, risks, lessons, and daily log entries. The exam may use either term; the underlying function — a traceable record of quality checks — has not changed, only its container.

Quality Tolerance

Quality tolerance is the permissible deviation from a quality criterion before the product is judged non-conforming. For example, a performance criterion of 'responds within 200 ms' might carry a quality tolerance of 'up to 220 ms under peak load'. Setting the tolerance is a planning decision recorded in the Product Description; exceeding it is a quality control failure that must be raised and resolved. Tolerances prevent reviewers from arguing over trivial differences and give the team a clear, agreed boundary.

Exam Scenario Patterns

• Components of a Quality Management Approach. Expect questions that ask what belongs in the QMA versus in a Product Description. The QMA holds the how (techniques, standards, roles, reporting); Product Descriptions hold the what for this product (criteria, method, tolerance).
• Outputs of a quality review. The signature outputs are a confirmed review result and an action list; the administrator records and distributes them.
• Where a quality check is recorded. Each quality check is recorded in the Quality Register (or, in v7, the Project Log). The Product Description defines the criteria; the QMA defines the approach; the register records the event of checking.