7.3 Quality Control Techniques, the Quality Register & Product Acceptance
Key Takeaways
- PRINCE2 7 names six supporting quality techniques — verification, validation, prototyping, testing, inspection, and certification — and expects the quality management approach to say which will be used, when, where, and by whom.
- The quality register is a component of the project log; it summarizes every planned and completed quality activity and records the result simply as pass or fail, plus the response if the product fails.
- A failed quality activity is not automatically an issue: if the product was expected to pass, it may be reasonable to repeat the activity; only a failure against quality tolerances or quality specifications is handled as an off-specification through the issue management technique.
- Every product description names a producer, a reviewer, and an acceptance authority, and acceptance of the project product transfers ownership from the project or supplier to the project board on behalf of the user.
- The formal 6th Edition quality review technique — with its chair, presenter, reviewer, and administrator roles and its complete / conditionally complete / incomplete statuses — is not part of PRINCE2 7; a project may still use it, but only as a documented tailoring choice inside the quality management approach.
Quality Control, Quality Records & Product Acceptance in PRINCE2 7
Practitioner Core Mandate: Quality planning produces two things — product descriptions carrying quality specifications and tolerances, and a quality management approach describing techniques, standards, roles, and responsibilities. Everything after that is quality control: doing the quality activities, recording what happened, and deciding what to do when a product fails. Practitioner scenarios almost always turn on the third part. A candidate who can explain what belongs in the quality register, when a failure becomes an off-specification, and who is allowed to accept a product will score well across the whole 51% practices block.
1. Where Quality Control Sits in the Product Quality Lifecycle
PRINCE2 7 describes a product quality lifecycle that runs from the user's quality expectations through to acceptance. Quality control is the middle and end of that chain.
THE PRODUCT QUALITY LIFECYCLE (PRINCE2 7, CHAPTER 8)
PLANNING QUALITY (8.3.1.1) CONTROLLING QUALITY (8.3.1.2)
┌──────────────────────────────┐ ┌──────────────────────────────┐
│ Gather user inputs │ │ Perform the quality activity │
│ • user's quality │ │ (verify, validate, test, │
│ expectations │ │ inspect, certify, ...) │
│ • acceptance criteria │ ───► │ │
│ (project product descr.) │ │ Record PASS or FAIL in the │
│ │ │ QUALITY REGISTER │
│ Create product descriptions │ │ │
│ • quality specifications │ │ Update the PRODUCT REGISTER │
│ • quality tolerances │ │ with status and version │
│ • producer / reviewer / │ │ │
│ acceptance authority │ │ Capture lessons in the │
│ │ │ LESSONS LOG │
│ Describe the quality │ └───────────────┬──────────────┘
│ management approach │ │
└──────────────────────────────┘ ▼
ACCEPTING PRODUCTS (8.3.1.3)
┌──────────────────────────────┐
│ Review the quality control │
│ information from the project │
│ PLUS an independent review │
│ against the user's quality │
│ expectations and acceptance │
│ criteria │
│ │
│ Ownership transfers to the │
│ project board on behalf of │
│ the user │
└──────────────────────────────┘
Two structural points matter for the exam. First, quality control cannot begin until the quality management approach and the initial product descriptions are approved — an exam scenario in which testing starts before any product description exists is describing a governance failure, not an efficient team. Second, control activities are recorded in the quality register, which then feeds the end stage reports and the end project report. Progress reporting depends on quality records; a project that keeps its quality results in a tester's private spreadsheet cannot produce a defensible end stage report.
2. The Six Supporting Quality Techniques
PRINCE2 7 lists six techniques that are most commonly used in a project context. Understanding their timing, location, and resource requirements is described as essential to project planning — which is why these techniques appear in plans questions as well as quality questions.
| Technique | What it confirms | When it happens | Typical resourcing |
|---|---|---|---|
| Verification | That interim products (such as a design) reflect the necessary quality specifications and acceptance criteria, and that the delivery method follows good practice | During design and development, before the actual product exists | Usually needs specialists in the relevant products or methods |
| Validation | That the finished product meets the quality specifications and acceptance criteria | During testing or after the product exists | Specialists; may require arranging independent testing |
| Prototyping | Early feedback on functionality, or understanding of full-scale production concerns | Early and iteratively; integral to iterative-incremental delivery | Development team; also covers A/B testing of alternate versions |
| Testing | Behaviour under conditions representative of intended use | Multiple times, in multiple locations | Supplier facility testing reduces cost/delay risk; live testing confirms operational fitness |
| Inspection | Compliance with quality specifications and acceptance criteria | Usually at the point of delivery | Low effort; most applicable to commodities and off-the-shelf products |
| Certification | Proof that the product or supplier complies with industry or regulatory requirements | At the point of delivery | Lowest effort; only applicable to commercial off-the-shelf products |
Choosing between them in a scenario
- Verification versus validation is the single most-tested distinction. Verification asks "are we building it right?" and happens while the product is still a design or a draft. Validation asks "did we build the right thing?" and requires the product to exist. A scenario where a team plans only end-of-stage validation on a safety-critical design has skipped verification and will discover design faults at the most expensive possible moment.
- Inspection versus certification both sit at the point of delivery, but certification is a presentation of proof by a third party and applies only to commercial off-the-shelf products. If the scenario has the project manufacturing something bespoke and an option offers "obtain certification instead of testing", that option is wrong.
- Prototyping is a quality technique, not just an agile habit. In a hybrid scenario, a timeboxed prototype used to retire a production-feasibility question is a legitimate entry in the quality register.
Sustainability is a quality consideration, not a bolt-on
PRINCE2 7 places product sustainability inside quality planning (section 8.2.1.4). Sustainability specifications — embodied carbon, recyclability, energy consumption in operation — are written into product descriptions as quality specifications with their own quality tolerances, and they are then checked by exactly the same six techniques. An exam option that treats a carbon target as a separate corporate reporting exercise outside the quality practice is misreading Version 7.
3. Quality Assurance, Quality Control & Project Assurance
Three terms that scenario writers deliberately blur:
| Term | What it is | Who does it | Independence |
|---|---|---|---|
| Quality planning | Defining the quality specifications, tolerances, methods, and responsibilities | Project manager, with user and supplier input | Inside the project |
| Quality control | Performing the quality activities and recording the results | Producers, reviewers, testers named in product descriptions | Inside the project |
| Quality assurance | Independent check that the project's quality management system is adequate and being followed | The business, programme, or a corporate quality function | Outside the project management team |
| Project assurance | The project board's own independent oversight of business, user, and supplier interests | Appointed by, and reporting to, the project board | Independent of the project manager |
Two rules follow. Quality assurance is a business responsibility, not a project one — where more than one organization is involved, each may have its own quality management system and assurance expertise, and the quality management approach must record whose applies. Project assurance is a project board responsibility that can never be delegated to the project manager; in controlling a stage the project manager is expected to consult project assurance that the identified and selected quality reviewers are acceptable.
4. The Quality Register and the Product Register
Both are components of the project log (A13) in PRINCE2 7 — they are no longer stand-alone management products with their own Appendix A entries, and the 6th Edition's configuration item records and product status account have been removed entirely.
Quality register
Its purpose is to summarize all quality management activities that are planned or have occurred, and it is used by the project manager and project assurance as part of reviewing progress. Its content is short and specific:
| Field | What it holds |
|---|---|
| Quality identifier | Unique reference for the quality activity |
| Product identifier | The product subject to the quality activity |
| Quality method | The method involved (test, inspection, verification, certification, review, ...) |
| Dates | Planned and actual dates of the activity |
| Responsibilities | The individuals or functions involved and their respective roles |
| Result | Whether the product passed or failed — plus an indication of the response if it failed |
| Records | The documents associated with the activity, and where they are held |
Note what is not there: there is no "conditionally complete" status and no sign-off column carrying a chair's approval. PRINCE2 7 says the quality register "merely records the quality control activity and its result (typically as 'pass' or 'fail')". Options that describe elaborate status taxonomies in the register are adding 6th Edition machinery.
Product register
Its purpose is to list all products required for a plan and the status of those products:
| Field | What it holds |
|---|---|
| Product identifier | The identifier of the product |
| Dates | Dates of product description approval and of product acceptance |
| Status | Status such as in development or acceptance, and the current version number |
| References | Links to the associated product description |
The product register is the Version 7 answer to "how do we know which version of which product is approved?" — the question the 6th Edition answered with configuration item records and a product status account. In a stage boundary scenario, the evidence that all stage products are complete comes from the product register, supported by the quality register results.
5. From a Failed Quality Activity to an Off-Specification
This is the decision chain Practitioner scenarios test most often, and candidates routinely escalate too early.
WHAT TO DO WHEN A QUALITY ACTIVITY FAILS
Quality activity performed ──► Result recorded as FAIL in quality register
│
▼
Was the product expected to pass this activity?
├── YES, and the failure looks incidental
│ └──► It may be reasonable to REPEAT the activity.
│ Record the repeat and its result. No issue yet.
│
└── NO / the product cannot pass
│
▼
Review the failure against QUALITY TOLERANCES and QUALITY SPECIFICATIONS
│
┌────────────┴─────────────────────────────┐
│ │
Within quality tolerance Outside quality tolerance
└──► Acceptable variation. └──► OFF-SPECIFICATION.
Record and continue. Handle through the ISSUE
MANAGEMENT TECHNIQUE
(Chapter 10): capture,
assess, recommend, decide,
implement.
│
▼
Decision options include rework,
rejection, or a CONCESSION granted
by the authority with delegated
change authority.
Three exam-critical consequences:
- A single failed test is not automatically an issue. PRINCE2 7 explicitly allows repeating an activity where a pass was expected. An option that has the project manager raising an issue report on the first failed unit test is over-escalating.
- Exceptions to quality tolerances and off-specifications are handled by the issues practice, not the quality practice. The quality practice detects; the issues practice decides.
- Lessons go to the lessons log. PRINCE2 7 says lessons identified during the product quality lifecycle are captured in the project log: lessons log — not left in test reports.
6. Accepting Products
Acceptance is the formal end of the quality chain, and the manual is precise about it.
- Who accepts: the individuals or roles responsible for accepting a product are identified in that product's product description, under the Responsibilities heading, which names the producer, the reviewer, and the acceptance authority.
- What acceptance involves: usually both a review of the quality control information provided by the project and an independent review of the product against the user's quality expectations and acceptance criteria. One without the other is incomplete.
- What acceptance does: acceptance of the project product typically transfers ownership or responsibility from the project or supplier to the project board on behalf of the user.
[!CRITICAL EXAM RULE] A concession is not compliance. Granting a concession means an authority has consciously accepted a product that does not meet its quality specifications. The product register records what was actually accepted and at which version. A project manager may only grant a concession where change authority has been explicitly delegated within defined limits; anything touching project-level acceptance criteria or the business case belongs to the project board.
7. Where the Old Quality Review Technique Fits
The 6th Edition defined a formal quality review technique with four roles (chair, presenter, reviewer, administrator), three steps (preparation, review meeting, follow-up), and three outcomes (complete, conditionally complete, incomplete). PRINCE2 7 does not define this technique. Chapter 8 offers the six supporting techniques above, and the manual's glossary describes a quality review simply as an assessment of whether a product is complete, adheres to standards, and meets its quality specifications — which may need to be conducted at multiple points in the development of a complex product.
That does not make structured peer review useless. It makes it a tailoring choice, and PRINCE2 7 is explicit that alternative procedures may be used provided the choice is documented:
- Record the review procedure, its roles, and its outcomes in the quality management approach.
- Record each review as a quality activity in the quality register, with the result expressed as pass or fail.
- Keep the two genuinely valuable disciplines: the reviewer must be independent of the producer (the product description separates producer from reviewer for exactly this reason), and trivial editorial corrections should never consume review-meeting time.
- Do not carry over the 6th Edition vocabulary into exam answers. On a Version 7 paper, "the chair declared the document conditionally complete" is not a PRINCE2 status — it is a description of a locally tailored procedure.
Tailoring quality for agile and modern delivery
┌─────────────────────────────────────────────────────────────────────────────┐
│ PRINCE2 7 QUALITY CONTROL IN AN AGILE CONTEXT │
├──────────────────────────────────────┬──────────────────────────────────────┤
│ PRINCE2 7 CONCEPT │ AGILE / HYBRID IMPLEMENTATION │
├──────────────────────────────────────┼──────────────────────────────────────┤
│ Quality specifications in a product │ Acceptance criteria on a user story │
│ description │ plus a team Definition of Done │
│ Verification │ Design spikes, pull request review, │
│ │ pair programming, static analysis │
│ Validation / testing │ Automated unit, integration, and │
│ │ performance suites in CI/CD │
│ Prototyping │ Spikes, MVP slices, A/B testing │
│ Quality register entry │ Reference to a pipeline build report │
│ │ or sprint review acceptance, not one │
│ │ row per automated test │
│ Product register status │ Release/version status in the repo │
│ │ and deployment records │
└──────────────────────────────────────┴──────────────────────────────────────┘
Tailoring changes how quality control is performed and recorded. It never removes the obligations to define quality specifications, to perform quality activities, to record their results, and to obtain acceptance from the authority named in the product description.
8. Practical Scenario Evaluations
Scenario A: Testing before there is anything to test against
On the SmartGrid Metering rollout, the supplier's test manager begins system testing in stage 2 using a test plan written from the vendor's own product manual. The project's product descriptions for the metering firmware have not yet been approved, and the quality management approach is still in draft. Test results are emailed to the project manager, who files them.
Practitioner Evaluation:
- Governance flaw: quality control has started before the quality management approach and product descriptions were approved. There is no baseline against which "pass" or "fail" means anything, and the results are not in the quality register.
- Impact: the project cannot produce a defensible end stage report, because the quality register feeds it. Worse, the supplier is effectively defining acceptance.
- Correct PRINCE2 action: approve the product descriptions (with quality specifications, quality tolerances, and named producer, reviewer, and acceptance authority) and the quality management approach first; then plan the quality activities into the stage plan and record each result in the quality register.
Scenario B: Escalating a first failed test
During stage 3 of the CloudHealth Portal build, an automated performance test on the search service fails once, returning a 2.4-second response against a 2.0-second quality specification. The build had passed the same test the previous day. The project manager immediately raises an issue report, classifies it as an off-specification, and requests an exception report.
Practitioner Evaluation:
- Governance flaw: over-escalation. PRINCE2 7 states that where a product fails a quality control activity and there is an expectation that it is likely to pass, it may be reasonable to repeat the activity.
- Impact: the project board is drawn into a transient build artefact, and the issue register fills with noise that obscures real non-conformances.
- Correct PRINCE2 action: record the fail in the quality register, repeat the activity, and record the repeat result. Escalate only if the product genuinely cannot pass, and then only after reviewing the failure against quality tolerances — an off-specification is the outcome of that review, not its starting point.
Scenario C: Accepting on test evidence alone
At the end of the final delivery stage of a hospital records migration, the supplier presents a complete pack of passed test results. The project executive proposes accepting the project product on that basis so the project can close on schedule. The senior user has not reviewed the product against the acceptance criteria in the project product description.
Practitioner Evaluation:
- Governance flaw: acceptance normally requires both a review of the project's quality control information and an independent review of the product against the user's quality expectations and acceptance criteria. Only the first has happened.
- Impact: ownership would transfer to the project board on behalf of the user without the user confirming the product is fit for use — the classic route to a product that passes every test and is rejected in operation.
- Correct PRINCE2 action: obtain the independent review by the acceptance authority named in the project product description before confirming project acceptance in closing a project (19.4.3). If the user accepts something short of specification, record it explicitly as a concession and update the product register.
9. Practitioner Exam Pitfalls & Governance Traps
- Trap 1: Answering with 6th Edition quality review vocabulary. Chair, presenter, administrator, question list, and "conditionally complete" are not PRINCE2 7 terms. If an option depends on one of them being method doctrine, it is wrong.
- Trap 2: Raising an issue on the first failure. Repeating a quality activity is explicitly permitted where a pass was expected.
- Trap 3: Confusing quality assurance with project assurance. Quality assurance is independent of the project and belongs to the business; project assurance is the project board's own oversight and is never delegated to the project manager.
- Trap 4: Recording quality results outside the quality register. The register is the input to end stage and end project reporting, and to the project manager's and project assurance's progress reviews.
- Trap 5: Letting the producer accept their own product. The product description names producer, reviewer, and acceptance authority separately for a reason; a single individual filling all three is a governance failure the exam will punish.
- Trap 6: Treating sustainability specifications as outside quality. Product sustainability is part of quality planning; sustainability specifications carry quality tolerances and are checked with the same six techniques.
On the CloudBank Core Modernization project, the automated regression suite for the payments service fails one overnight run: transaction confirmation takes 1.9 seconds against a quality specification of 1.5 seconds, with a quality tolerance of +0.2 seconds. The same suite passed on each of the previous nine nights, and the build engineer believes an unrelated infrastructure restart caused the slowdown. Under PRINCE2 7, what should the project manager do first?
At the end of the final delivery stage of the National Records Migration project, the supplier presents a complete pack of passed test evidence for the migrated records platform. The project executive wants to accept the project product on that evidence alone so that closure stays on schedule. The Head of Clinical Records, who is the senior user and is named as the acceptance authority in the project product description, has not reviewed the platform against the acceptance criteria. Under PRINCE2 7, what is the correct assessment of this proposal?
On a fast-paced fintech software project utilizing agile delivery methods, the specialist team delivers working software increments through two-week sprints. The team uses automated unit testing, continuous integration build pipelines, and automated static code analysis to verify code quality against a shared 'Definition of Done'. The newly appointed Project Assurance officer insists that the team must halt agile development and conduct formal, paper-based PRINCE2 Quality Review meetings with printed question lists for every software user story. How should the Project Manager tailor the Quality practice to resolve this dispute?