Quality

Quality is something that project methods talk a lot about and it sounds great, but in reality, this is something that some Project Managers don’t understand. Some companies have a Quality Management System in place that describes how Quality should be done in that organization. Most often, this can be for specific departments in the company and may be only suited to specific types of products. Therefore, other projects cannot make use of this Quality Management System.

Quality can be difficult to define (if you don’t know how) and many people do not know how to explain it in a simple way. For example, let’s suppose the Sales Manager was asking for a new Sales system and you asked him to define the requirements. You will normally receive a list of requirements, but then if you ask them “What about quality?” or “What are your Quality Requirements?” you would leave them speechless, which may not be a normal state for a sales manager. So it is up to us as Project Managers to ask better questions.

Another point, if you don’t consider Quality at the start of your project, it is very difficult to end up with quality (a usable product). So, Quality must be addressed at the very start of the project

The good news is that the Quality Theme in PRINCE2 provides a simple solution for this. It describes how Quality can be defined, measured and controlled during the project.

The Quality Knowledge provided by PRINCE2

The purpose of the knowledge in the Quality Theme is to define and implement a system that will create and verify that products are fit for use and meet requirements. Hence, the Quality Theme defines the PRINCE2 approach to ensure that products created during the project meet the expectations, and that the end product can be used as intended.

If the quality of the products is not as expected, then the expected benefits that should be realized will not be achieved.

You might remember that product focus is one of the principles of PRINCE2, which means that a project’s products should be clearly defined at the start of the project or in a Stage Boundary process, so products are signed off (baselined) before development begins. The Project Plan and the Stage Plan will also include the quality control activities.

Product Description must include the Quality criteria information so that all project stakeholders have a common understanding of the products that will be created.

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

• Stainless steel and plastic handle should keep their color for 20 years.
• Dishwasher-proof.
• Mechanical parts must open 35,000 cans.
• Easy to use.

As you can see, the Quality criteria gives a lot more detail about the product.

So, the Quality Theme provides a method to help specify the Quality, to carry out Quality control, to explain how to get approved, and to facilitate the management of Quality during the project.

Quality Definitions

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.

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 a little strange, but think about it for a moment. It is the same as saying that all features of the product have to work as expected for a given amount of time.

Let me use the example of the can opener project. Think of the total amount of features or characteristics of the can opener, what a user might expect from the product, and how long they would expect it to last.

Scope

Scope is related to the scope of the plan, which is the sum of its products. It is defined using the product breakdown structure and the Product Descriptions. It can be clearly seen that Scope (of the project’s main product) and Quality are tied together.

Quality Management

Quality Management is defined as the activities to 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 on 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 constantly improve Quality and remove less-satisfactory performance.

Quality Assurance

This is like Project Assurance but the focus is on Quality in the organization and not just quality related to the project. It is to make sure that the planned Quality activities are done.

• Provides a way to get an independent review of the Quality process;
• Checks to see that it complies with company Quality standards; and
• Ensures that Quality processes are in place.
• Project Assurance is the responsibility of the Project Board, while the Corporate or Programme Management is responsible for Quality Assurance. You can also say that the role Quality Assurance is outside the project management team while Project Assurance is within the project management team.

PRINCE2 Approach to Quality

The PRINCE2 approach to Quality has two parts: Quality Planning and Quality Control

Quality starts with identifying all the products that the project wants to control. Remember that PRINCE2 is focused on the products from the start of the project – or as soon as they can be described and agreed, and before development starts.

The next step is to write a Product Description for each product, which includes Quality criteria, how the products will be assessed, Quality methods to be used to design, develop and accept the products, and the responsibilities of the people involved.

Quality Control implements and tracks the Quality methods used during the project.

Part 1: Quality Planning

Imagine a project that deals with building an apartment block. The customer is a mid-size property developer. As the Project Manager, you would need to be in agreement with the people who represent the customer, the supplier and other stakeholders (e.g., architects) and have an idea of the quality of the finished apartment block, as well as how Quality will be controlled during the project.

Purpose

The purpose of Quality Planning is to:

• Agree on the overall Quality Expectations and Acceptance Criteria with the Project Board:
• Document the Quality criteria (e.g., type of insulation, quality of materials used in the building, type of lighting fixtures and standards that must be meet).
• Document how the Quality Criteria will be checked (e.g., using independent building inspectors, own staff measurements, etc.).
• Communicate these agreements with all stakeholders:
• All stakeholders must have a common understanding of what the project will produce.
• Establish how Quality can be controlled during the project:
• Set baselines and tolerances for each product (e.g., wall insulation should be grade 5 with +- 10% tolerance; kitchen fittings should last 18 years +- 5% tolerance, etc.)

As you can imagine, if these topics are not discussed up front, it can make for a very exciting project with everybody having their own idea on the finished product.

The following questions should be asked in Quality Planning:

• What are the customer’s Quality Expectations?
• How can we prove that we meet each specification?
• What is the Acceptance Criteria that the Customer will use to accept products during or at the end of the project?

Quality Audit Trail

The first Quality Planning steps as shown in the diagram below are:

• Gather the customers Quality Expectations: This is very general, high-level
  • Key Requirements for the main product (Project Product) to be produced
  • Identify standards that must be met and the Quality Management System to use.
  • Measurements that can be used to assess Quality (speed, size, noise, etc.). E.g. Think of a Laptop PC description on a website (just 2 or 3 pages).
• Acceptance Criteria: Add the customer’s Quality Expectations and Acceptance Criteria to the Project Product Description (expectations that are measurable and prioritized).
  • Total building insulation must be grade 4 (Yes/No)
  • Yearly maintenance per apartment must be under €1,200 (Yes/No)
• Write the Project Product Description: This also includes adding the following Quality-related data to the Project Product Description:
  • The Project level tolerances – tolerance for the main product: e.g., outside noise-level has to be lower than a certain value +- x%
  • Acceptance method: stating how the Project Product will be accepted; and
  • Acceptance responsibilities – defining who will be responsible for accepting.
• Create the Quality Management Approach document: This document defines the agreed strategy for Quality in this project or, in other words, the rules of engagement for Quality during the project.
• Write Product Descriptions for each of the main products in the main product and include the Quality information, such as: This will be done for all the products that make up the main Project Product. E.g. Doors, walls, windows and fixtures.Quality criteria for each product and quality tolerances. Product-Based Planning (which will be discussed later) will provide a list of all products, and then you add the Quality information to each Product Description.
  • Quality method, (i.e., how to carry out quality checks after product is created).
  • Quality responsibilities for creating, quality checking and approving the product.
  • Lastly, set up the Quality Register. At first, it will be empty. You can get most of the data from the Plans documents (Product ID, Product Name, Producer, Approver, Target Review Date, Target Approve Date, etc.)

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 they may have budgetary issues so they think they can save on Quality. I have even seen projects where the funds were scarce at the start of the project, but once the product was out and customers were having issues, then lots of funds were available to start fixing. This approach is always a lot more expensive and bad 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 that the Project Product should have when complete. This is agreed between the Customer and Supplier in the very first process – the Starting Up a Project process, and is therefore linked to the Project Product Description.

See the following table; this is a good example:

• Attribute 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:

• Users 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 M
• Maintenance of all pages can be done by existing support person S
• Auto-password recovery, without need for any human intervention M
• Secure data area for registered partners M

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 to help verify that the project has delivered what was expected and that the acceptance criteria have been met uses the Project Product Description. A good example of a Project Product Description that I like to use is the information that is 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 or Asus for an 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 this proof will have to be given for each Acceptance Criterion.
• All documents will be made available to Product Development Manager, S. Jones during the project by the Project Manager.
• Acceptance Responsibilities
• 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.

The 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 are going to be applied in 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 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, 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 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. Responsible for Producing, Reviewing and Approving.
• Quality Register

The 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 will use a spreadsheet for a Quality Register.

• Product ID: Just a product tracking number in the project (ex: 124).
• Product Name: A common name to refer to the product (ex: “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 Review happened.
• Target Approve date: When Project Manager will get Approval (ex: 1 week later).
• Actual Approve date: Actual date when 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 pass Acceptance Record to the customer.
• Think about the columns in the Quality Register; it’s the same information.

Quality Planning and Quality Control

The following diagram shows the relationship between Quality Planning and Quality Control The Quality Register is used to:

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

The PRINCE2 Quality Review Technique

The PRINCE2 Quality Review technique is a Quality Inspection technique. It has defined roles and a specific structure to follow. The purpose is to inspect products to see that they meet the customer’s Quality standards and meet the Quality criteria listed in the Product Description.

The Quality Review technique has four specific roles. The roles are:

• Chair: Responsible for chairing the review meeting.
• Presenter: Presents the products and represents the producers of the product.
• Reviewer: Reviews products, submits questions, confirms corrections or improvements.
• Administrator: This person provides admin support for the chairperson (e.g., taking minutes and recording results and next actions).

Here is an overview of how a Quality Review meeting might be run:

• Chair would coordinate the introductions.
• The Presenter would provide a brief product introduction.
• Chair will invite each reviewer to ask questions about the product and if any further actions are needed. These are agreed and noted by the administrator.
• The Presenter can provide a product walk-through. Again, any required actions are agreed and noted. (Note: The Reviewer should also have seen the product before the * meeting, so the Presenter does not have go into detail.).
• Towards the end of the meeting, the Reviewer will read back the actions and responsibilities.
• Lastly, the Chair will decide if the product is complete, conditionally complete (few actions are yet required) or incomplete (another Quality Review meeting is required).

The next step after the product is completed is to request approval for the product. This is usually a signature from the person listed as approver in the Quality Register.

Objectives of the Quality Review Technique

• To assess the products against their agreed criteria.
• To involve key stakeholders and help to promote quality and the project.
• To provide confirmation that the product is complete (get agreement) and baseline.
• To baseline (sign off) the product so no more changes can be made.
• Results of the Quality review meeting and the Quality Register

The main output is a decision to quality-approve the products or not. These are:

• Complete: Mark at Pass in the Quality Register.
• Conditionally complete: Tidy up some minor issues; no need for another meeting. Note this in the Quality Register.
• Incomplete: Mark as Fail in the Quality Register. Create a new line for the next quality check.

To summarize, the purpose of the Quality Review technique is to inspect that the product is complete, and that it respects the customer’s quality standards and meets the quality criteria listed in the Product Description, and to identify any actions that are still required and promote quality.

Roles and Responsibilities

Here are some of the responsibilities relevant to the Quality Theme.

• Corp / Program Management
  • 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 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.