The PRINCE2 Quality theme:


  1. Provides a common understanding of what the project will create = the Scope
  2. Defines the Acceptance Criteria which the project's products will be assessed = the Quality
  3. Thus ensuring that products are fit for purpose
  4. Meet the quality expectations of customers and users
  5. Defines the Quality Management activities, required in the project's plan
    1. This allows the full project cost and timescales to be estimated
    2. If omitted / overlooked is likely to lead to slippages, overspends and/or poor quality results
  6. Covers Continuous Improvement during the project
    1. e.g. to introduce more efficiency into the management of the project and it's products
    2. Capturing & acting upon Lessons Learned

What is Quality?

Quality is generally defined as the totality of features and inherent or assigned characteristics of a product, person, process, service and/or system that bear on its ability to show that it meets expectations or satisfies stated needs, requirements or specification.
In PRINCE2, a product can also be a person, process, service and/or system, so the focus of quality is on a product's ability to meet its requirements.




The scope of a plan is the sum total of its products. It is defined by the product breakdown structure for the plan and its associated Product Descriptions.



Quality Management and Quality Management Systems

Quality management is defined as the coordinated activities to direct and control an organization with regard to quality.


A quality management system is the complete set of quality standards, procedures and responsibilities for a site or organization. In the project context, 'sites' and 'organizations' should be interpreted as the permanent or semipermanent organization(s) sponsoring the project work, i.e. they are external to the project's temporary organization.



Quality Planning

To control anything, including quality, there must be a plan. Quality planning is about defining the products required of the project, with their respective quality criteria, quality methods (including effort required for quality control and product acceptance) and the quality responsibilities of those involved.


Quality control

Quality control focuses on the operational techniques and activities used by those involved in the project to:

  • Fulfil the requirements for quality (for example, by quality inspections or testing)
  • Identify ways of eliminating causes of unsatisfactory performance (for example, by introducing process improvements as a result of
    lessons learned)


Quality Assurance

Quality Assurance provides a check that the project's direction and management are adequate for the nature of the project and that it complies with relevant corporate or programme management standards and policies. Quality assurance activities are outside the scope of PRINCE2 as it is the responsibility of the corporate or programme organization.


Quality Assurance is about independently checking that the organization and processes are in place for quality planning and control (i.e. not actually
performing the quality planning or control, which will be undertaken by the project management team). It provides the project’s stakeholders with confidence that the quality requirements can be fulfilled.
The term 'quality assurance' is used in two senses:

  • As the function within an organization (or site or programme) that establishes and maintains the quality management system
  • As the activity of reviewing a project's organization, processes and/or products to assess independently whether quality requirements will be met


The PRINCE2 approach to Quality

The specific treatment for quality in PRINCE2 is the focus on products from the outset, requiring systematic activities to:

  • Identify all the project’s products (i.e. to the level at which the project intends to exert control)
  • Define them in Product Descriptions – including the quality criteria by which they will be assessed; the quality methods to be used in
    designing, developing and accepting them; and the quality responsibilities of those involved
  • Implement and track the quality methods employed throughout the project

The first two of these are covered by quality planning and the last is covered by quality control and quality assurance.


The figure to the right shows the Quality Audit Trail:


Quality Planning ensures:

  • Project Board agreement on the overall quality expectations, the products required with their associated quality criteria (including corporate and other standards to be observed), the means by which quality will be achieved and assessed and, ultimately, the acceptance criteria by which the project's product will be judged
  • Communicating these agreements unambiguously so that all the project stakeholders have a common understanding of what the project is setting out to achieve
  • Control, i.e. establishing an effective baseline for the project’s quality controls (including the quality tolerances) and a secure means of achieving products that are fit for purpose

Quality Planning comprises:

  • Understanding the customer’s quality expectations
  • Defining the project’s acceptance criteria
  • Documenting the customer’s quality expectations and the project’s acceptance criteria in the Project Product Description
  • Formulating a Quality Management Strategy
  • Writing clear Product Descriptions containing quality criteria, quality tolerances, quality method and quality responsibilities
  • Setting up the Quality Register

The Customer's Quality Expectations are a statement about the quality expected from the project product. They are defined and agreed early in the Starting up a Project process. The expectations are captured in discussions with the customer and then refined for inclusion in the Project Product Description. To avoid misinterpretations and inaccurate assumptions about the project's quality requirements, the customer’s quality expectations should cover:


  • The key quality requirements for the project product
  • Any standards and processes that will need to be applied to achieve the specified quality requirements, including the extent to which the customer's and/or supplier's quality management system should be used
  • Any measurements that may be useful to assess whether the project product meets the quality requirements (for example, existing customer satisfaction measures)

Example of Quality Expectation

The quality expectation for a water pump in a remote village is that it is robust enough to 'last a lifetime', whereas because the oil pump in a racing car needs to be as light as possible, it may only need to last the duration of one race.



The project's Acceptance Criteria form a prioritized list of measurable definitions of the attributes required for a set of products to be acceptable to
key stakeholders. Examples are ease of use, ease of support, ease of maintenance, appearance, major functions, development costs, running costs,
capacity, availability, reliability, security, accuracy, and performance.
Acceptance Criteria should be prioritized as this helps if there has to be a trade-off between some criteria – high quality, early delivery and low cost, for example, may not be compatible and one of them may need to be sacrificed in order to achieve the other two.

Example of a prioritization technique – MoSCoW

Each Acceptance Criterion is rated as either Must have, Should have, Could have or Won't have for now (MoSCoW).


All the 'Must have' and 'Should have' Acceptance Criteria should be mutually achievable.

When the project can demonstrate that all the Acceptance Criteria have been met, the project's obligations are fulfilled and the project can be closed. The acceptance criteria should be agreed between the customer and supplier during the Starting up a Project process and documented as part of the Project Product Description. It is important to recognize that little may be understood about the project's products at this early point.


Consequently, it is often the case that acceptance criteria will be refined and agreed during the Initiating a Project process and reviewed at the end of each management stage. Once finalized in the Project Product Description, acceptance criteria are subject to change control and can only be changed with the approval of the Project Board.

Example of Acceptance Criteria

If a customer's quality expectation for a water pump is that it 'lasts a lifetime', the acceptance criteria should focus on those measures that provide sufficient indication or confidence that the pump is capable of lasting a lifetime (defined as a specific number of years). This may include complying with certain engineering standards relating to product durability.



The Project Product Description is created in the Starting up a Project process as part of the initial scoping activity and may be refined during the Initiating a Project process when creating the Project Plan. It is subject to formal change control and should be checked at stage boundaries (during Managing a Stage Boundary) to see if any changes are required. It is used by the Closing a Project process as part of the verification that the project has delivered what was expected of it and that the acceptance criteria have been met.


The Project Product Description includes:

  • The overall purpose of the product
  • Its composition (i.e. the set of products it needs to comprise)
  • The customer's quality expectations
  • Acceptance criteria, method and responsibilities
  • Project-level quality tolerances

The approved Project Product Description is included as a component of the Project Brief and is used to help select the project approach. The Project Product Description defines what the customer is expecting the project to deliver and the project approach defines the solution or method to be used by the supplier to create the project product.


The Project Product Description is a special form of Product Description in that it includes the customer’s quality expectations and, at this level, the quality criteria and quality methods constitute the acceptance criteria and acceptance methods for the project overall.



The Quality Management Strategy is prepared during the Initiating a Project process and approved subsequently by the Project Board. It augments the project approach and can be regarded as the project management team's proposals in response to the customer's quality expectations and acceptance criteria.


The Quality Management Strategy:

  • Describes how the quality management systems of the participating organizations will be applied to the project and confirms any quality standards,procedures, techniques and tools that will be used
  • Where models and standards are to be tailored, the tailoring should also be outlined in the Quality Management Strategy for approval.
  • Provides a means by which the levels of formality to be applied in the quality plans and controls can be scaled and agreed according to the particular needs of the project
  • Outline the arrangements for quality assurance, including independent audits where these are required by the policies of the participating organizations

Key responsibilities for quality should be defined (both within and outside the project management team), including a summary of the approach to Project Assurance. Where there is already an established quality management system for projects, for example in a programme, only the measures specific to this project may need to be documented.


The Quality Management Strategy is maintained, subject to change control, throughout the life of the project.



Once detailed planning gets underway, Product Descriptions should be created for all of the project’s products. Product Descriptions are not optional.  They govern the development of the products and their subsequent review and approval.


The level of detail in a Product Description is a matter of judgement, with the primary aim being to select a level that provides a secure and appropriate measure of control sufficient to fulfil the customer’s quality expectations.


The purpose section of the Product Description should clearly state who needs the product, why they need it and what it will do. In addition to the purpose, the sections specific to quality are: quality criteria, quality tolerances, quality methods, quality skills required and quality responsibilities.


These define the quality controls that must be applied during product development and in the review and approval procedures for the completed product.



The Product Description should include the quality specifications that the product must meet, and the quality measurements that will be applied by those inspecting the finished product. The Quality Criteria should be of sufficient detail and clarity to enable those reviewing a product to unambiguously confirm whether the product meets its requirements.


Quality Tolerances for a product can be specified in quality criteria by defining an acceptable range of values. For example:

  • Is the duration of the presentation 30 minutes (plus or minus 5 minutes)?
  • Is temperature maintained in the range of 1 to 5°C?

Example of Quality Criteria

Consider a project to design and manufacture a new camera. One quality criterion is that the camera and its packaging must weigh no more than 1 kg. The product breakdown structure identifies a user guide product. It follows that the size and weight of the user guide is an important factor and not, for example, the number of pages.


Questions to be asked include: What is the target market for the camera? Does this also imply that the manual needs to be written in several languages? Will that mean it gets heavier? Or will a CD-ROM-based manual suffice? This could reduce the weight of the manual and allow the camera itself to be heavier.


Considering quality criteria often highlights connections and factors such as these which inform the subsequent planning process.


The Quality Methods section of the Product Description is used to specify the quality activities to be implemented during the development of a product, for review and approval on completion. Where specialized skills are implicit in the quality methods, these should also be specified. There are two primary types of quality methods: in-process methods and appraisal methods.
To avoid doubt, the Quality Responsibilities for a product should be specified. The responsibilities will fall into one of three categories:

  • Producer The person or group responsible for developing a product
  • Reviewer(s) A person or group independent of the producer who assesses whether a product meets its requirements as defined in its Product
  • Approver(s) The person or group, for example a Project Board, who is identified as qualified and authorized to approve a product as being complete and fit for purpose


The Quality Register is effectively a diary of the quality events planned and undertaken (for example, workshops, reviews, inspections, testing, pilots, acceptance and audits). It is created during the Initiating a Project process as the products and quality control measures are being defined. It is then maintained (in line with the current baseline plans) throughout the project.



Quality Control

Quality control is achieved by implementing, monitoring and recording the quality methods and responsibilities defined in the Quality Management Strategy and Product Descriptions (and subsequently agreed to in Work Packages). Quality control comprises:

  • Carrying out the Quality Methods
  • Maintaining quality and approval records
  • Gaining acceptance


The cost of correcting flaws in products increases the longer they remain undetected. It is much easier and cheaper to correct a design document early in the project than to correct a design fault that is only discovered when the finished product is being tested or, worse, when the product is already in operational use. It follows that quality inspections, implemented early in the design and development process, are potentially the most cost effective
quality methods available. There are two types of quality methods:

  • 'In-process' methods These are the means by which quality can be ’built into’ the products as they are developed. These might involve the use of specialist methods and/or techniques, including calibrated process controls, automation (e.g. robotics, software tools), piloting exercises, workshops, surveys and consultation, or, more simply, the use of quality inspections during the course of product development as well as upon completion
  • Appraisal methods These are the means by which the finished products are assessed for completeness and fitness for purpose. There are, in essence, two types of appraisal methods, depending on the extent to which it is possible to define objective quality criteria: testing (if the quality criteria are truly objective and quantifiable) or quality inspection (if some subjective judgement is required)

A quality inspection is a systematic, structured assessment of a product conducted in a planned, documented and organized fashion. A systematic
but flexible approach to quality inspection can be used:

  • During the development of products of this type, whether formally (i.e. in line with what was agreed during quality planning) or informally (simply as a means of assessing the quality of a ’work in progress’)
  • To mark the completion and approval of products
  • To complement testing, e.g. simply for checking test results



The PRINCE2 quality review technique


  • To assess the conformity of a product which takes the form of a document (or similar item, e.g. a presentation or test results) against set criteria
  • To involve key interested parties in checking the product’s quality and in promoting wider acceptance of the product
  • To provide confirmation that the product is complete and ready for approval
  • To baseline the product for change control purposes

Review team roles:

  • Chair This role is responsible for the overall conduct of the review
  • Presenter This role introduces the product for review and represents the producer(s) of the product. The presenter also coordinates and tracks the work after the review, i.e. applying the changes to the product agreed by the team
  • Reviewer This role reviews the product, submits questions and confirms corrections and/or improvements
  • Administrator This role provides administrative support for the chair and records the result and actions

The minimum form of review (used for simple inspections, e.g. of test results) involves only two people: one taking the chair and reviewer roles, the other taking the presenter and administrator roles
Note: quality review is a generic technique which can be used outside the project context. Thus the quality review roles have no specific relationship to roles in the project management team structure. However, team-building benefits can be realized where Project and Team Managers regularly chair reviews. Chairing quality reviews requires competence in facilitation and independence of the product being reviewed (the primary responsibility is to ensure that the review is undertaken properly)


Leave a Reply