Markdown Editor

Project Quality Management Plan Template

Quality policy, objectives, acceptance criteria, roles, QA audits, QC metrics, nonconformance and corrective action, improvement, records

Quản lý dự ánĐầy đủISO 10005:2018qualitymanagementplanmath
Mở trong editorTải .md

Cách dùng: Use during planning alongside the scope baseline. Fill measurable quality objectives and acceptance criteria per deliverable first. Main pitfall: treating quality as testing only and forgetting assurance of processes and supplier deliverables.

Xem trước

Quality Management Plan: [Project name]

Project quality management plan: quality policy and objectives, standards and acceptance criteria, roles, planning, assurance, control, tools, nonconformance and corrective action, continuous improvement and records. Based on common project management practice; the structure uses ISO 10005:2018 (guidelines for quality plans) as a structural reference only. Replace every [bracketed] value and every row marked Example.

Document control

FieldValue
Document ID[QMP-PROJECT-001]
Project[Project name] ([code])
Version[0.1]
Status[Draft / In review / Approved]
Owner[@quality-lead]
Project manager[@project-manager]
Classification[Internal]
Related documents[PMP-001, Test plan TP-001, Requirements specification SRS-001]
Last updatedYYYY-MM-DD

Approvals

RoleNameDecisionDate
Project sponsor[@name][Approved]YYYY-MM-DD
Head of quality[@name][Approved]YYYY-MM-DD
Project manager[@name][Submitted]YYYY-MM-DD

Revision history

VersionDateAuthorChange summary
0.1YYYY-MM-DD[@name]First draft
1.0YYYY-MM-DD[@name]Example: Approved at gate G1
1.1YYYY-MM-DD[@name]Example: Added accessibility audit after CR-007

Contents

1. Scope and purpose

This plan defines how quality will be managed on [Project name] so that its deliverables meet stakeholder requirements and the acceptance criteria in the scope baseline. It applies to all project deliverables, including those produced by suppliers, and to the project management processes used to produce them.

In scopeOut of scope
Example: Process design documents, onboarding platform, integrations, training materials, data migrationQuality of the core banking system itself (owned by the core banking service)
Example: Supplier deliverables under contract C-2027-14Ongoing service quality after handover (covered by the service level agreement)

2. Quality policy and objectives

The project adopts the organisation's quality policy ([QP-001]) and interprets it as follows for this project: deliverables are fit for purpose, verified against agreed criteria before acceptance, and defects are found as early as possible where they are cheapest to fix.

IDQuality objectiveMeasureTargetOwner
QO-01Example: Release without critical defectsOpen severity 1 or 2 defects at go-live0[@test-lead]
QO-02Example: Meet accessibility obligationsWCAG 2.2 AA audit findings at level A or AA0 open at go-live[@ux-lead]
QO-03Example: Accurate data migrationRecords migrated with field-level errorsBelow 0.1%[@data-lead]
QO-04Example: Ready usersStaff passing the training assessmentAt least 80% first attempt[@change-lead]
QO-05[Objective][Measure][Target][@owner]

3. Quality standards and acceptance criteria

Deliverables are built to the standards below and accepted against the listed criteria.

3.1 Applicable standards and requirements

SourceApplies toNotes
[Organisation quality management system]All deliverablesDocument control, review rules
Example: WCAG 2.2 level AACustomer-facing screensRequired by national accessibility regulation
Example: Internal secure development standard SDS-04Platform and integrationsIncludes code review and security testing
Example: Data protection regulationData migration, loggingData minimisation, retention
[Standard][Deliverable][Notes]

3.2 Acceptance criteria by deliverable

DeliverableAcceptance criteriaVerification methodAcceptor
D1 Process designExample: All 7 scenarios mapped; reviewed by operations and compliance; no open major commentsDocument reviewHead of operations
D2 Onboarding platformExample: 100% of Must requirements pass system test; UAT pass rate at least 95%; p95 response under 2 sTest reports, performance testProduct owner
D3 Data migrationExample: Reconciliation counts match; sample of 1,000 records error rate below 0.1%Reconciliation reportData owner
D4 TrainingExample: 95% of staff trained; assessment pass rate at least 80%Attendance and assessment recordsChange lead
[Deliverable][Criteria][Method][@acceptor]

4. Roles and responsibilities

Quality responsibilities are allocated as follows.

RoleNameQuality responsibilities
Project sponsor[@name]Approves quality objectives; accepts residual quality risk
Project manager[@name]Ensures quality activities are planned, resourced and reported
Quality lead[@name]Owns this plan; runs assurance reviews and audits; reports quality status
Workstream leads[@names]Apply quality control to their deliverables; fix nonconformances
Test lead[@name]Plans and runs testing; reports defect metrics
Supplier quality contact[@name]Ensures supplier deliverables meet contract quality clauses
Independent assurance[@name]Performs stage-gate health checks; reports to steering committee

5. Quality planning

Quality activities are planned per stage and included in the project schedule.

StageQuality activitiesEntry criteriaExit criteria
InitiationAgree quality objectives and acceptance criteriaCharter approvedThis plan approved
DesignRequirements and design reviews; compliance reviewDraft designs availableDesigns approved, no open major findings
BuildCode review, static analysis, unit testing, supplier inspectionsApproved designUnit coverage at least [80%], no critical static findings
TestSystem, integration, performance, accessibility, security testing, UATBuild complete, environments readyAcceptance criteria in 3.2 met
Deploy and transitionOperational readiness review, post-release verificationUAT passedHandover criteria met

The cost of quality is estimated so that prevention and appraisal are funded explicitly.

Cost of quality categoryExamplesBudget
PreventionTraining, design standards, reviewsExample: 12,000 EUR
AppraisalTesting, audits, inspectionsExample: 46,000 EUR
Internal failure (estimate)Rework before releaseExample: 15,000 EUR (contingency)

6. Quality assurance

Quality assurance confirms that the project is following its planned processes and that those processes are producing the expected quality. Findings are logged in the nonconformance register (section 9).

IDActivityScopeTimingPerformed byOutput
QA-01Example: Process auditRequirements and change control processesEnd of design stageQuality leadAudit report with findings
QA-02Example: Supplier quality auditVendor development and test processWeek 4 of buildQuality lead with procurementSupplier audit report
QA-03Example: Stage-gate health checkPlan, RAID log, quality metricsBefore each gateIndependent assuranceGate readiness report
QA-04Example: Test process reviewTest plan and test evidenceBefore UATQuality leadReview record
QA-05[Activity][Scope][Timing][@name][Output]

7. Quality control

Quality control verifies that deliverables meet their acceptance criteria before they are accepted.

7.1 Inspections and reviews

Deliverable typeControlCriteriaFrequency
DocumentsPeer review using checklist [QC-CHK-01]No open major commentsEvery document before approval
CodePull request review by a second developer; static analysisNo critical or high findingsEvery change
Data migrationReconciliation and sample inspectionCounts match; sample error rate below 0.1%Each trial migration
Training materialsReview by two pilot usersRated clear by bothEach module

7.2 Testing

Testing is planned in [Test plan TP-001] and covers unit, integration, system, performance, accessibility, security and user acceptance testing. Test completion is reported in a test completion report.

7.3 Quality metrics

MetricDefinitionTargetAction thresholdFrequency
Defect densityDefects found in system test per 100 requirementsBelow 15Above 25 triggers root cause reviewWeekly
Defect removal efficiencyDefects found before release / total defectsAt least 90%Below 85%At release and after 30 days
Review effectivenessMajor findings found in review / major findings found laterAt least 70%Below 50%Per stage
First-time acceptanceDeliverables accepted without reworkAt least 80%Below 70%Per stage

Defect removal efficiency is calculated as:

DRE=Dbefore releaseDbefore release+Dafter release×100%DRE = \frac{D_{\text{before release}}}{D_{\text{before release}} + D_{\text{after release}}} \times 100\%

Example: 180 defects found before release and 12 in the first 30 days after release give DRE=180/192≈93.8%DRE = 180 / 192 \approx 93.8\%, which meets the target.

7.4 Quality reporting

Quality status is reported in every project status report as a RAG rating with the metrics above, open nonconformances by severity and any acceptance criteria at risk. A monthly quality review, chaired by the quality lead, looks at trends rather than single values: a rising defect inflow late in testing, or a falling first-time acceptance rate, is raised as a risk in the RAID log even when the current numbers are still within target. Before each stage gate the quality lead issues a short quality statement confirming which acceptance criteria are met, which are not, and the residual quality risk the sponsor is asked to accept.

8. Tools and techniques

The project uses the following tools and techniques.

PurposeTool or technique
Defect and nonconformance tracking[Issue tracker, project "DOB"]
Test management[Test management tool]
Static analysis and code review[Tooling in CI pipeline]
Accessibility testing[Automated checker plus manual audit with screen readers]
Root cause analysisFive whys, cause-and-effect (fishbone) diagram
Trend analysisControl charts for defect inflow, Pareto analysis of defect causes

9. Nonconformance and corrective action

Any deliverable or process that does not meet its requirement is recorded as a nonconformance (NC). The NC owner contains the problem, analyses the root cause, and agrees a correction and, where the cause could recur, a corrective action.

NC IDDescriptionSourceSeverityRoot causeCorrectionCorrective actionOwnerDueStatus
NC-001Example: Two process documents approved without compliance reviewQA-01 auditMajorReview checklist lacked compliance stepCompliance reviewed both documentsChecklist QC-CHK-01 updated; reviewers briefed[@quality-lead]YYYY-MM-DDClosed
NC-002Example: Supplier code delivered without unit tests for 3 modulesQA-02 auditMajorContract did not state coverage targetTests added before acceptanceContract change: 80% coverage clause[@pm]YYYY-MM-DDOpen
[NC-nnn][Description][Source][Major / Minor][Cause][Correction][Action][@owner]YYYY-MM-DD[Status]

10. Continuous improvement

Quality data is reviewed at each stage gate and at monthly quality reviews. Improvement actions are recorded and tracked like other project actions; lessons that apply beyond the project are added to the lessons learned register.

IDImprovementTriggerExpected effectOwnerStatus
IMP-01Example: Add accessibility checks to the definition of doneAudit found 14 contrast issuesFewer accessibility defects at audit[@ux-lead]Implemented
IMP-02[Improvement][Trigger][Effect][@owner][Status]

11. Quality records

The following records are kept as evidence of quality management.

RecordLocationOwnerRetention
Review records and checklists[Repository folder]Workstream leads[7 years]
Test plans, test reports, defect logs[Test tool]Test lead[7 years]
Audit reports and NC register[Repository folder]Quality lead[7 years]
Acceptance certificates[Repository folder]Project manager[7 years]
Supplier quality reports[Contract folder]Contract manager[Contract term plus 7 years]

12. References and glossary

The following documents and terms are referenced in this plan.

ReferenceTitle
[QP-001]Organisation quality policy
[PMP-001]Project management plan
[TP-001]Test plan
ISO 10005:2018Quality management: Guidelines for quality plans (structural reference)
TermMeaning
Quality assuranceActivities that give confidence the planned processes are followed and effective
Quality controlActivities that check deliverables against their acceptance criteria
NonconformanceFailure to meet a specified requirement
Corrective actionAction to remove the cause of a nonconformance and prevent recurrence

Standard and licence note

Structure aligned with ISO 10005:2018, Quality management: Guidelines for quality plans, used only as a structural reference for the contents of a quality plan. Content is based on common project management practice. This template is original text written for this collection and reproduces no text from the standard; obtain the standard for its guidance. Template licence: MIT.

Template liên quan