A RACI matrix is a grid that lists activities down one side and roles across the top, then marks each cell with one of four letters: R for Responsible (the person who does the work), A for Accountable (the single person answerable for the result), C for Consulted (people whose input is sought before the decision), and I for Informed (people told afterwards). The point of it is to settle, in writing and in advance, who decides and who does, so the argument happens once instead of every week.
It is also called a responsibility assignment matrix, a RACI chart, or a RACI model, and the variants swap letters in and out (RASCI adds Support, DACI and RAPID reorganize it around decisions rather than tasks). The letters are the easy part. Almost every failed RACI fails for the same two reasons: somebody put two A's on one row, or the chart was drawn in a workshop and never opened again.
Key takeaways
- One A per row. No exceptions. Two accountable names is the same as none.
- R and A can be the same person, and often should be on small activities. Splitting them by reflex creates hand-offs nobody needs.
- Rows should be decisions and deliverables, not tasks. A RACI with sixty rows gets ignored; one with twelve gets used.
- Consulted is expensive. Every C is a person who can hold the work up, so keep the list short and deliberate.
- Use roles in the column headers, not names. People leave. Roles survive reorganizations.
- The chart is worthless until somebody disagrees with it out loud. If the review meeting is quiet, nobody read it.
- At portfolio level the valuable RACI is not about project tasks. It is about who approves funding, who sets priority, and who signs off benefits.
What is a RACI matrix?
A RACI matrix is a responsibility assignment tool that maps each significant activity in a piece of work to the people or roles involved, marking each relationship as Responsible, Accountable, Consulted or Informed. It exists to remove ambiguity about decision rights: who can decide, who has to do the work, who must be asked first, and who only needs to hear about it.
The reason it survives despite being a spreadsheet from the 1970s is that it forces a specific conversation most teams avoid. Everyone agrees in principle that ownership should be clear. Putting a single name in the A column for "approve a scope change over $50,000" makes it concrete, and that is where the disagreement surfaces. The chart is a byproduct. The argument it provokes is the actual deliverable.
It shows up in almost every methodology under slightly different names. PMI calls the general form a responsibility assignment matrix and treats RACI as the most common example. PRINCE2 handles the same problem through role descriptions and the project board. ITIL uses RACI extensively for service processes. The underlying idea is identical, and so is the failure mode.
What do R, A, C, and I actually mean?
Responsible means you do the work. Accountable means you answer for whether it was done and done properly, and you are the one person who can approve it. Consulted means your input is sought before the work is finished, in two-way conversation. Informed means you are told after the fact, one way, and you have no veto.
| Letter | Means | How many per row | The test |
|---|---|---|---|
| R Responsible | Does the work | One or more | If this slips, whose calendar do you look at? |
| A Accountable | Owns the outcome, approves the result | Exactly one | Who gets the phone call when it goes wrong? |
| C Consulted | Input sought beforehand, two-way | As few as possible | Could this person block or redo the work if skipped? |
| I Informed | Told afterwards, one-way | Any number | Would this person be annoyed to read about it in a status report? |
The line people get wrong is between C and I. Consulted is a genuine obligation: you have to give the consulted party time to respond and you have to deal with what they say. Informed costs nothing but an email. Teams mark stakeholders as Consulted to be polite, then discover that a friendly gesture has added two weeks to every approval. If someone cannot realistically change the outcome, they are an I.
How to create a RACI matrix
Building one takes an afternoon if you resist the urge to be comprehensive. The sequence matters more than the format.
- List the activities that actually cause arguments. Not every task. The decisions, approvals and deliverables where ownership has been unclear before, or where it will be. Ten to twenty rows for a project, eight to fifteen for a governance process.
- List roles across the top, never names. Sponsor, portfolio manager, project manager, finance business partner, technical lead, PMO analyst. Names go stale within a quarter.
- Fill the A column first, one row at a time. Do the accountable pass on its own, before anything else. It is the only column that constrains the others and the only one where a blank or a duplicate is fatal.
- Then assign R. Ask who does the work. If A and R land on the same person for a small activity, leave it. That is not a mistake.
- Add C and I last, and be stingy with C. For every C, say out loud what happens if that person is unavailable for a week. If the answer is "nothing", they are an I.
- Read it across and down. Across a row: exactly one A, at least one R. Down a column: if one role has an A on almost every row, decision-making is bottlenecked on one person. If a role has nothing but I's, ask why they are on the chart.
- Review it with the people named in it. Out loud, in a room, with permission to object. A RACI circulated by email and met with silence has not been agreed. It has been ignored.
Then put it somewhere people trip over it: the project plan, the PMO charter, the onboarding pack for new team members. A RACI in a folder nobody opens is a document, not a control.
RACI matrix example for portfolio governance
Most published RACI examples use a software project, which is fine for a delivery team and useless for a PMO. The version that earns its keep at portfolio level covers the decisions that repeat across every project: what gets in, what gets funded, who gets the people, and who confirms it worked. Here is a worked example.
| Decision or activity | PMO analyst | Portfolio manager | Project sponsor | Steering committee | Finance | Resource manager |
|---|---|---|---|---|---|---|
| Screen and log a new project request | R | A | C | I | C | I |
| Approve the business case and release funding | C | C | R | A | C | I |
| Set the portfolio priority order | R | R | C | A | C | C |
| Assign named people to approved projects | I | A | I | I | I | R |
| Approve a change above the delegated threshold | C | C | R | A | C | I |
| Pass or fail a stage gate | R | C | A | I | C | I |
| Stop or pause a project already in flight | C | R | C | A | C | I |
| Report portfolio status to the executive | R | A | C | I | C | I |
| Confirm benefits after go-live | C | C | A | I | R | I |
Two things in that table are worth arguing about in your own organization, because they are the rows that are usually wrong in practice. The first is stage gate accountability sitting with the sponsor rather than the PMO. The PMO runs the gate and prepares the evidence, but if the PMO also decides the outcome, the gate becomes an administrative checkpoint rather than an investment decision. The mechanics of that split are covered in the stage gate process.
The second is benefit confirmation sitting with the sponsor and finance rather than the project. By the time benefits are measurable the project team is gone, so if accountability was never moved to a standing business owner, nobody confirms anything. That hand-off is the whole subject of benefits realization management, and the review that tests it is the post implementation review.
RACI template: the columns and tabs worth having
A usable template is smaller than most people expect. In a spreadsheet, one tab does the job:
- Activity. Written as a decision or deliverable, starting with a verb. "Approve the resource plan", not "Resourcing".
- One column per role. Six to eight columns is the practical ceiling before the chart stops being readable on a screen.
- Trigger or frequency. When this activity happens: monthly, at each gate, on request. Without it, people cannot tell whether a row applies to them this week.
- Escalation route. What happens if the A and an R disagree. This single column prevents most of the deadlocks a RACI is supposed to solve.
- Version and date. A RACI without a date is assumed to be stale, and usually is.
Add a second tab only if you need it: a notes tab explaining the rows that were contentious and why they landed where they did. Six months later, when someone challenges a decision right, that note is the difference between reopening the argument and closing it in thirty seconds. The same discipline applies to the wider resource management plan template, where the RACI is one tab among several.
RACI vs RASCI vs DACI vs RAPID
The variants exist because RACI is weak in specific situations, not because consultants needed something new to sell. Pick based on the problem you actually have.
| Model | Letters | Best when | Weakness |
|---|---|---|---|
| RACI | Responsible, Accountable, Consulted, Informed | Default. Ongoing processes and delivery work with recurring activities. | Poor at one-off, contested decisions. Blurs "does the work" and "helps". |
| RASCI | Adds Support | Matrix organizations where shared services genuinely assist but do not own. | The S and R boundary is argued about endlessly. Extra letter, extra maintenance. |
| RACI-VS | Adds Verifier, Signatory | Regulated or safety-critical work where approval and verification are legally separate. | Overkill anywhere else. |
| DACI | Driver, Approver, Contributor, Informed | Single significant decisions, especially product and strategy choices. | Not built for repeating operational activities. |
| RAPID | Recommend, Agree, Perform, Input, Decide | Executive decisions where the recommender and the decider are different people. | Heavier to run. Needs facilitation to be worth it. |
In practice most PMOs should stay with plain RACI for process and delivery work, and reach for DACI or RAPID only for the handful of genuinely contested one-off decisions each year. Running two models at once, for different purposes, is fine. Running three is a sign the tool has become the project.
Where RACI charts go wrong
The failures are consistent enough to list, and every one of them is avoidable.
Two people accountable. This is the original sin. It usually happens because two senior people both want the row and nobody will decide between them, so the chart records the ambiguity instead of resolving it. If you cannot pick one A, you have not finished the conversation, and publishing the chart just makes the confusion official.
Consulted inflation. Adding stakeholders as C to keep them happy. Six months later every decision needs eight sign-offs and people route around the process entirely, which is worse than having no RACI at all.
Too many rows. A chart with every task on it is a work breakdown structure wearing a costume. Nobody reads sixty rows. Keep it to the activities where ownership is genuinely unclear.
Names instead of roles. The chart is accurate for one quarter, then someone moves team and the whole thing is quietly wrong. Roles in headers, names in a separate lookup if you need them.
Accountability without authority. Putting an A next to a role that cannot actually allocate budget or people. This is the most damaging one, because it looks fine on paper and fails silently. Whoever holds the A on a row has to be able to make it happen, which is why sponsor accountability is only real when the project sponsor controls the money.
Never reviewed. A RACI should be revisited when the governance changes, at annual planning, and after any reorganization. Not monthly, which trains people to ignore it, and not never, which is the usual alternative.
How does RACI fit with the rest of portfolio governance?
A RACI is the operating detail underneath a governance framework, not a replacement for one. The framework says which bodies exist, what they decide, and at what thresholds. The RACI says who inside those bodies does what for each activity. Build the framework first, then use the RACI to make it executable.
The practical order is: define the decision-making bodies and their thresholds in the project governance framework, describe the standing membership and cadence of the top body in the steering committee terms of reference, then use a RACI to assign the recurring activities across roles. Skipping straight to the RACI produces a chart that assigns work inside a structure nobody has agreed on, which is why so many of them are quietly abandoned within a quarter.
For multi-project programs the same technique scales, but the rows change: cross-project dependency resolution, shared resource arbitration, and benefit ownership move to the top of the chart. That layer is covered in program governance.
Frequently asked questions
What is the purpose of the RACI matrix?
The purpose is to eliminate ambiguity about who decides and who does. By forcing exactly one accountable person per activity and separating genuine consultation from courtesy notification, it prevents work stalling because everyone assumed someone else owned it, and it prevents approvals from collecting stakeholders who have no real say.
What is the difference between responsible and accountable?
Responsible is the person doing the work. Accountable is the single person who answers for whether it was done, and who approves the result. Several people can be Responsible for one activity, but only one can be Accountable. The accountable person delegates the doing and keeps the ownership.
How do you pronounce RACI?
It is pronounced "ray-see", rhyming with "racy". It is an initialism for Responsible, Accountable, Consulted, Informed. Some organizations spell it out letter by letter, which is understood perfectly well, and the RASCI variant is usually said "raa-skee".
Can two people be accountable for the same task?
No. One accountable name per row is the rule that makes the tool work at all. If two names appear, either the activity is really two activities that should be split into separate rows, or a decision about ownership has been dodged. Splitting the row is usually the honest fix.
Who creates the RACI matrix?
The PMO or the project manager normally drafts it, and the sponsor approves it. Drafting is a facilitation job rather than an authoring job: the draft exists to give people something concrete to argue with. A RACI written by one person and never challenged carries no authority when it is tested.
What is the difference between a RACI matrix and a responsibility assignment matrix?
A responsibility assignment matrix, or RAM, is the general category: any grid mapping work to people. RACI is the most common specific form of one. So every RACI is a RAM, but a RAM could equally use RASCI, DACI, or a simple X for assignment.
Is RACI still used in agile teams?
Yes, though usually outside the team rather than inside it. Agile teams self-organize around who does the work, so a task-level RACI adds friction. It stays useful at the boundary: who approves funding, who owns the product decision, who signs off a release, and who arbitrates between teams. Those are the rows worth keeping.
How many activities should a RACI matrix have?
Between ten and twenty rows for most projects and governance processes. Below ten it usually means the contentious activities were left out. Above about twenty-five people stop reading it, which returns you to the situation the chart was meant to fix.
The honest measure of a RACI is whether anyone has ever used it to settle a live disagreement. If a manager has pulled it up in a meeting and said "that is the sponsor's call, not ours", the chart works. If nobody can remember where it is stored, then the workshop produced a document rather than a decision, and the ambiguity it was supposed to remove is still sitting there. Charts do not create accountability. They record it, and only if somebody was willing to accept it in the first place. For the broader question of which roles a PMO should own before you start assigning letters, see PMO roles and responsibilities.
Last updated August 2026.