RACI Matrix

A system launch has many moving parts: IT thinks finance will approve the data migration, while finance expects operations to sign off. A RACI matrix makes the handoff visible before the deadline.

Put tasks or decisions in rows and roles or named people in columns, with R, A, C or I at each intersection where appropriate, and use specific deliverables such as approve migration test rather than an entire vague phase such as launch. The Responsible person or team performs the work, and more than one person can contribute, though too many joint owners may slow execution.

The Accountable person owns the outcome and has the authority to approve it, and standard RACI practice aims for one Accountable person for each row, so if two executives appear as A, split the decision or agree who has final authority. A person may be both Responsible and Accountable, as when a small-business owner drafts and approves a simple supplier list, and the chart need not invent another approver merely to fill each letter with a different name.

Consulted people give input before the decision or delivery, as when a privacy specialist reviews a proposed customer-data export, but consultation is not the same as a veto unless a separate policy or law gives that authority. Informed people receive the result or progress after a relevant step, so the warehouse manager might need to know that software is ready but not decide each technical setting.

Cornell University's RACI guidance assigns one Accountable owner per task and notes that the Responsible person can also be Accountable, and Atlassian likewise recommends checking each completed row for one A, though these are operating conventions, not a legal rule for every organisation. Start with the project's actual authority map, because a sponsor's charter, job roles and approval policy may determine who can sign off, and a RACI cell cannot override a board approval, regulated signatory or contract requirement.

Get the affected team to review the draft and ask whether each assigned person has the tools and time to deliver. A task with no A lacks a clear owner, and a decision with six Cs may stall if nobody sets a deadline for their input.

Keep the matrix at a workable level of detail, since one row for every tiny email creates busywork while one row for the entire project hides handoffs, so focus on cross-team tasks and decisions where responsibility is genuinely unclear. Distinguish a task from its approval, because prepare budget and approve budget can be separate rows involving different actions, and one combined row may incorrectly imply the preparer can authorise spending.

Revise the matrix when the scope or team changes, replacing the owner before a pending approval stalls if a finance manager leaves, and keep a dated version so teams do not follow conflicting assignments. A RACI matrix is not a schedule, since it does not list task duration or dependencies in enough detail to manage the whole job, so link its rows to the plan, ticket board or service process where execution is tracked.

For a manager, the value is clarity at the handoff. Use one real Accountable owner for each meaningful decision, name the doers, limit consultation to the people whose input is needed, and then confirm those assignments with the team.