About us
Useful Links
PRINCE2 Exam Guide
PRINCE2 Master Class
PRINCE2 Structure
Handling Issues
Management by Exception
Project Board Guidance
Tailoring PRINCE2

 Management products will be mentioned in the following sections – it may be an idea to refer to these in Appendix A of the PRINCE2 manual as you read through. All Management products are shown in italic.


The thing about quality in any project is that it isn’t a stand-alone area. It will be important to ensure that we understand the Customer Quality Expectations as early as possible in the project and that we refine our understanding of these into Acceptance Criteria for the project as a whole. Both of these are documented within the Project Product Description during its creation in SU. But this effort is wasted if we do not then have a mechanism within the project for demonstrating that we have actually delivered products which meet both the functional and quality requirements of the Customer.

PRINCE2 provides such a mechanism via the Quality Review technique. It is at this point that the delivered product is checked against its specification (represented in PRINCE2 projects by the Product Description of the product). Of course if all products pass these checks then we are almost certain to gain overall acceptance – there would be no reasonable justification on the part of the Customer to withhold this acceptance.

However, the story so far still does not hold water. We have documented what the Customer wants, built the product and checked it against its specification and everything is fine. But what do we do about any proposed changes to these products (both completed and uncompleted)? We will obviously need another mechanism to ensure that these changes are properly considered and that only changes approved by the Customer are actually implemented. We define this mechanism as the Change Control Approach and include it within the Quality Management Strategy – a big hint here that Quality and Change Control are intimately linked.

And there is a further consideration. If we are going to define how to consider and include changes to products during the lifetime of the project, how are we going to prevent unauthorised changes? The only way to do this is to ensure that our products are tightly controlled and protected from such actions (whether well-intentioned or malicious). This is where Configuration Management comes in; we create a Configuration Management Strategy. This provides the final piece of the jig-saw by documenting how we are going to identify, track and control our products and by defining the responsibilities for these within the Configuration Librarian role.

The three elements which, together, can deliver provable quality products are now assembled. But note the sting in the tail – if any 1 of these elements fails to work correctly in the project, then all 3 are rendered useless.

The Quality audit trail

PRINCE2 ensures that Quality is addressed throughout the project and, indeed, is never far from the surface. The best place to start in order to gain an understanding of how quality is achieved in a PRINCE2 project is the Quality audit trail, as shown below

This diagram needs some explanation to provide a coherent story about quality. In particular, we will need to consider the Change Control and Configuration Management elements which enable the project as a whole to deliver quality products which reach the Customers expectations.

It will be convenient to break this diagram up into the 2 areas shown:

Quality Planning;

Quality Control.

Quality Planning

Our first exposure to Customer Quality Expectations (CQEs) may be found on the Project Mandate, which triggers the overall SU process. If this is not the case then we will examine and understand the CQEs during the creation of the Project Product Description within SU. This management product should define a list of what makes the final product acceptable to the Customer and, as such, it should be relatively simple to derive Acceptance Criteria from it.

CQEs seek to make explicit, for example, that a QMS may be in place that needs to be followed as the project progresses – the Customer expects our project processes to be mapped onto the corporate quality systems and for us to conduct the project according to the procedures defined within that QMS. Refer to the product in Appendix A of the Manual for further details.

In the sub-process “Select the project approach and assemble the Project Brief”, various ways of delivering a solution to the project requirements are considered, and each may have a significant impact on the actual (quality) results which can be delivered. For instance, if the project was to deliver a timing system for a running track, we might consider 2 possible alternatives:

A man with a stopwatch:
An Omega electronic timing system.

The net result of choosing one or other of these approaches will have inevitable consequences for measures such as timing accuracy and repeatability (both quality measures of the final product). Naturally, it would not be possible, in the first instance to deliver an Acceptance Criterion of, say, 1/1000th second timings (an Accuracy criterion) and so the Approach and the requirement(s) need to be considered together. One may deny the other.

This early thinking about Quality (requirements and acceptance) is agreed during IP when the Quality Management Strategy is created. It is also refined with further thinking about any external factors which may have a bearing on Quality achievement. All external standards (including the corporate QMS) need to be part of the quality documentation within the Quality Management Strategy.

For example, if the project is to deliver a new IT system which deals with personal details of our customers, then we must take into account the requirements of the Data Protection Act (and possibly the Freedom of Information Act and many others). These 2 Acts can have a fundamental impact on the project deliverable in the sense that we will have to construct the IT system in such a way as to comply with them. In other words, complying with these Acts adds requirements to the project (and in this sense they are quality requirements since they are over and above the original functional requirements of the system).

You may wish to think through another project example in which the project is to build a new office block. The Customer mentions the new Disability Access Act and the need to take this into account in the construction and fit-out phases. How would this affect the final deliverable?

So, at this point (IP) we have a Quality Management Strategy which contains both the (internal) CQEs and Acceptance Criteria and relevant extracts of the (external) standards and Laws etc which will have a bearing on the project. It is not yet complete. As pointed out above, quality does not work in the absence of a workable Change Control Approach (CCA) and Configuration Management (CM) of the completed products. We therefore also document the CCA within the Quality Management Strategy and create a Configuration Management Strategy.

The Change Control Approach can be the simple flowchart approach shown in the PRINCE2 manual, but consideration must be given here to the level of authority given to the PM to make decisions about changes (such as Request for Change, Off Specification or general project issues). It should be remembered that PRINCE2 identifies the PB as having responsibility for decisions on change, but Management by Exception often leads to the authority being delegated. When this is considered in conjunction with another PRINCE2 tenet – that “once approved, the PM should not authorise any product change without the approval of the PB”, then the importance of documenting the CCA early in the project can be appreciated.

Similarly, having a documented Configuration Management Strategy means that we have a system for controlling and protecting our products throughout their lifecycle(s). Only approved changes will result in products being released from CM for change and unapproved changes will be a thing of the past.

The Quality Management Strategy, therefore, summarises the Quality regime that the project is operating under by taking account of the three legs of our triangle (shown earlier).

Since we will need to track (and report on) the quality activities of individual specialist products during successive project Stages, a blank Quality Register is also created within IP for this purpose.

Now that the Quality Management Strategy exists it will be used extensively to ensure that as we plan, execute and complete each product, the various requirements within it are included in individual Product Descriptions. In other words, each Product Description must address any relevant quality requirements for this product. Examination of the Product Description shows that it documents the following quality considerations (derived from the Quality Management Strategy).

Quality Criteria (quality specification, measurement and standards relevant to this product);
Quality method (test, inspection or review);
Quality tolerance;
Quality check skills required/people required.

After IP, we will use the Plans Theme during SB for the:
creation of the next Stage Plan at a Stage boundary);
creation of an Exception Plan at any point within any Stage).

Each of these activities will generate the requisite Product Breakdown Structures and Product Descriptions, so we now know what the product(s) specification(s) are – what we now need to do is plan for the quality checking activity. Here we identify the timings and resources for the quality check (remember the recommended PRINCE2 technique for this is Quality Review). Adding these activities to the Stage Plan effectively transforms it into the Stage Quality Plan. Our plans now include both the product creation activities and the quality checking activities.

Quality Control

As each plan is executed, Work Packages are issued to Team Managers (TM). Crucially, the Product Description(s) of the products are “attached” to this document, and so all requirements (functional and quality) are now in the hands of the TM. Additionally, the Work Package also defines the Configuration Management requirements for the product(s) contained within it, derived from the Configuration Management Strategy mentioned earlier. The TM now begins the creation of the product and arranges for the Quality Review (or other defined method) to be conducted on completion. The Quality Review compares the product against its specification (Product Description) with the ultimate aim of identifying and correcting errors, leading to sign-off of the product. The TM initiates the Quality Review by referring to an extract of the Stage Quality Plan to see who should be conducting this activity and when. This extract is also included in the Work Package. Once sign-off has been obtained, the TM updates the Quality Register to provide an objective measure of progress for the PM and also arranges for the product to be transferred to the Configuration Management system (handover to the Configuration Librarian). Our products are now built to specification, checked, signed-off and protected from uncontrolled change.

The only remaining consideration is what to do in the event of an issue arising, such as a Request for Change. This could be for a product we have completed, a product currently under development or even a product that has not been started. The process is the same for all – we follow the Change Control Approach defined in the Quality Management Strategy – no ad-hoc decisions are either allowed or needed. Do it the way you planned to do it!

The triangle is now complete!


The Quality audit trail diagram shown above describes a fairly continuous thread through PRINCE2, concentrating on the Quality aspects of a project. What we have seen above is that it is also entirely dependent on the Change Control and Configuration Management elements to make it successful. You will never be able to guarantee the quality of a product if you have left the door open to uncontrolled change (and uncontrolled change is always possible if you are not protecting your products).