Quality Metrics
Establish measurable, objective criteria to evaluate project deliverables and safeguard operational standards prior to launch.
In this reference document
§1 The Quality Framework
Quality metrics establish the objective standard for project deliverables. Rather than relying on subjective assessments during User Acceptance Testing (UAT), they provide verifiable targets that definitively prove a requirement has been met.
An effective Quality Metrics matrix relies on four foundational columns:
- ID: A unique identifier (e.g.
QM-01) used to trace the metric across testing logs, Jira tickets, and final sign-off documentation. - Item: The specific component, process, or deliverable being evaluated.
- Metric: The exact data point being observed. This must be a quantifiable figure, percentage, or binary state.
- Measurement Method: The tool, mechanism, or report used to capture the data, alongside the strict threshold for failure/success.
§2 Worked Example: Web Project
The following table demonstrates a completed Quality Metrics matrix for a corporate website overhaul (Mary's Consulting - New Company Website).
Notice how every item includes a specific tool (like Lighthouse CI or BrowserStack) and an exact numerical threshold (like < 2.5s or 100%).
| ID | Item | Metric | Measurement Method |
|---|---|---|---|
| QM-01 | Accessibility | WCAG 2.1 AA findings | Third-party audit at A031; defect count by severity |
| QM-02 | Performance - LCP | Largest Contentful Paint (75th percentile) | Lighthouse CI on 5 representative pages; target < 2.5s on 4G |
| QM-03 | Performance - CLS | Cumulative Layout Shift (75th percentile) | Lighthouse CI; target < 0.1 |
| QM-04 | Defect density | Defects per page template | Count of Sev-1/Sev-2 defects ÷ 12 templates; target < 0.5 |
| QM-05 | Defect resolution time | Average days from logged → resolved | Jira report by severity; target Sev-1 < 2 days; Sev-2 < 5 days |
| QM-06 | Code review coverage | % of PRs with peer-reviewed approval | GitHub branch protection; target 100% |
| QM-07 | Test coverage | % lines covered by automated tests | Jest coverage report; target > 70% on JavaScript components |
| QM-08 | Security - OWASP scan | Number of high/critical findings | ZAP/Burp scan before UAT; target 0 high/critical |
| QM-09 | Content quality | % of pages signed off by Marketing Lead | Tracked in content QA log; target 100% before UAT |
| QM-10 | Bio submission rate | % of in-scope consultants with submitted bio | Christine's tracker; target 60% by Sep 25 |
| QM-11 | Cross-browser | Browser/device combinations passing smoke tests | BrowserStack matrix: Chrome, Firefox, Safari, Edge × desktop+mobile; target 100% |
| QM-12 | Uptime (post-launch) | Production availability during hypercare | Pingdom monitor; target ≥ 99.9% over 14-day hypercare window |
§3 Quick Reference
Automate First
Whenever possible, select metrics that can be extracted automatically via CI/CD pipelines (e.g. Jest, Lighthouse) rather than manual tracking.
Clear Thresholds
Ensure your targets are definitive. Avoid words like "fast" or "secure". Use exact figures (< 0.1) or absolutes (0 critical findings).
Baseline Agreements
Standardise your matrix and secure stakeholder sign-off prior to the execution phase to prevent goalpost shifting during final delivery.