RACI Chart: What It Is, How to Build One, and Where It Breaks

Unclear ownership is one of the most expensive problems in project management. A McKinsey study on corporate decision-making found that managers spend 37% of their time making decisions, and more than half of that time is wasted. They even estimate the cost at roughly $250 million a year in lost labor for the average Fortune 500 company.

A RACI chart exists to close that gap. However, in software delivery, the problem is much more complicated. The decisions that delay a project usually sit at the boundary between the client and the vendor. Project managers, delivery leads, and engineering teams running software projects that span more than one organization deal with this daily.

This guide covers what the four roles in a RACI chart mean, how to build one in five steps, a worked example for a software development project, and where a RACI chart earns its keep in Agile and outsourced delivery, and where it doesn’t.

What is a RACI chart?

A RACI chart is a project management tool that maps every task or deliverable in a project to four main roles: Responsible, Accountable, Consulted, and Informed.

It’s also known as a RACI matrix or a responsibility assignment matrix. The RACI chart is easy to confuse with two related frameworks, RASCI and DACI, that assign responsibility differently.

How the RACI grid works

The chart itself is a grid. Tasks or deliverables run down the left side, roles or named people run across the top, and each cell holds one letter marking that person’s relationship to that task.

More people, overlapping work, or turnover can all make ownership unclear. That’s when teams reach for a chart. If your project is lean, you don’t need a chart to keep track of what your teammates are doing.

Take a single row from a real project: approve final UAT sign-off. The Product Manager is marked Accountable. The QA Lead is marked Responsible, since they’re the one running the tests.

The client’s IT security team is marked Consulted, because their input shapes what counts as a pass. The rest of the delivery team is marked Informed, so everyone knows the moment sign-off happens.

Most people mess up between Responsible and Accountable. Responsible is whoever does the work. Accountable is whoever owns the task. That said, only one person should ever be Accountable for a given task.

The four RACI roles, explained

Each letter in RACI answers a different question about a task. Here is the definition for each of the roles and how to use them:

Responsible

The Responsible party is whoever does the work. A task can have more than one Responsible name attached to it. A feature might list both a backend developer and a frontend developer as Responsible, since both are doing hands-on work to ship it.

Accountable

The Accountable party owns the outcome. They’re the one who signs off on the work and answers for it if something goes wrong, whether or not they did the work themselves. Unlike Responsible, Accountable is capped at exactly one person per task.

Consulted

The Consulted role covers subject matter experts or stakeholders whose input shapes the work before it’s finalized. It runs on two-way communication, where the person doing the work asks and the Consulted party answers.

Keep this list short. A task with six Consulted names rarely moves faster than one with two. Not to mention more consultants mean you have fewer man-hours for other projects.

Informed

The Informed role is for people who need to know the outcome but don’t need to weigh in on it. Communication here runs one direction only.

If someone on the Consulted list never needs to give input, and only needs to know what happened, move them to Informed. It’s a common fix for charts that have grown too many “stakeholders.”

The RACI golden rule: Only one Accountable per task

There is a reason the RACI chart allows one Accountable for a single task.

When there are two Accountables, the Responsible party ends up chasing two sign-offs instead of one, and the two don’t always agree. When they disagree, there’s no way to settle it at the task level.

Neither Accountable outranks the other, so the disagreement gets escalated instead of resolved where the work is actually happening. It also exhausts the person who is in charge of the task, since they will not know who to listen to.

Worst of all, when the task goes wrong, there’s no single name to hold to account. Both Accountable parties can point at each other. The one guarantee a RACI chart is supposed to make quietly disappears.

How to build a RACI chart in 5 steps

The mechanics of a RACI chart are simple enough. What’s hard is deciding which role actually fits each person and task. Here are what you can do to build an effective RACI chart:

1. List every task or deliverable down the left side of the grid: Keep each row to a single decision or piece of work, not an entire project phase. “Design phase” is too broad to assign one Accountable person to. “Approve final wireframes” is the right size.
2. List every role or named person across the top: Use role titles for a reusable template, and actual names once the chart applies to a live project. A template with roles is easier to reuse across projects, while a chart with names is easier to run.
3. Fill in one letter per cell: Every task needs at least one Responsible and exactly one Accountable. Consulted and Informed are optional. Not every task needs input from a subject matter expert or an update to the wider team.
4. Check for gaps and overlaps before calling it done: This is the step that determines whether the chart holds up under pressure. Scan every row for a task with no Responsible listed, then scan every row again for a task with more than one Accountable.

RACI chart example for a software development project

Here’s what a RACI chart looks like on an actual software delivery project. This team includes a client stakeholder, alongside the vendor’s delivery roles.

In this table, the Client is the main Accountable for three of the four tasks, with being Consulted on one task. Those are the decisions where the client owns the outcome, regardless of which side actually does the work.

UI/UX Design works differently. The Designer is both Responsible and Accountable there. This is an example of a decision that stays inside the delivery team.

When the call stays in-house, the process moves faster, since the person has full ownership of their task. When the decision crosses to the client, that trade flips. This adds a genuine approval layer, but it also means the decision now depends on someone else.

Where RACI charts break: The boundary between client and vendor

A RACI chart matters in software delivery only when the final call on a decision belongs to you instead of the vendor.

Inside your team, Accountable authority runs through the org chart. A manager can reassign the work, escalate a stuck decision, or overrule the call, because everyone reports up to the same chain of command eventually.

Once a decision belongs to your client, that internal authority stops working. Nobody on your team can tell the client’s team what to approve the way a manager tells a direct report what to do. Sign-off now depends on what the contract says and how well the two sides work together.

When you work with a vendor, use a smaller chart that has four to six rows covering only the relevant decisions. It should be built and agreed on before the project starts.

Is RACI outdated in Agile and DevOps teams?

RACI isn’t outdated in Agile or DevOps teams. It’s misapplied, and the misuse takes a different shape depending on which team is asking. Agile teams complain it kills sprint speed while DevOps teams hit the opposite problem. Sprints and continuous deployment don’t remove the boundary. They just make it easier to miss.

Why RACI seems to slow Agile teams down

This complaint is really about one specific mistake. Your team would build a RACI row for every backlog item. But what you should do instead is save the framework for the decisions that actually need it.

Most sprint-level task ownership doesn’t need that treatment, because Agile roles already cover it. The Product Owner owns priority. The Scrum Master owns process. The team owns execution. Furthermore, Agile ceremonies already resolve that same ownership question on their own, through a different mechanism than a chart.

If a team wants to strengthen how those ceremonies work, rather than layering a RACI chart on top of them, the better fix is to improve the agile development process itself.

The DevOps exception: Production deploys and on-call handoffs

DevOps doesn’t make the client-vendor boundary go away. It just moves where you hit it. Take a production deploy. The engineering team builds the DevOps pipeline, but the client’s operations team is the one who runs it.

So neither side automatically owns the sign-off. The same problem shows up during an incident, when both organizations’ on-call rotations get pulled in, and nobody knows who has the final call.

The right-sized RACI chart for Agile and DevOps teams

The right-sized answer is five or six rows, aimed only at the moments where ownership genuinely crosses an organizational line. Those rows sit alongside the Agile process the team already runs for everything else.

RACI alternatives: When RASCI or DACI fit better

The RACI model isn’t the only responsibility framework, the choice also depends on fit and size. Let’s look at some of the examples:

RASCI adds a fifth role, Support. This role helps the Responsible party without owning the outcome themselves. It’s useful when a task has a clear lead plus a group of helpers who need a different letter than Consulted, since Consulted implies giving input rather than doing hands-on work.

DACI (Driver, Approver, Contributor, Informed) is built for a single decision rather than an ongoing set of tasks. It fits a one-time call, like a platform migration or a vendor selection, rather than a project with dozens of recurring deliverables.

In regulated industries, that one-time call comes with vendor selection under a framework like APRA CPS 230/234. The Driver runs the decision process, the Approver decides, Contributors weigh in, and everyone else stays informed.

No framework at all is sometimes the right answer. A project small enough that ownership doesn’t need a chart. Building one anyway adds process overhead, since the ambiguity the chart is meant to solve was never a problem on that team.

The choice between these comes down to what’s genuinely ambiguous. Task ownership across a team calls for RACI or RASCI, while authority over one specific decision calls for DACI.

Final thoughts

A RACI chart doesn’t need to cover every task on a project to be useful. It needs to cover the few decisions that are important. For example, when Accountable crosses from one organization to another or the moment a client’s sign-off.

Everywhere else, a well-run Agile team already has ownership sorted, and adding a chart on top of that just adds a second system tracking the same thing.

Before your next kickoff call, resist the urge to hand over a RACI chart with every backlog item on it. Hand over a few rows, the ones where Accountable has to cross a company line. Get everyone named in those rows to agree to them before the project starts, and let the team’s existing Agile process handle everything else.