Project QA Plan

Project: [Project name] Sponsor / client: [Name / organisation] Author: [Name / role] Date: [Date] Reviewers: [Names] Status: [Draft / Approved]

---

1. Project and scope

[In 2-3 sentences: what this project delivers, who it is for, and what this QA plan covers. Note anything explicitly out of scope for quality assurance — e.g., a third-party component covered by its own warranty.]

2. Quality objectives and acceptance criteria

State, for each major deliverable, the specific conditions that must be true before it can be accepted.

Deliverable	Acceptance criteria (specific, checkable)	Standard / reference	Accepted by
[Deliverable 1]	[Condition 1; condition 2; condition 3]	[Brand guide / spec / regulation]	[Role]
[Deliverable 2]	[Condition 1; condition 2]	[Reference]	[Role]
[Deliverable 3]	[Condition 1; condition 2]	[Reference]	[Role]

[Add one row per deliverable. Each criterion should be checkable by someone other than the author.]

3. Review and approval gates

Gate	Applies to	Entry condition	Exit condition (passed when)	Decider
Author self-check	All deliverables	Draft complete	Checklist passed	[Author]
Peer review	[Deliverables]	Self-check passed	Comments resolved; criteria met	[Reviewer]
Quality / lead review	[Deliverables]	Peer review passed	Standards confirmed	[QA / lead]
Approval / sign-off	[Deliverables]	Lead review passed	Owner accepts in writing	[Owner / client]

4. Roles and responsibilities (RACI)

Activity	Responsible (R)	Accountable (A)	Consulted (C)	Informed (I)
Maintain this QA plan	[Name]	[Name]	[Name]	[Team]
Review each deliverable	[Name]	[Name]	[Name]	[Name]
Approve gate exit / sign-off	[Name]	[Name]	[Name]	[Sponsor]
Triage and track defects	[Name]	[Name]	[Name]	[Team]

[Exactly one Accountable per row.]

5. Defect / issue process

• Raising an issue: [Where issues are logged and what information is required.]
• Severity scale:
  • Critical — [e.g., blocks acceptance or causes data loss]
  • Major — [e.g., significant fault with no clean workaround]
  • Minor — [e.g., cosmetic or low-impact]
• Triage: [Who reviews new issues, how often, and how priority is set.]
• Resolution rule at sign-off: [e.g., no open Critical or Major defects; agreed Minor issues deferred to a documented backlog.]
• Tracking: [Where issues live and how closure is recorded.]

6. Quality metrics

Metric	How measured	Target / threshold	Owner
Open defects by severity	[Count from tracker]	[e.g., 0 Critical at sign-off]	[Role]
First-time review pass rate	[Passed / reviewed]	[e.g., >= 80%]	[Role]
Post-sign-off escapes	[Issues found after acceptance]	[e.g., trend down]	[Role]

7. Audit / review schedule

Activity	When / frequency	Performed by	Output
[QA checkpoint review]	[Milestone / date]	[Role]	[Findings, actions]
[Standards audit]	[Frequency]	[Role]	[Audit note]
[Plan review]	[Each phase / date]	[Role]	[Updated plan]

---

Optional sections

• Tooling: [Trackers, checklists, or test tools used to support quality.]
• Traceability: [Mapping of requirements to the deliverables and checks that cover them.]
• Change handling: [How a change to scope updates acceptance criteria and gates.]