RACIQ: A Standing Quality Role

Summary

RACIQ adds a Quality review role to RACI, giving the quality-assurance function its own named place on the chart instead of burying it inside the Accountable owner. It fixes the “owner grades their own homework” problem: an independent, named party checks each deliverable against defined quality requirements. Choose it where QA is a real standing function, software delivery with a dedicated test team, manufacturing quality control, pharmaceutical QA; skip it where quality genuinely belongs to the owner and a Q column would sit empty. Do not confuse Q with RACI-VS’s Verify (a per-deliverable acceptance gate) or PACSI’s Control (a rejectable review with a veto); Q is the standing quality function made visible.

The letters

RACIQ adds a single role, Quality review, to the RACI baseline.

The addition is deliberately narrow. Q is not a general reviewer, not a formal signatory, and not the accountable owner. It is the quality-assurance function given its own place on the chart, so that “did this pass QA?” has a named answer that does not depend on the owner grading their own work.

Origin and history

RACIQ is one of the standard documented extensions of RACI, listed in the family’s core references including Wikipedia and CIO Wiki, both of which define the Q role as those who check whether the product meets its quality requirements. Like the rest of the family, it has no single named inventor; it is a practitioner convention that took hold in environments where quality assurance is an established, separate discipline rather than an activity the delivery owner performs on themselves.

Its origin logic is the same one that recurs throughout the family: the base matrix has no dedicated place for a role that a particular context treats as essential. In software, manufacturing, and pharmaceuticals, QA is a distinct function with its own staff, standards, and reporting lines. Folding that into the Accountable owner, or leaving it inside a generic Consulted, understates it and obscures the independence that makes it valuable. RACIQ gives it a column.

What problem it solves

RACIQ solves the “owner grades their own homework” problem for quality specifically. When quality assurance is buried inside Accountable, the person who owns delivery is also the person attesting that the deliverable is good enough, which is a weak control and a poor signal. By separating Q, RACIQ records that an independent quality function has checked the work against defined requirements, and it names who that function is on each task.

The second benefit is organizational rather than task-level. Where QA is a standing team, a Q column lets you read across many tasks to see how the quality function is deployed and loaded, in much the way a Support column does for helpers in RASCI. That turns the matrix into a small planning tool for the QA function, not just a per-task organizer.

When to choose it, and when not

Choose RACIQ where quality assurance is a standing, named function rather than an ad-hoc step: software delivery with a dedicated QA or test team, manufacturing with quality control, pharmaceutical and medical-device work with a formal QA role, and any environment where an independent quality check is expected on most deliverables. It is the right choice when you want quality visible and independent on every relevant row.

Do not add Q where quality is genuinely the owner’s responsibility and there is no separate function to name. An empty or owner-duplicating Q column adds nothing. Where the control you need is a per-deliverable verification-and-signature gate, RACI-VS fits better; where reviewers need the power to reject work outright, PACSI and its Control role are more appropriate. RACIQ is specifically for a standing quality-assurance role.

Common pitfalls

• Q, Verify, and Control confusion. Three neighboring matrices each add a review-ish role. Q is a standing quality function, Verify (RACI-VS) is a per-deliverable acceptance check, and Control (PACSI) is a rejectable review. Mixing them produces a chart nobody trusts. Pick the one that matches your actual control.
• Q collapsing into A. If the accountable owner is also the quality reviewer, the independence that justifies the Q role is gone. Keep them distinct.
• Q as a rubber stamp. A quality role that never fails anything is decoration. The value is a genuine, independent check against defined requirements.
• No defined quality criteria. Q is meaningless without an explicit standard to check against. Name the criteria, or the role is just a second opinion.

Worked example

A software feature delivery with a dedicated QA team.

Reading the “Quality review” row: the QA Engineer holds the Quality role (Q), checking the feature against defined acceptance criteria, while the Engineering Manager remains Accountable (A) for the outcome and the Tech Lead is Consulted (C). The developer is Informed. Because Q sits with an independent QA engineer rather than with the accountable manager, the chart records a genuine, separate quality check rather than the owner attesting to their own team’s work.

Where it sits in the family

RACIQ is one of the three control-oriented cousins in the task family, alongside RACI-VS and PACSI. Its distinctive niche is the standing quality-assurance function: not a gate, not a veto, but an independent, named quality check applied across tasks. It composes cleanly with other additions, so a mature chart might carry both a Support role and a Quality role at once. Choose RACIQ when quality is a real function in your organization and you want it visible and independent on the chart rather than assumed inside ownership.

Sources

Web sources

• Responsibility assignment matrix, Wikipedia (RACIQ: includes Quality review): https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
• RACI Matrix, CIO Wiki (RACIQ quality-review definition): https://cio-wiki.org/wiki/RACI_Matrix
• Responsibility assignment matrix reference, GitHub (joelparkerhenderson): https://github.com/joelparkerhenderson/responsibility-assignment-matrix

Academic sources

No peer-reviewed literature treats RACIQ as its own subject; it is documented through the family’s standard references. The independence-of-quality idea it encodes has a deep academic and standards pedigree.

• Deming, W.E. (1986) Out of the Crisis. Cambridge, MA: MIT Press. The foundational argument that quality must be built into how work is organized rather than inspected in afterward by the producer.
• International Organization for Standardization (2015) ISO 9001:2015 Quality management systems: requirements. Geneva: ISO. The standard that institutionalizes quality assurance as a distinct, auditable function, which is the organizational fact RACIQ charts.