This blog is reader-supported. When you purchase something through an affiliate link on this site, I may earn some coffee money. Thanks! Learn more.
By Elizabeth Harrin 15 June, 2022 6 September, 2024 Last updated: 6 September, 2024 Templates, Project quality
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.
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?
And here are some others:
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.
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:
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, on the other hand, is all about checking your work. Control tasks include:
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.
You need some inputs before you can put fingers to keyboard! Here are 3 simple steps for writing a quality plan.
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.
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.
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.
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.
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.
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:
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.”
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:
Cost of quality, you say? What’s that? Let’s look at that next.
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:
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.
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.
The project manager or product owner is ultimately responsible. However, the project team might include a quality manager. Everyone is responsible for following the processes and doing a good job.
Quality matters because people want to get the right thing at the end of the project. They want a decent result because they’ve spent time and money on the process and they have certain expectations.
The purpose of project quality management is to ensure the project delivers the right outputs that meet customer expectations in a controlled way while minimizing the cost of quality by building a culture where quality is baked into everything the project team does.
Project manager, author, mentor
Elizabeth Harrin is a Fellow of the Association for Project Management in the UK. She holds degrees from the University of York and Roehampton University, and several project management certifications including APM PMQ. She first took her PRINCE2 Practitioner exam in 2004 and has worked extensively in project delivery for over 20 years.
Elizabeth is also the founder of the Project Management Rebels community, a mentoring group for professionals. She's written several books for project managers including Managing Multiple Projects.
