Project QA Plan

What a project QA plan is

A project QA plan is the document that says, for one specific project, how you will define quality, check for it, and decide that each deliverable is good enough to accept. It names the deliverables, states the acceptance criteria each one must meet, sets out the review and approval gates the work passes through, assigns who is responsible for quality at each step, and describes how defects are logged and resolved. It turns "we'll make sure it's good" into an agreed, inspectable plan that the client, the team, and the sponsor can all point to.

It is project-level by design. An organisation-wide quality assurance plan describes the standing standards, processes, and audits that apply across everything a team produces. A project QA plan takes those standards and applies them to the deliverables, schedule, and people of a single engagement — what "done well" means for this website, this report, this installation. It is also broader than a technical test plan: a test plan drills into the test cases for a software release, whereas a project QA plan governs quality for every deliverable, including documents, designs, training, and physical work, not just code.

Defining quality for each deliverable

Quality is meaningless until it is made concrete, so the heart of the plan is a per-deliverable definition of "acceptable". For every deliverable you list, write down acceptance criteria — the specific, checkable conditions that must be true before it can be signed off. Good acceptance criteria share three traits:

• Specific. "The report is high quality" is not a criterion; "every figure cites a dated source and totals reconcile to the finance export" is.
• Measurable or observable. Someone other than the author must be able to look at the deliverable and agree, without debate, whether each condition is met.
• Agreed in advance. Criteria written after the work is finished are an argument, not a standard. Settle them with the client or sponsor before the work starts so acceptance is a check, not a negotiation.

Where a standard already exists — a brand guide, a coding standard, a regulatory requirement, an accessibility level — reference it rather than re-describing it, and treat conformance to it as one of the criteria. The aim is that quality becomes a list you can tick, not a feeling you have to defend.

Review and approval gates

Quality is built in by checking work before it moves forward, not by inspecting it at the very end. A project QA plan defines the gates a deliverable must pass through, and what happens at each. Common gates, roughly in order of cost to fix, are:

• Author self-check — the person who produced the work runs it against a checklist before showing anyone. Cheap, and it catches the obvious.
• Peer review — a colleague who did not do the work reviews it against the acceptance criteria and the relevant standard. This is where most defects should be caught.
• Quality / lead review — a QA lead or discipline lead confirms standards and consistency across the deliverable, and that earlier review comments were actually resolved.
• Approval / sign-off — the accountable owner (often the client, sponsor, or product owner) formally accepts the deliverable against its criteria, usually recording the decision in writing.

For each gate, the plan should state the entry condition (what must be ready before the gate), the exit condition (what "passed" means), and who decides. A gate with no written exit condition is a meeting, not a control.

Roles and responsibilities (RACI)

Quality fails most often not because nobody cares but because everybody assumed someone else was checking. A RACI matrix removes that ambiguity by naming, for each quality activity, who is:

• Responsible (R) — does the work of checking or producing the deliverable.
• Accountable (A) — owns the outcome and makes the accept/reject call; there is exactly one A per activity.
• Consulted (C) — gives input or expertise before the decision (two-way).
• Informed (I) — is told the outcome after the fact (one-way).

A short RACI table covering the key activities — writing the plan, reviewing each deliverable, approving exit from each gate, triaging defects — is usually enough. The discipline is in the single Accountable name: if two people are accountable for the same sign-off, neither truly is.

Metrics and defect handling

A plan that cannot tell whether quality is improving or slipping is just hope on paper, so agree a small set of metrics up front and track them. Useful, lightweight measures include the number of open defects by severity, the proportion of deliverables that pass review first time, rework time as a share of total effort, and the count of issues found after sign-off (escapes). Pick two or three that the team will actually update, not a dashboard nobody maintains.

Behind the metrics sits a defect process that everyone follows. Define how an issue is raised, how it is classified by severity (for example: Critical = blocks acceptance or causes data loss; Major = significant fault with no clean workaround; Minor = cosmetic or low-impact), who triages it, and how it is tracked to closure. Tie severity to the gates: typically no Critical or Major defects may remain open when a deliverable is approved, while agreed Minor issues can be deferred to a documented backlog. Recording defects in one place, with severity and owner, is what lets the metrics mean anything.

How it fits the project plan

The QA plan is not a standalone artefact; it hangs off the rest of the project's documents and only works when it is wired into the schedule. It draws its list of deliverables and milestones from the project charter and the implementation plan, and it inherits the standards and overall approach from the organisation's quality assurance plan. It also pairs naturally with the risk assessment: the highest-risk deliverables are the ones that earn the most review, so risk ranking and QA effort should line up.

Practically, this means the review and approval gates must appear as real activities in the project schedule, with time and named people allocated to them. A gate that is not in the plan will be skipped the moment the deadline looms. When the QA plan, the schedule, and the deliverable list agree with one another, quality stops being a last-minute scramble and becomes a planned part of how the work gets done.

Common mistakes to avoid

• Vague acceptance criteria. If a criterion cannot be checked by someone other than the author, it is an opinion, not a standard. Make every condition specific and observable.
• Setting criteria after the work is done. Agree what "acceptable" means before starting, or acceptance becomes a dispute instead of a check.
• Gates with no exit condition. "We'll review it" is not a control. State what passing the gate means and who decides.
• A RACI with two people accountable. Shared accountability for a sign-off means nobody truly owns it. Exactly one Accountable name per activity.
• Confusing this with the org-wide QA plan or the test plan. The project QA plan applies standards to one project's deliverables; it is not the standing programme, and it covers more than software test cases.
• Inspecting only at the end. Quality found at final sign-off is the most expensive kind. Push checking earlier with self-checks and peer review so defects surface when they are cheap to fix.
• Metrics nobody updates. A handful of measures the team genuinely maintains beats an elaborate dashboard that goes stale by week two.