PRINCE2® Quality Management

PRINCE2, as probably the best project management methodology, provides a simple, yet effective system for quality management. This article tries to explain the whole PRINCE2 quality management system simply, briefly, and clearly, without going much into details.

What’s Quality, in Plain English?

A quality product is one that is “fit for purpose”. An example, similar to that of the official manual, is the car oil pump. Do you expect your car oil pump to break every three months and have to change it? Of course not; this doesn’t fit your purpose. We expect a car’s oil pump to last for years. In a race car in contrast, the expectation for an oil pump is to last for one race! So, there are different expectations for these two types of oil pump, and it impacts how the product fits the purpose (quality).

High Quality!

We consider high and low quality levels in daily life, and always believe that a “higher” quality is better. The goal in project management is to identify the quality expectations, understand what fits the purpose, and then to create such a product. If we design and create a production line for race car oil pumps that last for ages, we’re probably losing money, because they don’t want the pump for more than one race. So, it’s not about having a “high” quality, but rather about having appropriate quality.

Step 1: Understanding Customer’s Quality Expectations

Obviously, the first step is to understand the customer’s quality expectations. For example, if you’re supposed to design and create a race car oil pump production line, you should start interviewing your customer to understand, document, and communicate their expectations.

This step is very basic, and should be done in the very beginning, in the Starting Up a Project process. We usually try to understand the customer’s quality expectations while we are also trying to understand the scope of the product. The result will be documented in the Project Product Description. The Project Product Description is a management product that defines the project as a whole, and is a part of our initial understanding of the project: Project Brief.

Even though we conduct this step in the beginning, we do not leave it as it is. We should always check it at the end of the stages. Sometime the customer’s quality expectations change because of external factors or any other reason.

Step 2: Defining the Acceptance Criteria

So, let’s say the customer expects the product to work more than one year. What should we do? Create it and use it for one year to see if it’s right?

Acceptance criteria are ways of proving that the product fits the purpose and matches the expectations of the customer. We usually use codes and standards for this, and may add our own criteria to complete specific needs. In case of a concrete structure for example, there are many well-known standards that define the way we should check the concrete structure to ensure desired quality.
The acceptance criteria are also part of the Project Product Description in the Project Brief. It might be elaborated in the initiation stage, and we need to check them for updates at the end of each stage. Any changes to the acceptance criteria should be approved by the Project Board.

The Project Product Description

I’ve mentioned the Project Product Description, so let’s talk about it a little. It’s a management product (can be a document, PowerPoint presentation, etc.) that defines what the project is supposed to deliver. Both the customer and the supplier should agree on the Project Product Description.

It’s created in the Starting Up a Project process; the first process that is run in the project. Then it will be refined during the Initiating a Project process, when we spend enough time planning the project. Finally, it should be checked for updates at the end of each stage, and if any changes are needed, they should be approved by the Project Board.

The Project Product Description is a special “Product Description” for the final product of the project, instead of the smaller building blocks that are the subject of normal Product Descriptions.

The Product Descriptions

A Product Description is a management product (can be a document) that defines a “product”. A product is either of the following:

  1. Specialist products: building elements of the final product of the project
  2. Management products: supportive products needed to ensure we can deliver the final product as defined. Plans and reports are examples of management products. Even a Product Description is a management product [that defines another specialist or management product].

Product Descriptions are really helpful, because they help both the customer and the supplier understand what will be produced in the project. Fewer surprises!

This is a common composition of a Product Description:

  • Purpose: why do we need this product?
  • Composition: what is it composed of? What are the building elements? This is the scope of the product.
  • Deviation: what are the sources?
  • Format and presentation: e.g. visual presentation aspects of a report or a concrete structure.
  • Development skills required: this part is not a detailed resource plan for the development of the product, but a simple explanation of the important points.
  • Quality criteria / acceptance criteria: we won’t know what we are expected to produce, until we know the quality criteria or acceptance criteria.
  • Quality tolerance: well, quality doesn’t have to be exact and we usually have a tolerance.

We have many Product Descriptions in a project. Besides that, we also have a high-level Product Description for the project as a whole, which is called Project Product Description. An additional part in the Project Product Description is the customer’s quality expectations.

Step 3: Preparing the Quality Management Strategy

OK, where were we? Yes, we talked about the first two steps, where we understand the customer’s quality expectations and turn them into practical acceptance criteria. The next step is to find a way of working that ensures the produced product will pass the acceptance criteria, because we don’t want to have the risk of rework and the waste of time, money, and credit.

This step is done in the Initiating a Project process, along with other planning activities. The result is some kind of framework for the quality management. This framework contains the PRINCE2 quality management system (a tailored version of course) and also covers the organizational quality standards/guidelines. It is called Quality Management Strategy.

Step 4: Planning the Quality in Detail

Now that we know the rules of the game (Quality Management Strategy), we should plan the quality in detail. We break the final product of the project and its supportive needs into multiple products and create Product Descriptions for them. Each Product Description explains the scope and the quality of that small building block.

These are the main elements we should define for each product:

  • Quality criteria: those measurable quality targets we talked about before. The product will not be accepted unless it passes all the criteria.
  • Quality tolerances: quality measures cannot be exact, and we need to have a tolerance level for them.
  • Quality methods: what quality activities should we implement to develop, review, and get the approval for the product?
  • Quality responsibilities: who’s involved in the quality of the product?

We don’t prepare all the Product Descriptions in the beginning of the project. Description for each product is prepared when we are planning its corresponding stage.

As mentioned before, codes and standards are great sources for defining both the quality criteria and “the way we should work” (part of the quality method). However, we usually need to add extra guidelines for our specific needs.

For example, standards about concrete structures give a lot of guidelines for the development that ensures we will pass the quality criteria (they also help define the quality criteria). For example, they explain what kind of water we should use for the concrete, what’s the maximum time we have between mixing the concrete and pouring it, and so on.

Product-Based Planning

You might have heard of “product-based planning”: the main planning methods used in PRINCE2, which is totally dependent on the product, instead of activities. Some of the previous steps are parts of product-based planning, when they are involved in creating the Project Product Description and decomposing it into Product Descriptions.

These are the product-based planning steps:

  1. Preparing the Project Product Description
  2. Creating the product breakdown structure (this helps decompose the final product into smaller pieces)
  3. Preparing the Product Descriptions
  4. Preparing the product flow diagram (the logical relationship between the building elements of the final product. Similar, but not the same as, a common activity network diagram)

Quality Planning

All the previous steps are types of planning. Quality planning is a sum of all steps mentioned before: understanding the customer’s quality expectations, defining the acceptance criteria, preparing the Quality Management Strategy [for the whole project], and preparing the quality criteria, tolerances, methods, and responsibilities for the building parts.

Quality Responsibilities

You remember that a part of quality plans in the Product Descriptions is the quality responsibilities. After all, PRINCE2 always pays a lot of attention to roles and responsibilities.

These are the general categories of quality responsibilities:

  • Producer: the person or group responsible for developing the product [with the desired quality]
  • Reviewer: the person or group responsible, independent of the producer, responsible for checking the quality of the product as defined in the Product Description.
  • Approver: the person or group responsible for approving the product to have desired quality, based on the assessment from the reviewer(s).

Yes, we need all of them defined for each product.

Step 5: Tracking the Quality / Quality Control

Now we know how to deliver quality and we should do so, following the plans. Meanwhile, we should also track it, to see if it’s going OK.

Quality management is not only about investigating and finding the faults, it’s more about preventing them, because it’s faster and less expensive. So, we follow the quality guidelines and activities we’ve identified to ensure the quality of the products. When a product is developed, we check it to see if it passes all the quality criteria. If it doesn’t, we should fix it. Meanwhile, all the information will be recorded to enable management control. The quality related information will be summarized in the Quality Register, and we usually have separate quality records with more information.

PRINCE2 also provides some information about the quality review technique (where we check the developed product), its responsibilities, agenda, and so on.

When the project is about to finish, we check the final product against the acceptance criteria before considering it closed.

Quality Review Technique

When a product is developed, its quality is checked in a quality review session.

These are the roles needed for the quality review technique:

  • Chair: the responsible person for the review session
  • Presenter: the person who presents the product, answers questions, and coordinates the actionable items after the session
  • Reviewer: the person or group that reviews the product and may suggest corrections or improvements
  • Administrator: records the results, etc.

Don’t worry, all the above are “roles”, and one person can be responsible for more than one.

The output of the session is a review result (complete, conditionally complete, incomplete), and may also be a list of corrective actions.

Higher-Level Quality Checks: Quality Assurance

Steps explained before are done inside the project organization. There’s also a higher-level quality check for both the specialist and management products of the project (including processes) done in the corporate/program level, called Quality Assurance.

Quality Assurance ensures the corporate/program that the project organization can deliver the project as defined. The way Quality Assurance is done is outside the scope of PRINCE2. You can check this article for more information about Quality Assurance.

Summary

To summarize, this is how we manage quality in the PRINCE2 environment:

  1. We start by understanding the customer’s quality expectations and identify the acceptance criteria, which will be stored in the Project Product Description, which in turn is a part of the initial definition of the project: Project Brief.
  2. Then we compose a Quality Management Strategy, which determines how we will satisfy the quality requirements of the project.
  3. Then we deepen our understanding by decomposing the final product of the project into its building parts and detailing their quality information before each stage.
  4. And finally, we develop the product based on the quality plan and keep assessing the outputs and recording the results.
  5. All the way, a higher level Quality Assurance is monitoring the performance and the quality of the product and process, to ensure the corporate/program management that the project will deliver what it’s supposed to.

The main point in PRINCE2 quality management is its integration with the product-based planning and the way it’s combined with the whole project management process. However, there’s no doubt that we should use other resources for quality management tools and techniques to succeed. PRINCE2 is all about the process and methodology, and tools and techniques are outside its scope.

 

Related Courses

The first 30% of all elearning courses is free: you can start taking the course now and see if it suits your needs.
background-grass-edge
Professional Training Center of Excellence N.V (Management Plaza™), Barbarastraat 13, 3120 Tremelo, Belgium
We are available 16 hours a day, 5 days a week, and you can contact us using the online chat box that is available on all pages, or via support@mplaza.pm email.

 

ITIL®, PRINCE2®, PRINCE2 Agile®, MSP®, M_o_R®, P3O®, MoP® and MoV® are registered trade marks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
PMI®, PMP®, PMBOK® Guide, OPM3®, and CAPM® are either marks or registered marks of Project Management Institute, Inc.
DSDM, Atern, and AgilePM are Registered Trade Marks of Dynamic Systems Development Method Limited.
PSM, Professional Scrum Master, PSPO, and Professional Scrum Product Owner are registered trademarks of Scrum.org.