A practical guide to quality management, assurance & control

One of the questions I’m asked often when I’m mentoring project managers, is what is the difference between quality assurance and quality management?

To be honest, that’s the wrong question to be asking.

Quality management is the overarching approach, concept, principle, technique – whatever you want to call it. It is made up of three elements:

• Quality planning
• Quality control
• Quality assurance.

Quality management is the term given to the techniques and standards used by the relevant people to achieve a quality result on the project – in other words, how you are going to make sure you end up delivering something good (or at least acceptable).

You can see that we can’t really compare quality management and quality assurance as one (assurance) is part of the other.

However, I know you still want to know the practical differences and similarities to make the terms stick in your head, so let me give you some more info on each of these, along with some examples from my project management experience.

Let’s start with quality planning, because that’s where we start on a real project: planning how we are going to get a quality result. I’ll also link the practice back to the PMBOK® Guide and Managing Successful Projects, the latest PRINCE2 manual.

Quality planning

Quality planning is the work you do at the start of the project (or throughout, if you are introducing a new deliverable later as part of a change, for example).

One of the project management principles in The Standard for Project Management is to build quality into processes and deliverables. So while we plan for it, the goal is to make it part of everything we do, built into the work as we go.

The activities include:

• Identifying the deliverables (which PRINCE2 calls products) and documenting expectations around customer satisfaction about what quality standards they will adhere to.
• Identifying and documenting quality requirements, specifications and acceptance criteria and how these will be checked e.g. metrics, product verification and validation, audits, testing.
• Coming up with the quality management approach to ensure the project team can meet the expectations, specification and criteria set.
• Identifying who will ensure quality responsibilities are met.
• Setting a quality baseline with the project board’s approval.

While you are finding out about customer requirements and documenting all the things you are going to do to ensure a good result, you’ll also be documenting the tolerances for each deliverable. You’ll also find out about any legislation or regulation that the project must comply with during this step.

What all this means is that you work out what a good quality project result looks like, and then plan how you are going to get there and who is going to do the work.

Quality planning example

I’ll be honest: most of my projects don’t have pages of detailed written down requirements. We don’t have the discipline of creating product descriptions or detailed specs. However, we do set acceptance criteria, even if these are only documented in the project charter or a high-level business request document.

The quality baseline represents the expectation of the result you’ll get at the end of the project, but that might change. For example, let’s say you are creating a landscaped garden for your client. The client asks for 50 species of plant in the garden and together you make a list, with a tolerance of +/- five species. That’s a quality expectation.

The quality responsibilities are set as follows:

Producer: This is the person responsible for the deliverable/product/work package. In this case, that’s you, the project manager.

Reviewer: This is the person responsible for checking the product meets its quality criteria. In this case, that’s the client’s head gardener.

Acceptance authority: This is the person (or group) responsible for final sign off of the deliverable. In this case, that’s the client.

However, in our garden project it turns out that you can’t deliver 50 species because certain species are too expensive/too invasive/don’t grow in the soil that your client has. So you change the spec and plan to deliver 40 species instead. This is below the tolerance level so requires a formal change.

The change also creates a change to the quality baseline (assuming the project board approves the change) because you can’t deliver the result the client wanted. There is no corrective technique to apply here: you can’t change the process to deliver a different result. You either have the plants or you don’t.

In a software project, you can do product testing, perhaps review the process design and operational techniques and tweak what you are doing to get a different result. For some projects, preventative action is possible, but you might not have that possibility on every project.

Quality control

The next aspect of quality management is control. Quality control is the work you do throughout the project to make sure that the products created are to the required specification. It’s the process of monitoring and checking quality.

PRINCE2 defines it like this (take a breath before you read this long sentence):

The procedures to monitor the specific products of a project and their development or delivery activities to determine whether they comply with relevant standards and of identifying ways to minimize causes of unsatisfactory performance.

Managing Successful Projects: PRINCE2 7th edition

The activities include:

• Doing the quality checking tasks (i.e. implementing whatever quality management approach you planned for).
• Being aware of and acting on situations where the quality of products is not up to standard, including continuous improvement.
• Getting approval for the deliverables created.

Quality control will help you spot defective products. If you think of software testing, the testing team is there to stop bugs making it into the final version. They spot quality issues before they reach the client so they can be resolved.

Quality control example

In our garden example, once the rockery is complete, the project manager would ask the client to sign off the finished product. The client compares what was delivered to the specification provided and approves the deliverable. In practice, the project manager will already have done that comparison and checked out that what they have delivered meets the spec.

We also installed a fountain, and there is a requirement to meet the appropriate standards for water quality. To check that, we hire an expert. Their quality control process involves checking the water every day for a month. The lab analyses the water and signs off that the fountain is compliant with standards. They provide certification as evidence.

Luckily for us, we already documented that we would need a testing lab to certify this deliverable as we figured that out during the planning stage. We planned for the lab costs in our project budget.

If the water didn’t meet satisfactory minimum requirements, we would take corrective action.

Quality assurance

Quality assurance the process of checking that the plans and approach are fit for purpose. Think of it as a confidence-boosting exercise for people who are not close to the delivery work but need reassurance that it is going to plan.

The activities include basically just that:

• Ensuring that the planning and control approaches are robust enough to deliver the expected results.

PRINCE2 defines effective quality assurance like this:

A planned and systematic activity that provides confidence that products will meet their defined quality specifications when tested under quality control.

Managing Successful Projects: PRINCE2 7th edition

In other words, it’s the process of making sure defects can’t happen (or are unlikely to happen) because you’ve done a good job of planning, building, checking in the first place.

Assurance is usually carried out by someone who is not in the project team. It’s an independent function as it seeks to check we’re doing the right thing. Often the function is provided by the PMO or another business team.

Quality assurance example

I’ve never had anyone say to me that my project management plans would not end up delivering a result that meets the quality criteria. Quality assurance is one part of project assurance, and it’s all about checking that things are done right.

In our garden example, you could imagine that another project manager from our company reviews our plans and comments that if we put the pond where we’ve planned, it would flood the walled vegetable garden every winter, and that wouldn’t be the right thing to do.

“Aha!” we say. And we move the pond.

Later, that other project manager visits again and checks we really have moved the pond.

Quality assurance vs project assurance

Project assurance is a much wider subject than simply quality assurance, so don’t confuse the two.

Quality assurance is all about making sure the project deliverables are a good enough standard and that the team follows all the good practice and plans they laid out. It should be done by someone independent from the project who can hold them to account and keep them honest.

Project assurance checks that the whole project is being done in the right way. Their role in quality assurance is to:

• Advise the project manager on anything to do with quality e.g. based on past projects or best practice
• Check that the approaches and control mechanisms proposed are actually going to deliver the results expected, and provide that level of confidence to the project board
• Check in regularly to ensure that what the project team said they would do, they are actually doing.

The assurance function holds the team accountable if they do not deliver.  

Differences between quality assurance and quality control

It’s common to get quality assurance and quality control confused.

Quality control is about checking products are fit for purpose during the making of the product. This is where you find the defects and fix them.

Quality assurance aims to prevent the defects from happening in the first place by creating a culture of quality. The differences are below in tabular form.

Aspect	Quality Assurance (QA)	Quality Control (QC)
Focus	Preventive	Corrective
Goal	Assures processes are followed correctly	Identifying defects in the final product and ensuring the product meets requirements
When Occurs	Throughout the project lifecycle	After the product is developed
Responsibility	Everyone in the team is involved	Specific team or individuals
Activities	Process-oriented, process improvement	Product-oriented, error detection
Tools	Process checklists, audits, reviews	Inspection, testing, sampling
Outcome	Compliance with standards and procedures	Defect detection and correction
Prevents Defects	Yes	No (but helps identify and fix them)

How to document your quality management approach/plan

PRINCE2 talks about writing the quality management approach in the project initiation document. The PMBOK® Guide talks about creating a quality management plan that is part of the overall project or program management plan.

Either way, if you have internal quality standards, you can reference them or link to the intranet page where readers can find out more. Don’t make the document longer than you have to by repeating yourself.

If you don’t have anything you can reference to save yourself a job, here’s what to include.

Scope: Describe what work is covered by the scope of the quality management approach. It’s probably easier to describe what is excluded, as pretty much everything is likely to be covered. Who doesn’t want their project result to be a reasonable quality?

Procedures: Describe the process for control e.g. “Product quality will be reviewed internally by the project team before being reviewed by the client’s team and signed off by the project sponsor on confirmation that they meet the specification.” Document what change control process you’ll use as well (probably the standard project change control process).

Resources and responsibilities: List out who does what (a RACI matrix is good for this) and any non-human resources required.

Tools and techniques: List out how you are going to check quality e.g. what testing methods or statistical techniques will be used, what product sampling sizes you will use etc. Split out quality assurance and quality control techniques.

Standards: Document any overarching quality standards and protocols the project has to stick to. You can also put PMO standards in here, like references to the templates you will use to create a log of deliverables (the quality register in PRINCE2). Link to any standard operating procedures.

Finish off with a list of any further reading or references like any internal policy documents or a note about the quality management system software that will be used if you have any.

Project quality management in the PMBOK® Guide

PMBOK 7 actually has very little in it that mandates how to approach quality. However, Process Groups: A Practice Guide does have all the info in about how to ‘do’ quality management. There are 3 processes:

Plan quality management: this is the process of creating the quality plan described above

Manage quality: this process is about assurance and process improvements

Control quality: this process is about recording the results of activities like testing to ensure the outputs are fit for purpose and meet customer expectations.

The quality balance

The unfortunate fact is that quality costs money. Doing more testing, checking, auditing, validation, having people trained to a higher standard… it all costs money.

There’s a balance for the project team and key stakeholders to strike between spending loads of money on quality and getting a ‘good enough’ outcome.

Next steps

If you’ve got this far, you’re probably planning how you are going to ‘do’ quality on your project. Here are some practical next steps to get going:

• Talk to stakeholders about their expectations of quality.
• Check the business case or any other initiation documentation to see what quality criteria have already been mentioned.
• Talk about tolerances: are there any that are acceptable? Often there are not, or they aren’t easy to negotiate.

Document what you find and then work out how you are going to achieve that. Cross-reference the plan and make sure there are tasks that allow you to deliver on those requirements – check you have a way to build them in and test them.