How to Write a Quality Assurance Plan for Consulting Deliverables

A quality assurance plan explains how a team will make sure an output is fit for its intended use before it is released. In consulting, the output might be a recommendations report, diagnostic assessment, operating model, policy pack or client workshop deck. The plan should prevent unsupported claims, missed review steps and unclear approval authority.

Use this scenario: a consulting team is preparing a strategy review report for a client sponsor. The report will summarize interviews, compare options and recommend changes to the client's operating model. The quality assurance plan needs to define what "good enough to release" means before the team is under deadline pressure.

Define scope and quality criteria

Start with scope. What deliverable or process does the plan cover? What is outside it? EPA's Quality Assurance Project Plan guidance describes a QA Project Plan as a formal document covering QA, QC and technical activities needed so results satisfy stated performance criteria EPA. That EPA context is environmental data, but the drafting lesson applies broadly: quality starts with intended use and criteria.

For the consulting report, quality criteria might include:

• every key recommendation is linked to evidence or approved assumptions;
• client confidential material is handled according to the engagement agreement;
• financial figures trace to approved source files;
• options are described with limitations and dependencies;
• the report matches the approved scope and decision questions.

Draft language:

The quality objective is to release a recommendations report that is accurate against approved evidence, clear for executive decision-making, consistent with the engagement scope and reviewed for confidentiality before client circulation.

Review criterion: each criterion should be observable. "Professional quality" is not enough. "Every recommendation cites evidence or an approved assumption" can be checked.

It also helps to separate client requirements from internal standards. The client may require a decision-ready executive summary by a board meeting date. The consulting firm may require a second-person evidence check before release. Both matter, but they have different owners and different consequences if missed. Put them in separate rows so the reviewer can see which obligation comes from the engagement and which one comes from the firm's own delivery method.

Choose inspection points across the workflow

A QA plan should not rely on one final review. Late review catches mistakes after the team has built around them. Plan inspection points before, during and after drafting.

For the strategy review:

• Before analysis: confirm scope, data sources, interview plan and confidentiality rules.
• During analysis: review evidence tags, assumptions and emerging findings.
• Before drafting: approve report outline and decision questions.
• Before client release: check claims, figures, confidentiality, formatting and approvals.
• After delivery: capture client feedback and improvement actions.

EPA QAPP guidance emphasizes documenting assessment procedures sufficient to confirm that data of the type and quality needed are obtained EPA QAPP. In consulting terms, do not wait until the report is designed to ask whether the evidence is usable.

Draft language:

The engagement lead will hold a midpoint evidence review before recommendations are drafted. The review will confirm source coverage, unresolved assumptions, excluded material and issues requiring client clarification.

Review criteria:

• Is each inspection point tied to a decision?
• Is the reviewer named by role?
• Is evidence retained?
• Does the plan say what happens if the check fails?

For a report, evidence does not need to be elaborate. It may be a review comment log, a marked-up draft, an evidence matrix or an approval email stored with the project file. What matters is that the evidence shows the check happened before release and that open issues were either closed or accepted by someone with authority.

Plan nonconformance handling

Nonconformance means the work does not meet the defined requirement. In a consulting QA plan, examples include an unsupported recommendation, use of unapproved data, a missed review, a confidentiality issue or a deliverable that exceeds approved scope.

Do not bury nonconformance in a vague "fix issues" sentence. Define the decision path:

• record the issue;
• assess impact;
• decide correction, rework, deviation or rejection;
• assign owner;
• verify the fix;
• inform the client or internal approver if required.

EPA's older QA guidance says response actions to non-conforming conditions should be addressed and assigned EPA QA/G-5. Again, the formal EPA context differs, but the operational principle is useful: decide who responds and how.

Draft language:

If a recommendation is not supported by approved evidence, the reviewer will mark it as a nonconformance. The engagement lead must either add verified evidence, revise the recommendation, record an approved assumption or remove the recommendation before release.

Review criterion: the plan should distinguish correction from approval of a deviation. A senior person may accept a limitation, but the record should show that it was intentional.

Define release approval

Release approval is the point where the deliverable leaves the controlled drafting process. For a consulting report, approval may require the engagement lead, technical reviewer, confidentiality reviewer and client sponsor. Do not make everyone an approver unless they truly have authority; too many approvers blur accountability.

A release approval table can include:

• deliverable name and version;
• acceptance criteria;
• required reviewers;
• evidence checked;
• open limitations;
• approval decision;
• date and approver.

Draft language:

The report may be released to the client only after the engagement lead confirms that all critical findings have evidence references, the confidentiality review is complete and the sponsor-facing limitations section is included.

Review criterion: a person reading the file later should know which version was approved and on what basis.

Add corrective action and improvement

Quality assurance is not just document policing. It should improve the system. If the same issue appears repeatedly, the plan should require corrective action. Maybe analysts need a better evidence tagging guide. Maybe the scope approval step is unclear. Maybe client data arrives in a form the team cannot verify.

Corrective action fields:

• issue pattern;
• root or contributing cause;
• action owner;
• due date;
• evidence of completion;
• effectiveness check.

Draft language:

Recurring unsupported claims will trigger a review of analyst training and the evidence tagging procedure. The engagement lead will verify effectiveness by sampling the next report section before client review.

Review criterion: corrective actions should change the process, not only repair one document.

Add review triggers as well. The plan should be revisited when the scope changes, when the client adds a new decision question, when new data replaces earlier evidence, when a reviewer identifies a repeated defect or when a confidentiality incident affects the deliverable. Without triggers, the plan can look current while the project has moved on.

Prepare the plan for real use

Keep the QA plan close to the work. A plan that lives in a folder nobody opens will not improve the report. Include it in kickoff, midpoint review and release approval.

Before issuing the plan, check:

• quality criteria match the approved scope;
• inspection points happen early enough to matter;
• nonconformance decisions are named;
• release approval is clear;
• evidence records are stored in the approved location;
• the plan has an owner and version.

For a structured starting point, the consulting quality assurance plan template includes editable sections for quality objectives and scope, review and inspection activities, acceptance and nonconformance, corrective action and approval. It helps organize the draft, but the criteria and approvals must come from your actual engagement.

Final test: if the client asks why a recommendation appears in the report, the QA plan should have required an answer before the report was sent.