Project Quality Plan: The Easiest Guide (With Template)

The big risk as a project manager is that you hit all the project management success criteria: being on time and on budget, but what you deliver doesn’t meet the customer’s requirements.

That can happen for a lot of reasons, but one of the main causes is that you didn’t know what good looked like before you started. A project quality management plan can help with that. In this article, we’ll talk about how to write one and why you should. Plus I have a template to share with you.

The basics: What is a quality management plan?

A quality management plan is a document that sets out how the expectations for the project will be achieved. It is part of the project management plan.

In my experience, I’ve never written a bumper project management plan. I’ve always written several different plans and then (sometimes) had a document that references them all. Sometimes it is worth doing a project management plan and then calling out references to one or two specific other documents.

For example, I rarely write a specific risk management plan because I can just reference the PMO’s standard risk management approach which is published on the intranet. But if my project included a lot of procurement, I might write a separate procurement management plan.

The quality plan talks about how you are going to make sure that the project delivers a quality result. So what does a quality result look like?

What quality looks like

It’s hard to define quality in project management. There are so many different types of projects, each with specific goals. There is no definitive answer for how to measure quality in project management. Unfortunately.

‘Quality’ means different things to different people, so you will have to ask stakeholders what they are expecting from the project and then help them translate those into quality criteria.

Sometimes it’s easy: the website search button must a result within 0.2 seconds. Each toy brick must be 1.5cm by 3cm. The new product must be ready by 25 June.

Sometimes it’s hard, especially when the output supports organizational transformation, culture change, or something else that is difficult to quantify. Give it a go anyway; you might be surprised at what you can come up with.

Here are some suggestions of what you could suggest to stakeholders as the basis for quality metrics. The two biggest ones are:

• Performance: How is the thing supposed to work and does it do what it is supposed to do?
• Conformity: Is the thing fit for purpose? Can we use it? Does it meet the specifications as set out in the requirements?

And here are some others:

• Sustainability: Does the thing support sustainability goals? Has it been created with sustainability in mind?
• Uniformity: If you are making lots of things, are they all the same?
• Reliability: Does the thing work on a reliable basis? Are the results you get from it consistent?
• Customer satisfaction: Do people like the thing? Is the user experience good? Are they recommending it to their friends and colleagues?

Where are quality requirements documented?

So where do you get an idea of what stakeholders want?

The expectations for performance levels i.e. the quality expected from the project are probably documented in the exit or completion criteria, the business case, requirements documents, use cases or a statement of work. Any of these might include quality targets.

Failing that, use the list above to talk to team members and the wider stakeholder community and get some ideas.

The contents of a quality management plan

You have your quality requirements. You know what good looks like and what your quality goals should be. Now it’s time to create a quality management plan.

The plan can include:

• Roles and responsibilities: Who will do the quality management tasks (e.g. external quality inspectors, quality manager)
• The quality assurance plan and approach
• The quality control approach and what activities are going to be scheduled for quality management
• The plan for how ‘continuous improvement’ is going to happen
• Any quality management system, tools, or processes that are going to be involved, for example, the process for dealing with corrective actions
• The quality standards and acceptance criteria that the project must stick to.

This is what I would include in my project quality document. There is no definitive list, so if you want to add in a section or delete one, just do it. Make the document relevant to your project.

As you can see, the plan mentions quality assurance and quality control. There are 3 processes in project quality management, and they are the other two (along with quality planning).

Quality assurance (QA)

Quality assurance activities are all about making sure there is a culture of quality. It sums up different ways of work to give stakeholders and the project sponsor confidence that you are doing the right things: it’s part of your overall approach to project assurance.

For example, quality assurance tasks could include:

• Writing new processes and following them
• Scheduling quality reviews and documenting the output
• Having a process for lessons learned to support ongoing organizational knowledge sharing.

The role of quality assurance in project management is proactive and process-led. It is all about planning to deliver something that meets the quality objectives.

I have never worked on a project where there is a specific quality assurance team. It has always been considered something that I would lead on, as part of the project management responsibilities.

Quality control (QC)

Quality control, on the other hand, is all about checking your work. Control tasks include:

• Testing the deliverables
• Carrying out peer reviews, internal project reviews, or quality audits
• Root cause analysis
• Failure mode and effects analysis (which is something I learned when I was doing Six Sigma training)
• Documenting the output of tests, reviews, and audits along with recommended corrective actions and a plan for how to implement these to get the deliverables up to scratch.

Quality control in project management is reactive because it happens after the deliverable is created. However, you would still have a quality control plan that sets out the schedule for audits and so on.

Some organizations will have a quality control team, so tap into them if you do have experts available to you.

Both QA and QC processes are required for certain industries, for example in healthcare and life sciences, and to ensure compliance with ISO 9000. Talk to your quality management team if you are worried about your project not being able to evidence that it has met contractual guidelines.

How to write a project quality plan

You need some inputs before you can put fingers to keyboard! Here are 3 simple steps for writing a quality plan.

1. Establish what quality looks like for this project

What does a good result look like? What metrics are you going to use? How will you track and measure what is produced?

Look at what standards exist in the organization already and then think about how that applies to your work.

Then, go a level deeper and work out the acceptance criteria (or exit criteria, depending on what you want to call them) for each aspect of the work. This gives you a complete overview of how to assess quality for each deliverable.

On an agile project, this is something you’ll do for each sprint, as the contents of each sprint are known.

2. Clarify roles and responsibilities

Will you have a dedicated quality manager for this project? If not, who is going to do all the relevant tasks? How will they fit that in? Have they been allocated those tasks on the Gantt chart or project schedule yet?

Document roles and responsibilities and make sure everyone is happy with what they are going to be doing.

3. Write it down

Use the outline template below to write your quality plan. Reference other project documents where they exist to save duplicating the effort.

Then get your plan signed off by the project sponsor or client.

We’re all for integrated project management, so once the document is complete, make sure to update any other files that reference it (or should reference it). Add any new risks to your risk log, update the stakeholder register and so on.

Quality management plan template

Here is a template you can use to create your own quality plan. Put the headings into your own organization’s document template in Word, or turn it into a set of slides in PowerPoint. I would not suggest creating this plan as an Excel file as it’s too wordy.

This outline is deliberately vague as you need to make it project-specific. There is no single checklist that I can give you because the definition of quality differs from project to project.

• Project title
• Date
• Roles and responsibilities: List the roles and what part they have to play in the quality management process.
• Tools: If you are using specific software, templates, analysis techniques (like Ishikawa or control charts) then put all that in here.
• Quality assurance approach: Outline how you will ensure high quality for the final deliverable and any process quality standards applicable to the project.
• Quality control approach: Outline how QC will work for this project
• Quality improvements: Outline how you will identify improvements and how these will be acted on.
• Quality metrics: Document the specific requirements. These might already exist in the product descriptions as part of the work breakdown structure, so don’t reinvent the wheel if you already have this information.

Finally, make sure you have all the normal version control information on there, like your name, the version number, and a history of how the document has been updated, so people can make sure they have the latest version.

Why bother with project quality?

So far, all this quality planning sounds like quite a lot of work, so what’s the purpose behind project quality management procedures and processes?

It’s obvious really: you get a better result. If you make an effort to embed quality practices in whatever you do, you are more likely to:

• Get project deliverables that are fit for purpose
• Spend less money
• Deliver results that don’t have bugs or other defects
• Meet your business objectives
• Make stakeholders happy because you have met customer requirements
• Save time because you don’t have to do rework.

What the Standard for Project Management says

The Standard for Project Management covers quality by saying we should build quality into processes and deliverables.

If you ask any customer what they want, one of the responses is going to be that they want the deliverables to be good enough. They get to define what ‘good enough’ means and then you have to make sure the project team meets those standards.

The Standard talks about maintaining:

“a focus on quality that produces deliverables that meet project objectives and align to the needs, uses and acceptance requirements set forth by relevant stakeholders.”

The Quality domain

You might not subscribe to the PMBOK® Guide 7^th Edition way of doing things, but even if you don’t, there are still a few useful takeaways in the PMI manual.

Quality falls into the Delivery Performance Domain. There isn’t much in the way of specifics in the book but what I took from it is:

• Your quality plan should link in with any organizational quality policy.
• Work procedures are part of quality management as they document the way tasks are expected to be carried out, so if you are writing new Standard Operating Procedures (SOPs) they had better be good.
• Most of the cost of quality falls to the supplier doing the work, whether that is internal or external.

Cost of quality, you say? What’s that? Let’s look at that next.

What is the cost of quality?

Quality costs. As you can imagine, putting those checks and balances in place takes time and costs money.

When we talk about the cost of quality (COQ), we mean how much do we spend on getting a quality result, and how much does it cost to have to do work again because we messed up the first time. In other words, what would it cost us to not deliver a quality solution.

The cost of quality includes:

• Preventing nonconformance: the effort involved in making sure the requirements meet the right quality standard
• Checking: appraising what you deliver to check it does meet requirements
• Rework: the effort involved in having to do something again and get it right the second (or third…) time

Internal failure costs are when the project team recognizes there is a mistake before it gets to the customer. External failure costs are found by the client – that’s a big no no, plus it’s embarrassing to hand something over only to be told your customer has found an error or it isn’t up to scratch.

Quality management in agile projects

Agile projects integrate quality into everything they do. I think this is the way it should be for all projects. Why make it different, when delivering a good result should be what we turn up to work to do anyway?

The waterfall approach is often to do a quality audit and assurance work periodically or when deliverables are finished. That’s not the agile way, because agile teams have a much more holistic view of building quality into every step of the journey.

Quality assessments happen as part of sprints. Defects are detected early and fixed at the next possible opportunity.

Spotting errors early means it costs less to put them right: try backing out a line of code when there are hundreds of other processes that might be dependent on it. That’s a whole lot of regression testing that could have been avoided if only the bug was resolved earlier on.

In an agile environment, quality management is the responsibility of the product owner, but really it’s everyone’s job.

FAQ about project quality management