We’re often asked by project managers about the purpose of Quality Management Plans and what benefits (if any) they may have on projects.
The short answer is that when used correctly they can be essential to project success.
Firstly what is a Quality Management Plan (QMP) for a project? (they’re often also called Project Quality Plan)
Just as a Project Management Plan (PMP)* describes the project objectives, strategy, activities, mechanisms, constraints and resources for a project, a QMP is a document which describes the:
- quality objectives
- standards and
- assurance activities
to deliver an agreed level of quality for the project.
*the QMP/PQP can (and often is) included as a chapter or section within a project’s PMP
These seem to cause the most angst for project managers. These are just the specific goals and targets for the project deliverables. eg. Zero software defects, <5 non-critical external asset material problems, zero Health/Safety/Environment issues.
Once the objectives have been defined, a strategy to achieve those objectives needs to be described – what is the overall QC/QA/method to be applied? Lots of upfront design reviews? Daily walkthroughs? Inspections scheduled throughout the project?
The Quality Control for each phase and each deliverable (or type of deliverable at the very least) needs to be described in sufficient detail so that the project stakeholders have a reasonable understanding of what is being undertaken.
Testing & Defect Management
If there is no separate test strategy, you need to describe how defects, problem reports, and other non-conformances are to be managed on the project. So the process/mechanism for:
• Identifying defects
• Prioritizing defects
• Reporting defects; and
• Resolving them
needs to be described. Of course if there is a test strategy which describes this then it doesn’t need to be repeated.
The QMP should also include processes for addressing process non-conformances. What happens if team members don’t follow the agreed process for the project? How will this be identified? (see the next section) What impact will it have on the quality of deliverables (products and services)?
Process & standards compliance (audits)
The review of compliance to required processes and standards needs to be described. Process assessments enable a reasonable level of transparency and visibility are available to the sponsor and project stakeholders in a timely manner. After all, getting details of poor design practices once manufacturing has commenced is a wasted opportunity.
Some indication of which process reviews or audits are to be undertaken needs to be described. The questions of what will be reviewed, why and when should be answered.
Unless described elsewhere (and it often isn’t) the QMP should include all project-specific processes. On many contracts there are specific processes which are unique and need to be followed, so it’s important to inform project team members of any special requirements.
Customer Complaints and Feedback
Customer complaints are often seen by project managers are the bane of their existence. If customers would only stop complaining the project team could get some real work done.
However if you broaden the term to include both positive as well as negative feedback you’ll tend to get a much more positive response from the project team and customer. But in doing eliciting comments and feedback from customers and partners, you must provide a mechanism to ensure positive comments are actually collected.
- What needs to be described?
- How will feedback be collected? Surveys? Email?
- How often will feedback be collected? Monthly? Quarterly? Find a balance.
- Who gets to see the raw data? Everyone thinks they want the raw truth – until they see in the light of day.
- Get gets to see the results
- What actions will be undertaken to address the feedback?
- Who is responsible for each action?
- How will corrective actions be communicated back to customers, partners and stakeholders?
Quality Gates and Acceptance Criteria
For a project to progress through differing phases, most projects conduct project quality gates (also called quality review points, checkpoints, etc). These gates ensure mandatory activities/criteria are satisfied prior to subsequent phases occurring. They are also the best mechanism to examine the progress and performance of a project to assess whether it should continue or whether some action is required.
The QMP should include as much criteria as possible for each of the quality gates. Preferably include the actual quality gate checklists that will be used (with the understanding that they may be tailored/adjusted prior to the gate occurring once more information is known about the project). This will ensure that no “unknown unknowns” are raised at a meeting surprising everyone and frustrating the project manager.
The QMP should also include how the quality of deliverables from suppliers, subcontractors and partners will be managed.
Although often included in contract terms and conditions, they are often not described in sufficient detail to be useful.
- Who is responsible for QA/QA?
- When will it be conducted?
- How will multi-supplier conflicts be managed?
- Who will pay for defect rectification prior and post delivery to the customer?
Agreeing these mechanisms jointly with your suppliers and partners will ensure everyone’s expectations are aligned (or at least known).
Finally the standards which need to be followed must be specified. This can be in the form of an appendix or end section. It’s interesting to note that this is often left out of QMPs and contract documents. Or it’s included in a brief clause stating that “appropriate” standards will be complied with. This can be a major source of conflict due to inferences drawn from poorly specified standards requirements.
The QMP should be approved at the same time as the PMP to ensure both documents are aligned. (which will definitely happen if the QMP is a section of the PMP)
Once approved, the QMP contents should be communicated to project team members and all appropriate stakeholders to ensure a consistent view of quality expectations for the project.
Just like the PMP, the QMP should be updated at appropriate junctures throughout the project. And just like the PMP, the QMP often isn’t.
Agile and the QMP
While many people believe the PMP (and hence QMP) to be anathema to agile development, the QMP can be a powerful force for agile development projects.
But that’s for the next post.