Quality Report Framework

§1Purpose of the Quality Report

The Quality Report is the primary output of the "Manage Quality" process, serving as the bridge between raw testing data and strategic project governance.

Prepared periodically (often monthly or at phase gates) by the Project Manager or Quality Lead, the report synthesises granular metrics—such as defect density, test coverage, and audit findings—into a coherent posture. Sponsors and steering committees rely on this document to make informed, data-driven decisions regarding phase-gate approvals, corrective actions, and overall project health.

A properly structured report replaces anecdotal assessments of quality with empirical evidence, standardising how performance is communicated across the portfolio.

§2Metric Tracking Architecture

At the core of the template is the Quality Status by Metric table. This forces the project team to define quantifiable criteria at the project's outset and continually measure against them. Each metric requires:

§3Defect Summaries & Corrective Action

Beyond raw metrics, the report must contextualise the defect landscape and outline a path forward. This prevents the document from becoming a passive log and transforms it into an active management tool.

• Defect Summary (Cumulative): Track the total volume of defects logged versus resolved. Crucially, break down the open defects by severity (Sev-1 to Sev-4) and categorise them (e.g., UI/Visual, Functional, Performance). Identifying a trend—such as a decreasing Sev-1/2 burn-down—provides confidence for upcoming User Acceptance Testing (UAT).
• Quality Audit Findings: If a phase gate or independent review occurred during the period, synthesise the good practices observed, the deficiencies identified, and any process bottlenecks.
• Process Improvements: For any metric marked "At Risk" or "Off Track", the PM must document a specific, assigned corrective action.

§4Worked Example: Digital Project

To demonstrate the template in practice, consider the data below synthesised from a recent digital implementation (Mary's Consulting Website). It illustrates how metrics, defects, and actionable recommendations are formatted at the end of a build phase.

Derived Corrective Actions: Based on the data above, the PM formulated specific interventions. Because test coverage was "At Risk" (QM-07), a developer was allocated six dedicated hours in the upcoming sprint to write tests for under-covered components. To address the "Off Track" content submission (QM-10), the PM proposed a tiered launch strategy to mitigate schedule slip, which was formally tracked in the issue register.