Quality

Quality is something often discussed in project management, but many project managers struggle to understand it fully. Some organizations have a quality management system that sets out how to manage quality, but these systems are often limited to specific departments or product types, making them less useful for other projects.

Defining quality can be tricky, especially if you don’t know how to approach it. For example, if a sales manager requests a new sales system and you ask about quality requirements, they might struggle to answer. They might give you a list of features, but not provide clear expectations for quality. As project managers, it’s our job to ask the right questions to uncover these expectations.

If quality is not considered early on in the project, it’s hard to end up with a good, usable product. That’s why quality must be addressed from the start.

The good news is that PRINCE2 offers a simple and structured way to define, measure, and control quality throughout the project, ensuring a successful outcome.

Quality management in PRINCE2

The quality practice in PRINCE2 aims to establish a system that ensures products are fit for use and meet the required standards. It defines the PRINCE2 approach to guarantee that the products created during the project meet expectations and that the final product is usable as intended.

If quality is not as expected, the project will not deliver the anticipated benefits.

One of the PRINCE2 principles is product focus, which means that a project’s products should be clearly defined at the start or during a stage boundary process. This ensures that products are signed off (baselined) before development begins. The project plan and the stage plan should also include activities related to quality control.

The product description documents must include detailed quality criteria so all stakeholders have a shared understanding of the products to be created.

For example, if you are designing a new can opener, some of the quality criteria could be:

• Stainless steel and plastic handle should maintain their color for 20 years.
• Dishwasher safe.
• Mechanical parts must open at least 35,000 cans.
• Easy to use/comfortable to grip.
• Rust-resistant materials.
• Fits standard can sizes.
• Lightweight for easy storage.

As you can see, the quality criteria provide specific and measurable details about the product.

The quality practice in PRINCE2 offers a method to define quality, carry out quality control, explain how to get approval, and manage quality throughout the project.

Definition of quality

Quality has its own terms, and these terms can mean different things to different people. The terminology used by PRINCE2 comes mainly from ISO 9000 standard. Just read these definitions for now; they will be explained further in this chapter.

The following are the definitions used in PRINCE2:

• Quality: Quality is generally defined as the total amount of features or characteristics of a product, such that it meets expectations and satisfies the stated needs. This might seem strange, but think about it for a moment. It is the same as saying that all product features must work as expected for a given amount of time.
• Quality management: Quality management is defined as the activities that direct and control an organization with regard to quality. Some of these activities are: defining quality, quality control, quality assurance, and quality improvement.
• Quality management systems: A quality management system is the complete set of quality standards, procedures and responsibilities for a site or organization. The majority of bigger companies have a quality management system in place, so a good first question to ask is, “Do you have a QMS that can be used for this project?”
• Quality planning: For the project to meet the customer’s quality expectations and the acceptance criteria, the project manager must have a strategy in place. This involves identifying the necessary products and the quality criteria for each, planning quality methods (i.e. the necessary tasks for quality control and product acceptance), and designating quality responsibilities.
• Quality control: Quality control focuses on the techniques and activities to inspect and test products. This would also include looking for ways to improve quality and constantly remove less-satisfactory performance.
• Quality assurance: Quality assurance is similar to project assurance, but it focuses on ensuring that the quality processes in the organization are followed, not just within the project. Its role is to make sure that planned quality activities are completed.
  • It provides an independent review of the quality process.
  • It checks if the project complies with the company’s quality standards.
  • It ensures that proper quality processes are in place.

While project assurance is the responsibility of the project board, quality assurance is handled by the corporate or programme management. In short, quality assurance operates outside the project management team, while project assurance is part of the project team.

PRINCE2 approach to quality

PRINCE2’s approach to quality includes two key elements:

• Quality planning
• Quality control

Quality planning begins with identifying all the products the project will control. PRINCE2 focuses on products from the start of the project, or as soon as they can be described and agreed upon, before any development begins.

The next step is to create a product description for each product. This description includes:

• Quality criteria
• How the product will be assessed
• Quality methods for designing, developing, and accepting the product
• The responsibilities of the people involved

Quality control ensures that the planned quality methods are implemented and tracked throughout the project.

Part 1: Quality planning

Imagine you’re managing a project to build an apartment block for a mid-sized property developer. As the project manager, you need to collaborate with stakeholders like the customer, suppliers, and architects to define the quality expectations for the finished building and how quality will be controlled throughout the project.

Purpose

The following are the purposes of quality planning:

• Agree on quality expectations and acceptance criteria with the project board: Document the quality criteria (e.g., insulation type, materials quality, lighting fixtures, and relevant standards).
• Document how quality will be checked: Specify methods for checking quality, such as using independent building inspectors or internal staff measurements.
• Communicate these agreements to all stakeholders: Ensure all stakeholders have a shared understanding of what the project will deliver.
• Establish how quality will be controlled: Set baselines and tolerances for each product (e.g., wall insulation must be grade 5 with ±10% tolerance, kitchen fittings should last 18 years ±5% tolerance).

Without these discussions at the start, there can be misunderstandings and differing expectations about the project’s outcomes, leading to confusion and conflict.

Key questions to ask in quality planning:

• What are the customer’s quality expectations?
• How can we demonstrate that we meet each specification?
• What acceptance criteria will the customer use to accept products during or at the end of the project?

Steps/concerns

The following are the quality steps/concerns involved in quality planning:

• User’s quality expectations: Quality planning starts with documenting the user’s quality expectations, which are detailed in the project product description. It should include:
  • Major products to be delivered
  • User quality expectations and acceptance criteria
  • Relevant standards and procedures
  • Quality measurements
  • Quality tolerances for acceptance
  • This ensures requirements stay within scope and avoids unnecessary additions.
• Quality tolerances: Quality tolerances define the acceptable deviation before issues must be escalated. Since projects often lack resources to meet all quality standards, stakeholders and the project board should prioritize criteria and set tolerances to manage quality within limits.
• Describing products: Product descriptions capture key details like purpose, format, and quality specifications. These are essential for planning, scheduling, and quality control. Product descriptions evolve over time and are finalized when products are accepted, becoming part of regular operations.
• Product sustainability: Product descriptions should include sustainability criteria, addressing environmental impact and long-term viability. This ensures the product can continue delivering its benefits over its expected lifetime.
• Quality responsibilities: Quality responsibilities should be clearly outlined in the product description, including:
  • Producer: Responsible for developing the product
  • Reviewer: Assesses the product’s quality
  • Acceptance authority: Decides if the product is acceptable, which may be delegated by the project board.

The customer’s quality expectations

It is normally not an easy task to extract the quality expectations of a product from a client, and the answers you get can be very vague, but this must be done and must be done as early as possible in the project so that they can be listed in detail in the project product description. In some projects the project product description may be updated during the project in the stage boundary process. This is fine, as long as each change goes via the change control process.

Some companies may be in a rush to get the product out or have budgetary issues, so they think they can save on quality. I have even seen projects where the funds were scarce at the start, but once the product was out and customers were having issues, lots of funds were available to start fixing. This approach is always a lot more expensive and harmful for users.

Some good questions to ask to get the customer focused on quality:

What percentage of features should work when product is launched, and what is the budget for critical issues (e.g., fixes, recalls etc.)? Tip: Notice their reaction when you ask. What will be the cost to the company if the product cannot be used as expected at the end of the project (e.g., fines, keeping old product in service, etc.)? Prioritizing quality expectations: Use MoSCoW. They should be prioritized, starting with what the client finds most important.

Prioritize technique: MoSCoW: This will be discussed later. It stands for 1) must have, 2) should have, 3) could have, 4) won’t have for now. You could also use: High, medium, low or not required but MoSCoW is better.

Example of the customer quality expectations for an apartment block project

• Elevator safety (meet EC safety standard) - MoSCoW: M, measure: EC 34575, tolerance: None
• Elevator usable for blind people - MoSCoW: M, measure: Check, tolerance: None
• Outside noise in all apartments (standard: XC22) - MoSCow: M, measure: DB meter, tolerance: None
• All light fittings with a guarantee of 25 years - MoSCow: S, measure: Warranty, tolerance: ±10%
• Wall insulation should be R-11 - MoSCoW: S, measure: Inspection, tolerance: R11 to R12
• All window insulation R15 - MoSCoW: S, measure: Inspection, tolerance: R15 to R17

List acceptance criteria

The acceptance criteria is a prioritized list of attributes the project product should have when complete. This is agreed upon between the customer and supplier in the first process – the starting up a project process, and is therefore linked to the project product description.

The following is an example:

• Attributes are to be accepted (taken from the customer’s quality expectations).
• Prioritize status, such as “must have,” “should have” and so on.
• Accepted status: Yes / no.

Once the acceptance criteria list is complete, it will become part of the project brief. The acceptance criteria should also be prioritized using the MoSCoW technique.

Here is an acceptance criteria example for a website project:

• M: Users are able to use 90% of functionality without help
• M: Support costs lower than €5,000 per year
• M: Appearance to match the approved design layout
• S: Maintenance of all pages can be done by an existing support person
• M: Auto-password recovery, without the need for any human intervention
• M: Secure data area for registered partners

The project product description

Don’t confuse the project product description with the normal product descriptions. The project product description is a description of the main product that will be produced by the project. The project product description is created in the starting up a project process and becomes part of the project brief. The product descriptions are created in the initiation stage as part of the planning activity.

The ‘closing a project’ process helps verify that the project has delivered what was expected and that the acceptance criteria have been met using the project product description. A good example of a project product description I like to use is the information provided for a laptop computer on a computer website. There will be an overview description, features, specifications and guarantee information. See the websites of Dell, HP, and Asus, for example. As you can see, it does not have to be 100 pages but more like 2 to 4 pages.

Acceptance method

• All acceptance criteria have to be measured, inspected, and approved, and proof of acceptance will have to be given for each acceptance criterion.
• The project manager will make all documents available to the product development manager, S. Jones during the project.
• Acceptance responsibilities
• The project manager will collect all inspection, survey and other documents and hand them to the appropriate person(s).
• The executive will confirm project costs and manufacturing unit costs.
• Senior user will be responsible for all other acceptance criteria.

Quality management approach

A quality management approach is a document and a plan of action that defines the quality requirements and the quality control method for all the products in the project. This document also confirms how the quality systems and standards from the customer and supplier will be applied to the project. In other words, the quality management approach document defines how quality will be done in the project.

This document is created at the initiation stage with the other strategy documents and becomes part of the project initiation documentation.

The quality management approach answers the following questions:

• Which quality management system to use? i.e., from a customer, supplier or a mixture?
• What standards will be used?
• What tools and techniques will be used?
• How will quality assurance be carried out?
• Who is responsible for documenting the customer’s quality expectations and acceptance criteria?
• Who is responsible for quality assurance, approving the quality management approach, and confirming acceptance of the project product?
• What records will be required, and where will they be stored?
• How will the timing of quality activities be executed?

Product descriptions

The product descriptions should be created for all the products as part of the planning activities and before the project plan can be completed. This is not always possible in each project; therefore, product descriptions may be created or updated in the stage boundary process, and the product descriptions will be agreed upon and baselined before development starts.

The typical content of a product description is similar to the project product description. The contents are as follows (again, notice how much quality information):

• Identifier: Unique product name: e.g., 047.
• Title: Name by which the product will be known: e.g., 250-mb hard disk.
• Purpose: State who needs the product, why they need it, and what it will do.
• Composition: List the parts that the product will be made up of.
• Quality criteria: e.g. Color, noise, size, durability, lifetime.
• Quality tolerance: e.g. Color cannot fade in 10 years +-10%.
• Quality method: e.g. Use machine to test color fading; use inspection.
• Quality skills required: e.g. What knowledge is required to be able to test?
• Quality responsibilities: e.g. being responsible for producing, reviewing, and approving.
• Quality register

Quality register

The quality register is a diary of the quality events that take place during the project, such as workshops, reviews, testing and acceptance. At first, the quality register will be empty and the project manager will get most data from the plans and product descriptions. Many project managers use a spreadsheet as a quality register.

• Product ID: Just a product tracking number in the project (e.g., 124).
• Product name: A common name to refer to the product (e.g., “elevator”).
• Quality method: Describes how testing will be done. (e.g., inspection for the elevator).
• Producer: Who produces or installs the product, such as Otis (an elevator co.).
• Approver: Who quality-approves the product (ex: “John from safety company”).
• Target review date: When the product should be reviewed (ex: “June 20.”).
• Actual review date: Actual date that the review happened.
• Target approve date: When the project manager will get approval (ex: 1 week later).
• Actual approve date: Actual date when the project manager received approval.
• Result: This can be pass or fail.

The quality register makes it easier for the project manager to follow up on quality during the project, as they can check whether the actual target review date and actual approve date columns are filled in or not. This allows the project manager to control quality.

Full quality audit trail (quality history): As the quality register contains all the quality activities and is continually updated during the project, it provides a full audit trail for quality.

Part 2: Quality control introduction

What is quality control? Quality control is carrying out the activities to control quality as defined in the quality management approach. There are three parts to quality control, and I will explain each of them:

• Carrying out the quality methods: e.g., quality review techniques.
• Maintaining quality and approval records.
• Gaining acceptance and passing the acceptance record to the customer.
• Think about the columns in the quality register; it’s the same information.

Quality planning, quality control, accepting products

The quality register is used to:

1. Plan quality,
2. Control quality
3. Provide a history of quality activities in a PRINCE2 project.

Supporting techniques

Understanding the quality techniques and their timing, location, and resources is essential for project planning. While many quality techniques exist, the most common ones in project contexts are:

• Verification:
  • Ensures interim products (e.g., project design) meet quality specs and acceptance criteria.
  • Occurs during product design and development before the product exists.
  • Requires specialists in the relevant products or methods.
• Validation:
  • Confirms the product meets the quality specs and acceptance criteria.
  • Takes place during testing or after the product exists.
  • Requires specialists and may involve independent testing.
• Prototyping:
  • Produces a preliminary product for early feedback on functionality or production concerns.
  • Integral to iterative methods like agile; also used in beta testing.
  • Involves testing different product versions, such as in A/B testing.
• Testing:
  • Uses the product or its components under conditions similar to real-world use.
  • Occurs at various stages of development and delivery in different locations.
  • Supplier testing helps avoid costs and delays; operational testing confirms readiness.
• Inspection:
  • Confirms the product meets quality specs and acceptance criteria.
  • Typically occurs at delivery.
  • Mainly applies to commodities and off-the-shelf products.
• Certification:
  • Provides proof the product or supplier meets industry or regulatory standards.
  • Happens at delivery and requires minimal effort.
  • Applies to off-the-shelf products only.

Roles and responsibilities

Here are some of the responsibilities relevant to the quality practice.

• Business layer
  • Provide details of the corp or program quality management system.
  • Provide quality assurance to the project.
• Executive
  • Approve the project product description.
  • Approve the quality management approach.
• Senior user
  • Provides quality expectations and acceptance criteria for project product.
  • Approve the project product description.
  • Provide acceptance of the project product (end of project).
• Senior supplier
  • Provide resources to undertake supplier quality activities.
• Project manager
  • Document the customer’s quality expectations and acceptance criteria.
  • Prepare the project product description with other persons.
  • Prepare the product descriptions with other persons.
  • Prepare the quality management approach document.
• Team manager
  • Produce products consistent with product descriptions.
  • Advise the project manager of the product quality status.
• Project assurance
  • Give QMS advice to the project manager.
  • Assure the project board on the implementation of the QMS.
• Project support
  • Provide administrator support for quality control.
  • Maintain quality register and the quality records.

—o—

Written by Frank Turley.

If you have questions or doubts after using this wiki, you can ask for help on the Facebook or LinkedIn study groups.