What Is Quality in Project Management?

Quality planning identifies the quality standards relevant to the project and determines how to satisfy them. It produces the quality management plan — a document that defines the quality objectives, the acceptance criteria for each deliverable, the standards and metrics that will be used, the tools and processes that will be applied to achieve and verify quality, and the roles and responsibilities for quality management across the project team. Quality planning must happen during the planning phase, before any delivery work begins. A quality standard defined after delivery has started is a standard that will be ignored under delivery pressure — because the team is already building to the implicit standard they assumed, and changing it mid-build is expensive.

Quality assurance (QA) is the ongoing audit of project processes to ensure they are being followed consistently and are capable of producing outputs that meet quality standards. QA is process-focused, not product-focused — it asks “are we doing things the right way?” rather than “did this specific output meet the standard?” Consequently, QA activities include process audits, methodology reviews, lessons-learned sessions, and continuous improvement initiatives. Quality assurance is preventive by nature: it reduces the probability of defects occurring in the first place by ensuring the processes that create deliverables are sound and consistently applied across the team.

Quality control (QC) is the inspection and measurement of specific deliverables to verify that they conform to quality requirements. QC is product-focused — it asks “does this specific output meet the standard?” rather than “are our processes capable of producing quality outputs?” QC activities include testing, inspection, peer review, defect measurement, and acceptance testing. Importantly, quality control finds defects after they have been created — which is why it is always more expensive per defect found than quality assurance, which prevents defects from occurring at all. The goal of a mature quality management approach is to minimize QC effort by maximizing QA investment.

Gold plating consumes time and budget that was allocated for specified deliverables. The unspecified additions still require testing, documentation, and ongoing support — costs that were not included in the project plan. Furthermore, added features introduce new failure modes: an enhancement not in the requirements was also not in the test plan, meaning it reaches the customer untested. Additionally, gold plating sets a precedent that the team’s judgment about what the customer wants is more reliable than the customer’s own stated requirements — which undermines the entire requirements management process and makes scope baseline maintenance impossible over the course of a long project.

Gold plating is prevented by maintaining a clear, baselined scope document and enforcing the change control process consistently — including for positive additions, not just for changes that reduce scope or extend the timeline. Specifically, any enhancement not in the original requirements must go through the formal change request process, regardless of how small it appears or how confident the team is that the customer will appreciate it. If the customer genuinely values the addition, it will be approved through the change control process and appropriate resources will be allocated. If it is not approved, the project team has been protected from spending time on something the customer did not actually want.

Gold plating should not be confused with value engineering — the legitimate practice of finding better ways to meet the specified requirements at lower cost or higher quality. Value engineering improves conformance to requirements; gold plating exceeds them without authorization. A developer who finds a more efficient algorithm that delivers required performance at half the processing cost is practicing value engineering. A developer who adds a personalization feature not in the requirements because it “seemed useful” is gold plating. The distinction matters because value engineering should be actively encouraged, while gold plating should be consistently redirected through the change control process regardless of how minor it appears.

Every deliverable in the project scope must have documented, measurable acceptance criteria — the specific conditions that must be met for the deliverable to be accepted by the customer or sponsor. Acceptance criteria that are vague (“the system should be fast”) are functionally useless: they create disagreement at acceptance, because the team believes the deliverable meets the standard and the customer believes it does not. Specifically, acceptance criteria should follow the format: “Given [condition], when [action], then [measurable outcome].” For example: “Given 5,000 concurrent users, when the product search function is executed, then results must be returned within 1.5 seconds in 99% of cases.” Download our free Project Plan Template, which includes an acceptance criteria register as part of the project scope documentation.

The quality management plan documents the quality standards, objectives, roles, tools, and processes that the project will use to achieve and verify quality. It is a formal planning document — not an afterthought or a template filled in to satisfy audit requirements. Consequently, a quality management plan written after delivery has started describes what was done rather than what will be done. At a minimum, it should cover: applicable quality standards, quality objectives and metrics, QA process descriptions, QC inspection and testing approach, defect management process, and the criteria for escalating quality issues to the sponsor or steering committee.

The cost of quality framework makes a clear recommendation: invest in prevention activities — requirements reviews, process training, design walkthroughs, and standards adherence checks — before investing in detection activities like testing. In practice, this means scheduling formal requirements reviews before development begins, peer reviews of design documents before they are baselined, and process audits at the start of each delivery phase. Moreover, these prevention activities must be included in the project schedule with real time allocations — not treated as optional overhead that gets squeezed out when delivery pressure increases, which is precisely when they matter most.

Quality in project management should be tracked through the same KPI framework used for schedule and cost — with defined targets, amber and red thresholds, and named owners. Key quality KPIs to track during delivery include defect discovery rate per sprint or per phase, test pass rate on first execution, rework rate as a percentage of total effort, and requirements change rate. A rising defect discovery rate in development testing is a leading indicator of quality problems that will surface — at much higher cost — in user acceptance testing or in production. Tracking it early gives the team time to investigate and address the root cause before the rework burden becomes unrecoverable.

At project closure, the lessons learned review should include a dedicated analysis of quality performance — what quality problems occurred, at which stage they were detected, what they cost, and what process change would have caught them earlier or prevented them entirely. Furthermore, these quality lessons should be fed back into the organization’s quality standards and checklists, not simply filed in a project archive that nobody reads. The organizations that consistently improve their quality performance over time are those that treat project quality lessons as organizational learning — building institutional knowledge that makes each successive project better than the last.