A RACI matrix is useful only when it changes how work moves. Many matrices look complete yet fail during execution: two executives believe they approve the same decision, a supplier is shown as accountable for a risk the buyer still owns, every stakeholder is consulted, or a role appears responsible without receiving the input needed to start. The problem is rarely the four letters themselves. It is the absence of a disciplined audit.
This guide introduces RACI-20, a 20-test audit for an existing responsibility assignment matrix. It helps a project manager, process owner or team lead find ambiguous accountability, overloaded approvers, missing handoffs and communication debt before they become delays. It includes scoring rules, repair actions, a worked product-launch example and a meeting format that a team can use immediately.
The direct answer: what makes a RACI matrix effective?
An effective RACI matrix has one accountable role for every material deliverable or decision, at least one responsible role with the capacity and competence to do the work, consulted roles whose input is genuinely required before the decision, and informed roles who receive a defined message at a useful time. It also connects one row to the next through explicit handoffs and escalation rules.
The matrix should clarify responsibility at the level where work can be verified. “Manage project” is too broad. “Approve release readiness,” “complete security test,” and “accept operational handover” are auditable. The matrix should name roles rather than individuals where continuity matters, while a separate assignment list maps current people to those roles.
Why completed RACI charts still fail
Public practitioner questions repeatedly focus on the same frictions: the difference between responsible and accountable, whether a vendor can be accountable, whether one person can hold more than one letter, and how to handle small teams where everyone wears several hats. These are not theoretical concerns. They reveal that teams use the matrix without first defining authority, output and acceptance.
The four letters answer different questions:
- Responsible: Who performs the work or coordinates the people performing it?
- Accountable: Who has delegated authority to accept the output and answer for the result?
- Consulted: Whose input is required before completion or decision?
- Informed: Who needs the result or decision, but does not shape it before approval?
One person can be both responsible and accountable in a small team when that person performs and accepts the work, provided the organisation accepts the control risk. A supplier may be accountable for a contracted deliverable inside its organisation, while the client still owns the business outcome. The matrix must state the level and boundary being mapped.
Before the audit: define the unit of analysis
Write a scope statement at the top of the matrix: process or project, start and end points, organisational boundary, version date and owner. Then describe what every row represents. Mixing decisions, activities, milestones and departments in one column makes the letters incomparable.
Prefer outcome-oriented rows with a clear completion test. “Security” is a topic. “Approve threat model” is a decision. “Complete penetration test and resolve critical findings” is a deliverable. “Inform security” is an activity but usually too vague to manage.
Set the audit unit to one row. The RACI-20 score is calculated across the whole matrix, but each failed test should identify the affected rows so repairs remain concrete.
RACI-20 audit scorecard
Give one point when a test passes across all material rows, half a point when exceptions are documented, and zero when the condition is absent or unclear. Multiply the total by five for a percentage.
1. Scope boundary is explicit
The matrix states what is inside and outside scope. A project-delivery RACI should not silently assign accountability for post-launch operations. A client–supplier RACI should distinguish contractual delivery from business ownership.
2. Rows describe verifiable work or decisions
Every material row has an observable output, decision or state. Replace broad nouns such as “marketing” with “approve campaign brief” or “publish launch assets after legal approval.”
3. Every material row has exactly one accountable role
One accountable role prevents approval ambiguity. If two roles must jointly approve, define two separate decisions or create one formal approval body with a decision rule. Do not hide unresolved governance behind two A entries.
4. Accountable roles possess authority
The A role can accept, reject, fund or escalate the result. Seniority alone is not enough. Ask what the role is authorised to decide and within which tolerance.
5. Every row has at least one capable responsible role
An R without competence, capacity or access is decorative. Confirm that the role can perform the task and knows the acceptance condition.
6. Multiple responsible roles have a coordinator
Several people may contribute, but one role should coordinate completion. Otherwise each contributor can finish a fragment while no one integrates the deliverable.
7. R and A are separated where control requires it
For high-risk approvals, the same person should not create and independently accept the work. Examples include material financial changes, security exceptions and regulated controls. In a small team, document the compensating review.
8. Consulted roles have a specific input
For every C, state the input: legal interpretation, architecture standard, customer evidence or operational capacity. Remove consultation that exists only to avoid offending a stakeholder.
9. Consultation has a deadline
Undefined consultation can block work indefinitely. Specify when input is due and what happens when it is not received. “No response by Tuesday means the team proceeds using assumption X” is clearer than open-ended review.
10. Informed roles receive a defined message
Identify the information, sender, channel and timing. An I entry is not a substitute for a communication plan, but it should connect to one.
11. No role is overloaded across critical rows
Count assignments by role, then weight critical or time-constrained rows. A sponsor shown as A for 40 operational tasks will become a bottleneck even if the matrix is logically neat.
12. Handoffs identify provider and receiver
For sequential rows, name who provides the input and who accepts it. The transition between rows is often riskier than either activity.
13. Handoffs include acceptance criteria
“Design complete” means different things to design, engineering and compliance. Define the minimum evidence that allows the receiving role to start.
14. External parties do not inherit hidden business accountability
A vendor can own delivery against a contract, but the client retains accountability for many business, regulatory and adoption outcomes. State both layers when necessary.
15. Escalation thresholds are linked to accountable roles
Document which variance, risk or conflict remains local and which moves upward. A matrix without escalation encourages either paralysis or unauthorised decisions.
16. Decision forums have rules
If a committee is the accountable role, define quorum, chair, voting or consent rule, required evidence and tie-break. “Steering committee” is not a decision mechanism by itself.
17. Temporary absences have coverage
Critical decisions need deputies or time-bound delegation. The matrix should not fail because one person is unavailable.
18. Role names map to current people
Maintain a separate role roster with names, contact details and effective dates. This preserves the stable matrix while making current ownership visible.
19. The matrix matches other controls
Compare RACI assignments with the project charter, approval policy, job descriptions, workflow permissions and contract. Contradictions must be resolved, not merely noted.
20. The matrix has a review trigger
Set review events: phase transition, supplier change, reorganisation, repeated delay, material scope change or quarterly control review. A matrix is a living governance control, not a workshop souvenir.
Interpret the score
| Score | Interpretation | Required response |
|---|---|---|
| 90–100 | Operationally strong | Monitor workload and review triggers |
| 75–89 | Usable with defined gaps | Repair failed critical tests before the next gate |
| 60–74 | Material execution risk | Run a facilitated redesign and test key handoffs |
| Below 60 | Matrix is not a reliable control | Rebuild from outputs, authority and workflow evidence |
The total does not override a critical failure. A matrix scoring 90 but assigning no accountable role for regulatory approval is not safe. Mark tests 3, 4, 7, 13, 14 and 15 as critical where legal, financial, safety or security exposure exists.
Worked example: cross-functional product launch
Consider a software company launching an enterprise analytics feature. Roles are product director, product manager, engineering lead, security officer, marketing lead, sales operations lead and customer success lead. The first version of the matrix contains these rows:
| Row | Product director | Product manager | Engineering | Security | Marketing | Sales ops | Customer success |
|---|---|---|---|---|---|---|---|
| Finalise feature | A | R | R | C | I | I | C |
| Approve security | I | A | C | R | I | I | I |
| Launch campaign | A | C | I | C | R | C | C |
| Prepare customers | I | A | I | I | C | C | R |
The chart looks plausible. RACI-20 exposes four problems.
First, “finalise feature” combines product scope, engineering completion and release approval. The team splits it into three rows: accept scope, complete release candidate, and approve go-live. Second, the product manager is shown as accountable for security approval but lacks authority to accept cyber risk. Accountability moves to the security officer for control acceptance, with an executive risk owner handling exceptions above tolerance.
Third, the product director is accountable for the campaign although the marketing lead controls the budget and approval. The team clarifies that the product director approves positioning while marketing approves campaign execution. Fourth, “prepare customers” has no acceptance criterion. Customer success defines readiness as approved migration guidance, trained support staff and completion of communications for affected accounts.
After repair, the matrix includes two handoffs. Engineering supplies a signed release evidence pack to security. Security supplies the approval or exception decision to the go-live forum. Each handoff has a deadline and a contingency. The matrix becomes longer by two rows but easier to operate because decisions are no longer compressed into vague activities.
The original score was 11.5/20, or 57.5%. It failed accountable authority, row clarity, handoff acceptance, escalation and overload tests. The revised matrix scores 18/20. Remaining gaps are role coverage during holidays and alignment with workflow permissions, both assigned owners and due dates.
How to repair common patterns
Too many accountable roles
Do not negotiate which A to delete before defining the decision. Ask: what exact choice is being made, who owns the consequences and which delegated authority applies? If two different consequences exist, create two decisions. If the authority is genuinely collective, define the forum rule.
Everyone is consulted
Apply an input test. What unique evidence must this role provide before completion? If no specific input exists, move the role to informed or remove it. Use time-boxed consultation and an assumption when a response is late.
One executive is accountable for everything
Separate strategic tolerance from operational approval. Delegate routine decisions with thresholds. Retain escalation for material variance, policy exception or irreversible commitment. This reduces queue time without erasing oversight.
A vendor is marked accountable
Create two layers. The vendor may be accountable for the contracted output; the client role remains accountable for business acceptance, regulatory duty or operational adoption. Link the layers through acceptance criteria and contract remedies.
Small team members wear multiple hats
Use role columns even when one person fills several roles. This reveals conflicts and helps future staffing. Where one person holds R and A, record the reason and add peer review for critical outputs. Do not manufacture extra approvals merely to make the table look separated.
RACI does not match the workflow tool
Decide which control is authoritative, then update the other. If the RACI says the security officer approves a release but the software allows the product manager to approve it, the effective control is the software permission. Governance must match execution.
A 45-minute RACI audit meeting
Send the matrix and scorecard in advance. Invite the process owner, two roles doing the work, one downstream receiver and a representative of any control function. Avoid a room filled only with senior approvers.
Use this agenda:
- Five minutes: confirm boundary and row type.
- Ten minutes: test every A for single ownership and authority.
- Ten minutes: test R capacity and critical handoffs.
- Ten minutes: remove unnecessary C entries and define information needs.
- Five minutes: agree escalation thresholds.
- Five minutes: assign repairs, owners and review date.
Do not attempt to perfect every row in the meeting. Repair the highest-risk failures and schedule focused follow-up. Record contested assignments as decisions with deadlines rather than letting the workshop become an organisational debate.
RACI versus RAPID, DACI and workflow ownership
RACI clarifies participation around work and decisions, but it does not fully specify how a decision is made. RAPID or DACI can be more precise for major decisions because they separate recommendation, input, agreement, performance and decision authority. A service ownership model can be better for persistent operational accountability. Workflow permissions may be the strongest control for repeatable approvals.
Use the smallest model that resolves the problem. A project can use RACI for deliverables and a separate decision-rights table for five irreversible choices. Avoid combining acronyms until nobody understands the operating rule. MTF Institute’s existing RACI vs RAPID decision-rights matrix helps teams choose the framework; this guide serves the different task of auditing a RACI already in use.
Evidence to keep after the audit
Retain the dated matrix, score, failed-test log, repair decisions and role roster. For each critical row, link the acceptance criteria or policy that supports the assignment. After one month, review cycle time, missed handoffs, rework and escalations. The audit is successful when execution improves, not when the score increases.
If a failure repeats, ask whether it is truly a responsibility problem. A matrix cannot compensate for impossible workload, conflicting incentives, absent skills or an executive unwilling to delegate. Escalate the underlying constraint instead of adding more letters.
Practical next step
Take the RACI used by your current project or process. Run RACI-20 with one delivery role and one downstream receiver. Highlight every zero on tests 3, 4, 12, 13, 15 and 19. Repair those rows first, then measure whether approval time and rework change over the next four weeks.
For structured development in planning, governance, stakeholder work and execution controls, review MTF Institute’s Project Management programme. Compare the published curriculum with the gaps found in your audit and confirm current enrolment terms before deciding. The useful outcome is not another template; it is the ability to design responsibility that survives real handoffs, constraints and decisions.
Conclusion
A RACI matrix earns its place when it makes work faster, safer and easier to escalate. RACI-20 tests the elements that decorative charts omit: boundary, authority, capability, consultation purpose, workload, handoffs, acceptance, escalation and control alignment. The audit converts four letters into an operating agreement. Use the score to locate risk, repair critical rows and verify improvement through execution evidence.