Guidance for effective quality management

in PRINCE2

Aligning with corporate and external standards

A starting point for any project in an organization is to identify whether the organization has a mandated quality management system.

It is frequently the case that more than one organization is involved in a project (for example, separate customer and supplier businesses). It follows that each may have its own quality management system. If the project has a single key commissioning organization, or is part of a programme or portfolio, a single established quality management system is more likely to apply. 

The project may also be subject to external quality standards (for example, when the project is within a regulated environment). These various circumstances must be addressed when determining the project's approach to quality.

PRINCE2 Quality and delivery approaches

It is important that the approach to managing quality works with, and supports, the chosen delivery approach, rather than working against it.

For example, when using an agile approach, the high frequency of quality checking (in the form of reviews, demos or tests) may have a significant impact on how a project is planned.

This will affect the incremental delivery of the project's products and how they are released This is especially true in IT situations where continual integration and automated testing are being used

Quality and projects within a programme or portfolio

Where the project is part of a programme or portfolio, the quality management approach for the programme or portfolio will usually determine the quality management approach for the project. 

Where there is already an established quality management system for projects, for example in a programme or portfolio, only the project-specific approaches will need to be documented.

Independent quality assurance 

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. Although PRINCE2 does not address quality assurance, it is good practice to include it in the project's quality management approach.

PRINCE2 - The customer's quality expectations 

The customer's quality expectations should be 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 will drive the choice of solution and, in turn, influence the time, cost, scope, benefits and risk performance targets of the project.

The customer's quality expectations are often expressed in broad terms to gain common understanding of the general quality requirements. These are then used to identify more detailed acceptance criteria, which should be specific and precise.

Identifying the acceptance methods is crucial because they address the question:

"How do we prove whether and when the project product has been completed and is it acceptable to the customer?"

This is particularly relevant in commercial customer/supplier arrangements, where acceptance criteria may be stated as part of a contractual agreement.

Where possible, the customer's quality expectations should be prioritized as they will be used as inputs to define quality tolerances for the project's products. 

The customer's quality expectations should be reviewed at the end of each management stage in case any external factors have changed them.

Even for a simple project, there must be a shared understanding between the senior user, senior supplier and project manager of the levels of quality required for the project's products.

The degree to which these need to be defined will vary depending on the products themselves and must be enough to avoid ambiguity.

PRINCE2 Quality responsibilities 

Be clear as to who is responsible for which aspect of quality. This is particularly important in commercial customer/supplier situations, where the contract needs to make clear what the quality expectations are, what acceptance criteria are to be used and how quality assurance and control will be done.

It is advisable to define the customer's rights of inspection and audit in terms of what can be inspected or audited, how often, and how much notice needs to be given for any inspection or audit.

If integrating a supplier's products with those from other parties, care should also be taken that the individual obligations with respect to verification are defined

Prioritizing acceptance criteria 

The project's acceptance criteria form a 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. 

When the project can demonstrate that all the acceptance criteria have been met (according to the priorities set), the project's obligations are fulfilled, and the project can be closed.
It should be recognized that it may not be possible to meet all the acceptance criteria and that the criteria may need to be prioritized

Evolving acceptance criteria 

It is important to recognize that little may be understood about the project's products during the starting up a project process.

Consequently, it is often the case that acceptance criteria will be refined and agreed during the initiating a project process, with each management stage providing further information which is incorporated through change control.

When finalized, acceptance criteria are subject to change control and can only be changed with the approval of the project board.

When an agile approach is being used, the project product description may be written in the form of an epic or a user story, with associated acceptance criteria. As such they can develop iteratively as the project proceeds.

Specifying PRINCE2 quality criteria in
product descriptions

Quality criteria specified in product descriptions need to be both specific and measurable.

For example, 'The user interface is lovely' is neither specific nor measurable. Instead the quality criteria need to be measurable, such as '70 per cent of users agree that the user interface is "easy to use" or better'.

However, care should be taken to write product descriptions in enough detail but not in too much detail.

Product descriptions that are too detailed can lead to an unnecessary increase in the cost of quality for the project, whereas incomplete or inaccurate product descriptions can lead to acceptance disputes if the delivered results do not match the customer's expectations.

Where necessary, the product description should reference supporting information, such as any applicable standards or specialist design documents.

A product description should include the quality criteria that the product must meet. These must be of enough detail and clarity to enable those reviewing a product to unambiguously confirm whether the product meets its requirements.

Quality tolerances, methods and responsibilities

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- 5°C?

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.

When 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.

Responsibilities are often described in terms of:

• 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 description
  
  
• Approvers(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.

In-process and appraisal quality methods

'In-process' methods 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 consultations.

A simpler approach to consider might include the use of quality inspections during the course of product development as well as upon completion.

'Appraisal' methods are used to assess the finished products for completeness and fitness for purpose.

There are 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
• quality inspection, if some professional judgement is required.

PRINCE2 Quality inspections 

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, 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). 

Quality inspection techniques are particularly applicable when professional judgement is required to assess the product's fitness for purpose. The techniques can be used within the project as quality controls, and by independent experts as part of quality assurance.

Peer and gateway reviews are examples of quality assurance activities that can be implemented by using or adapting a generic inspection technique.

Used as a project management team control, conducting systematic quality inspections can also have valuable team-building side-benefits.

PRINCE2 Quality records 

The quality records support entries in the quality register by providing the project manager and the project board with assurance that:
 

• products really are complete (and consequently that the related activities are finished)
• products have met their associated quality criteria and are fit for their intended purposes (alternatively there are records of any quality failures and corrective action)
• the agreed processes have been observed
• approval authorities and key product stakeholders are satisfied
• planned audits have been conducted and reported. 

Quality records should include references to the quality inspection documentation, such as a test plan, details of any 'defect' statistics and actions required to correct errors and omissions of the products inspected, and any quality-related reports (e.g. an audit).

When these records are received by project support, the quality register entries for the relevant products can be completed

During the project and at project closure, the quality records provide a valuable source of information for analysis in accordance with the PRINCE2 principle that projects should learn from experience.

For example, quality metrics, such as defect types and trends, can be used as a source of information for lessons and process improvements.

PRINCE2 Approval records 

Even though quality records provide evidence that each product has met its requirements as specified in its product description, it is good practice to obtain a record that the product has been approved.

PRINCE2 does not specify the format or composition of approval records as these will depend on the level of formality required, the customer/supplier relationship and the quality management system of the organizations involved.

The format for approval records could, for example, be a note in the minutes of a meeting, an email, a letter, a signature on a document or a certificate.

PRINCE2 Acceptance records

PRINCE2 uses the term 'acceptance' to describe the ultimate approval of the project's product.

Acceptance is frequently required from more than one set of stakeholders, for instance those using the project's products and those maintaining them (in which case both categories of stakeholder should have been involved in defining the relevant products, participating in quality inspections and granting approval during the course of the project).

Products are approved throughout the life of the project and ownership may even be transferred to the customer as part of a phased handover.

However, during the closing a project process, it is important to check that all forms of approval have been obtained and records kept for audit and/or contractual purposes.

Acceptance may be qualified and documented 'concessions' can be granted (e.g. if there are faults in the solution or some performance criteria have not been fully achieved).

Where concessions have been granted by the project board, it may be necessary to recommend follow-on actions for later improvements or remedies for the products concerned.

PRINCE2 Quality Responsibilities

Corporate, programme management or the customer

Project Board Executive

Project Board Senior User

Project Board Senior Supplier

Project Board Project Assurance

PRINCE2 Project Manager

Team Manager

Project Support

If you really MUST pass your PRINCE2 Practitioner Exam at first try - then you need to invest in our PRINCE2 Masterclass!

Click The Image Below to find Out More ...