None of my projects last year had quality plans.
The project teams delivered high quality results, on budget and mostly to the timescales agreed with the customers. But we didn’t do it with the help of quality plans.
A quality plan is a document that sets out what ‘quality’ means to the project and how it will be achieved. This could be through quality reviews, audits, peer reviews or other methods designed to ensure that the products are fit for purpose. PRINCE2 recommends using quality plans.
A document doesn’t make you deliver quality results. You could have the best quality plan ever written and still end up with deliverables that aren’t what the customer ordered.
Work with customers instead
On my quality plan-free projects we worked extensively with the customers. We understood what they needed and what they wanted. And we worked with them to help them understand when we couldn’t do it, and why. We worked with suppliers too, and challenged them when they weren’t up to our standards.
Yes, sometimes we delivered items that were not of the standard we’d have liked. But a quality plan wouldn’t have made any difference there. I believe we did everything we could to do a quality job.
In my opinion, quality plans are a waste of paper. I know that not everyone will agree with me. And I know that there will be some projects where a quality plan is inevitable, such as where it sets the internal standards for code review on software development projects.
Get the quality attitude
Quality is an attitude. Writing a few pages about what quality means to this project doesn’t equal quality deliverables. Quality should be something we manage instinctively as part of the deliverables for a project task. We shouldn’t need a document to tell us to do our jobs properly and deliver a good quality, fit-for-purpose outcome.
If you don’t know what your customer wants, then something’s wrong. If you don’t try to do your best and deliver that, every time, then something’s wrong.
How do you approach quality planning?