PRINCE2 2017 Quality Theme and Product Acceptance
Translate broad expectations into explicit, testable product criteria, then create evidence that each planned quality activity and final acceptance decision has actually occurred.
Executive summary
Fit for purpose
Quality management is used to verify that project products meet agreed expectations and can support the intended benefits.
Plan before checking
Quality expectations, acceptance criteria, product-level quality criteria, tolerances, methods and responsibilities should be defined before final inspection.
Evidence matters
The quality register and quality/approval records provide evidence that planned activities were completed and products were reviewed and accepted.
Two descriptions, two purposes
The Project Product Description defines the overall project product and customer acceptance; Product Descriptions define individual products and their detailed quality review requirements.
Purpose and control logic
The Quality theme exists to define and implement the means by which the project verifies that products are fit for purpose. In the supplied material, fitness for purpose has two linked dimensions: products should meet business expectations, and they should be capable of enabling the intended benefits. A project can therefore be on time and within budget yet still fail if the outputs cannot be accepted or used as intended.
The method treats quality as a planned management discipline rather than a final inspection event. The project first discusses customer quality expectations and acceptance criteria for the overall project product. It then identifies the products that will be controlled, defines them in Product Descriptions, specifies quality criteria, tolerances, methods and responsibilities, and tracks the resulting activities. This creates a chain from expectation to specification to verification to acceptance.
A practical consequence is that quality should be designed into the management system. If a team reaches the end of development before agreeing what “good” means, disputes about completeness are almost inevitable. The source therefore connects quality closely to the focus-on-products principle and to product-based planning.
Quality planning versus quality control
Quality planning defines what quality means for this project and its products. It establishes the overall expectations, acceptance criteria, individual product criteria, allowable tolerances, methods of review or test, required skills and the people responsible for producing, reviewing and approving products. It also defines how quality management will be communicated and governed.
Quality control is the execution of planned checking. It uses inspection, testing or review to determine whether products satisfy their defined criteria. It also confirms product completeness and creates records of the checks and approvals performed. The supplied material notes that particular technical quality-management techniques are outside the method; the project chooses suitable techniques for its domain.
| Question | Quality planning | Quality control |
|---|---|---|
| Primary question | What must be true for the product to be acceptable, and how will we check it? | Does the product actually meet the defined criteria? |
| Timing | Before and during product definition and planning | During production and when products are ready for review/approval |
| Typical outputs | Quality Management Approach, Product Descriptions, planned entries in Quality Register | Test/review results, Quality Register updates, quality records and approval records |
| Management value | Prevents ambiguous expectations and unplanned checking | Provides objective evidence and triggers correction when criteria are not met |
Customer quality expectations and acceptance criteria
Customer quality expectations describe the expected quality of the overall project product. They are usually broad and may include important standards, processes, measurements or behavioural expectations. The source places them in the Project Product Description and notes that they influence the solution and the detailed acceptance criteria.
Acceptance criteria are a prioritised set of measurable conditions that the overall project product must meet before the customer will accept it. They are first understood during Starting Up a Project and agreed in Initiating a Project; the source allows them to evolve as understanding improves. They are critical at closure because user acceptance cannot be confirmed credibly without a previously agreed basis.
Prioritisation is useful when expectations compete. It helps the project understand which attributes are essential, which are desirable and where some tolerance may exist. It also provides an input to quality tolerance. A well-written acceptance criterion should be capable of an observable pass/fail or measured assessment, should identify the acceptance method and should have an owner who is authorised to sign off.
The project can close after the agreed products are accepted even though some benefits are expected only after operational use. Acceptance confirms the delivered output; the Benefits Management Approach covers later benefit measurement.
Product-level quality definition
For each controlled product, the Product Description converts requirements into a practical quality-control specification. The source highlights five elements: quality criteria, tolerances, methods, skills and responsibilities. Quality criteria are the measurable specifications that the product will be judged against. A quality tolerance defines an acceptable range around a criterion where that is appropriate. The quality method describes how the criterion will be checked.
The source distinguishes in-process methods from appraisal methods. In-process methods build quality into production through controls, automation or other preventive techniques. Appraisal methods examine a finished or partially finished product through inspection, testing or review. A mature project may use both: prevention to reduce defects, and independent appraisal to demonstrate conformance.
Responsibilities are also explicit. A producer creates the product, a reviewer checks it against its requirements, and an approver confirms that it is complete and fit for purpose. These responsibilities should be tailored sensibly, but the act of defining them prevents the common failure in which everyone assumes someone else will perform the final check.
Criteria
The measurable product attributes or specifications to be achieved.
Tolerance
The permitted range around a criterion before the result becomes unacceptable or requires escalation.
Method
The test, inspection, review or in-process control used to evaluate the criterion.
Skills
Any specialist competence needed to perform or interpret the quality method.
Reviewer
The person or role that checks whether the product meets its defined requirements.
Approver
The authorised person or role that confirms completeness and fitness for purpose.
Project Product Description versus Product Description
The supplied material deliberately distinguishes the Project Product Description from ordinary Product Descriptions. The first is created early and defines the overall project product from the customer-acceptance perspective. It contains the overall customer quality expectations, acceptance criteria, project-level quality tolerances, acceptance method and acceptance responsibilities.
A Product Description operates at the individual-product level. It states the product’s purpose and composition as well as quality criteria, quality tolerance, quality method, required quality skills and responsibilities for production, review and approval. These descriptions are central to product-based planning because activities are identified only after the products have been defined.
| Management product | Primary perspective | Typical quality content |
|---|---|---|
| Project Product Description | Overall project output and customer acceptance | Customer quality expectations, acceptance criteria, project-level quality tolerance, acceptance method and acceptance responsibility |
| Product Description | One controlled product | Purpose/composition plus detailed quality criteria, tolerances, methods, skills and producer/reviewer/approver responsibilities |
Quality Management Approach, register and records
The Quality Management Approach explains how quality will be managed across the project. At minimum, the source requires it to address quality control, project assurance, communication of quality management and the roles and responsibilities involved. In practice it should also make clear how organisational quality standards and procedures will be applied to the project.
The Quality Register summarises planned and completed quality activities. It allows the project manager and assurance roles to see what reviews or tests are due, whether they occurred and what evidence was created. It supports end-stage and end-project reporting because those reports should not rely on memory or informal statements that “testing was done”.
Quality records demonstrate the outcome of quality activities. Approval or acceptance records are especially important near closure. The source gives examples such as an approval email, certificate or meeting record, but the form is less important than the evidence: it should be clear what was approved, against which criteria, by whom and when.
Define
Agree overall expectations and acceptance criteria.
Describe
Write product-level criteria, tolerances, methods and responsibilities.
Plan
Schedule quality activities and record them in the quality system/register.
Perform
Carry out reviews, inspections, tests and in-process controls.
Record
Capture results, defects, corrective actions and approvals.
Accept
Confirm the overall project product against the agreed acceptance basis.
Assurance boundaries and practical governance
The source separates quality assurance from project assurance. Quality assurance is an organisational management function outside the project-management team. It checks that appropriate quality systems and standards exist and are being followed. Project assurance is a project-board responsibility, independent of the project manager, that checks whether the project is being directed and managed appropriately from business, user and supplier perspectives.
This distinction matters because the two functions answer different questions. A corporate quality function might audit whether required procedures were used. Project assurance might ask whether the selected quality controls remain sufficient for this particular project, whether acceptance criteria still match user needs or whether an apparent shortcut threatens the business case.
To apply the theme effectively, maintain traceability. Each important requirement should flow to a product and criterion; each criterion should have an agreed method and responsibility; each planned activity should leave a record; and each final product should have an approval or acceptance path. When any link is missing, quality becomes an assertion rather than evidence.
Practical verification checklist
- Record customer quality expectations in the Project Product Description.
- Convert expectations into prioritised, measurable acceptance criteria.
- Define controlled products and write Product Descriptions before scheduling their production activities.
- Specify quality criteria, tolerances, methods, required skills and producer/reviewer/approver responsibilities.
- Maintain a Quality Management Approach that explains control, assurance, communication and roles.
- Plan and record quality activities in a Quality Register or equivalent.
- Retain objective quality records and final approval/acceptance evidence.
- Review expectations and acceptance criteria when stages or circumstances change.
- Keep project assurance distinct from external organisational quality assurance.
Common mistakes to avoid
- Treating quality as final inspection rather than planned product definition and control.
- Using broad aspirations such as “high quality” as if they were acceptance criteria.
- Confusing Project Product Description with individual Product Descriptions.
- Failing to identify who reviews and who approves a product.
- Confusing project assurance with organisational quality assurance.
- Closing without traceable acceptance evidence.