RACI Matrix
One row per decision, one owner per row — the grid that turns a recommendation into someone's Monday morning.
On this page
The gist
- →RACI is an execution grid: rows are deliverables and decisions, columns are roles, cells say who is Responsible, Accountable, Consulted, Informed.
- →The iron rule: exactly one A per row and at least one R. Two accountable owners means no owner; every extra C is a delay you agreed to.
- →Assign the A first, then audit: a column overloaded with letters is a bottleneck, a veto-holder marked only I is a hidden blocker.
- →Use it late in the case when asked how to make it happen or why a project stalled — never for sizing, pricing, or what-to-do questions.
The framework at a glance
When to use it
Reach for RACI in the last third of a case, once the analysis is done and the interviewer asks some version of how do we actually make this happen, who owns it, or what could go wrong in execution. It is the natural companion to any prompt where multiple functions touch the same outcome: a post-merger integration where two sales teams must merge, a product launch needing Tech, Risk, Marketing and Ops to move in sequence, a turnaround where cost cuts must be enforced by plant heads who do not report to the CFO, a regulated launch where compliance sign-off gates everything, or a client who says the strategy is fine but nothing moves. It is also the right answer when the interviewer describes symptoms rather than a task — decisions get relitigated, deadlines slip with no one at fault, approvals arrive after the work is done, or two teams built the same thing. Do not use it for market sizing, profitability trees, pricing, or any question about what to do rather than who does it.
What it is
A RACI matrix is a simple grid that answers one question for every important piece of work: who exactly is doing what. Down the left side you list the decisions and deliverables. Across the top you list the people, teams or functions involved. In each cell you write one of four letters. R means Responsible: this person actually does the work. A means Accountable: this person owns the outcome, signs off, and carries the blame if it goes wrong. C means Consulted: their input is genuinely sought before the thing is finalised, and the conversation runs both ways. I means Informed: they are told after the fact, one way, no debate expected. The formal name of the tool is the responsibility assignment matrix; RACI is just the most common set of letters.
Keep reading ↓Show less ↑
The whole power of the framework sits in one rule: exactly one A per row. Not zero, not two. The moment two people are accountable for the same deliverable, accountability evaporates, because each one quietly assumes the other is watching it. A single A means there is always one person who can say yes, one person to escalate to, and one person whose calendar you check when a milestone slips. R can be shared across several people. C and I can be many. A cannot. The second rule is that every row needs at least one R, otherwise you have written down an intention rather than a plan.
RACI is deliberately unglamorous. It is not a strategy tool and it will never tell you what to do. It is an execution tool that surfaces the organisational friction that kills good strategies: the approval nobody knew was needed, the function that found out too late, the decision three people each thought someone else was making. In consulting decks it usually appears on the implementation page, after the recommendation, next to a timeline and a set of KPIs. Because it is so easy to read, it also works in reverse as a diagnostic: fill in how a stalled project runs today, and the bottlenecks show up as visual patterns — a column where one person is A on everything, a row with four Cs and no R, a function that appears only as I but keeps blocking releases anyway. Common variants swap or add letters: RASCI adds S for Support (helps the R without owning it), CAIRO adds O for Omitted (explicitly out of the loop, which stops people lobbying to be added), and DACI reframes it for decisions with a Driver, Approver, Contributors and Informed.
How to apply it, step by step
- 1
List the deliverables and decisions, not the tasks
Write 8 to 15 rows, each a milestone-level output or a real decision point: approve the credit policy, sign the vendor contract, launch the pilot in 3 cities, go or no-go on national rollout. Phrase each as a verb plus an output so it is unambiguous when it is done. If you list 60 granular tasks the matrix becomes a project plan nobody reads; if you list 3 vague themes it hides the exact handoffs you are trying to expose. Decisions belong on the list as much as deliverables, because that is where projects actually stall.
- 2
List roles across the top, not names
Columns should be roles or functions: Chief Risk Officer, Regional Sales Head, Partner Bank, IT Delivery Lead, Steering Committee. Roles survive attrition and transfers; names do not. Include external parties too, such as the vendor, the channel partner or the regulator-facing compliance team, because that is exactly where handoffs break. Keep it under about 8 columns; if you need more, you are probably mixing two projects into one matrix.
- 3
Assign the A first, one per row, before anything else
Go row by row and name the single person answerable for that outcome. Do this before assigning R, because it is the hardest and most political column and doing it first forces the real conversation. The A must be senior enough to break a tie and close enough to the work to notice it slipping. If a row genuinely seems to need two As, that is a signal the row is really two deliverables and should be split.
- 4
Assign R, then C and I sparingly
R is whoever does the hands-on work; multiple Rs are fine as long as the A can coordinate them. Then be ruthless with C, because consulted means you will wait for their input before proceeding, so every C you add is a delay you have agreed to. Everyone else who merely wants visibility gets an I, which costs nothing but an email. When someone lobbies to be a C, ask what decision would change based on their input; if the answer is none, they are an I.
- 5
Audit the grid horizontally and vertically
Read each row: exactly one A, at least one R, and no row that is all Cs. Then read each column: a person who is R on everything is a burnout and a bottleneck, a person with no letters at all should not be in the room, and a function that is only ever I but holds a veto in practice is a hidden blocker you have just discovered. This audit pass is the step that produces the actual insight, and it is what separates a real RACI from a decorated table.
- 6
Pressure-test the handoffs and escalation path
For each row, ask what happens when the R and the C disagree, and how long the A has to resolve it. Write the escalation rule down, for example unresolved after 5 working days goes to the steering committee. Also check sequencing: if the compliance sign-off row sits after the marketing spend row, you have designed a rework loop into your own plan.
- 7
Attach dates, publish, and re-baseline at phase gates
A RACI without dates is a philosophy. Put a target date and a status against each row so it becomes the standing agenda for the weekly review. Circulate it to every named role and get explicit acknowledgement, because unagreed accountability is just a consultant's opinion. Revisit it at each phase gate, since the pilot RACI and the national rollout RACI are almost never the same as ownership shifts from a central project team to line business owners.
Worked example
Nivara Finance, a mid-size Chennai-headquartered NBFC, is launching a co-branded credit card with a Bengaluru fintech partner, targeting salaried customers in Tier-2 cities. The board approved the business case nine months ago and the pilot has slipped twice. The credit policy has been rewritten three times because Risk and the fintech kept reopening the approved cut-offs, compliance sign-off on the RBI co-branding norms landed after Marketing had already printed launch collateral for 40 branches, and when the MD asked in the last review who owns the go-live decision, four people answered. The engagement team concludes the strategy is sound; the failure is execution ownership. They build a RACI.
Step 1: Set the rows
The team lists nine milestone-level deliverables and decisions rather than a 200-line project plan: approve the credit policy and risk cut-offs, sign the partner commercial agreement, obtain RBI co-branding compliance sign-off, build and test the card management system integration, complete the DPDP customer data review, finalise pricing and reward structure, train branch and telesales staff, launch the 3-city pilot, and make the national rollout go or no-go call.
Step 2: Set the columns
Roles across the top: Chief Risk Officer, Head of Retail Products, Compliance Head, IT Delivery Lead, CMO, Regional Sales Head, the Fintech Partner, and the Steering Committee chaired by the MD. Nothing is written by individual name, so the matrix survives the IT Delivery Lead leaving in month four.
Step 3: Assign the single A per row
Approve credit policy: A is the Chief Risk Officer. Partner commercial agreement: A is Head of Retail Products. RBI compliance sign-off: A is Compliance Head. System integration: A is the IT Delivery Lead. Pricing and rewards: A is Head of Retail Products. Staff training: A is Regional Sales Head. Pilot launch: A is Head of Retail Products. National rollout go or no-go: A is the MD as Steering Committee chair. Naming one A on the credit policy immediately ends the rewrite loop, because the CRO alone can close it and the fintech becomes a C rather than a co-owner.
Step 4: Fill R, C and I
Credit policy: R is the Credit Policy Manager, C is the Fintech Partner and Legal, I is Marketing and Sales. RBI compliance sign-off: R is the Compliance Manager, C is Legal and the Fintech Partner, I is everyone else. Marketing collateral sits inside the pilot launch row with the CMO as R, and crucially that row is sequenced after compliance sign-off, so no printing happens until the I email from Compliance lands. Only two rows give the Fintech Partner a C, which stops the partner being consulted on everything and halving Nivara's decision speed.
Step 5: Audit the grid
Reading across, one row initially had two As because pricing was shared between Retail Products and the fintech, so it is split into Nivara-side pricing and partner-side reward funding, each with one A. Reading down, Head of Retail Products is A on four of nine rows and R on two more, a clear overload, so the training and pilot logistics R shifts to a dedicated launch manager. Compliance appears only as I on the marketing rows despite holding a real veto, which is exactly the hidden blocker that caused the wasted print run, so it is upgraded to C on collateral approval.
Step 6: Operationalise it
Each row gets a target date and a red-amber-green status, the grid becomes the one-page agenda for the fortnightly steering meeting, and an escalation rule is added: any R and C disagreement unresolved after five working days goes to the A, and any A-level deadlock after five more days goes to the MD. The team commits to re-baselining the matrix at the pilot-to-national gate, where ownership moves from the central launch team to the Regional Sales Heads.
Takeaway: Nothing about Nivara's strategy changed. What changed is that nine deliverables now have exactly one name each that can say yes, the compliance gate sits before the spending gate instead of after it, and the one genuinely overloaded executive has been unloaded. In a case interview, that is the answer to how do we make this happen: not more analysis, but a visible map of who decides, who does, who is asked, and who is merely told.
More worked examples
Worked example: reading the 2017 Equifax breach as a RACI diagnostic+
Equifax, one of the three large US credit bureaus, disclosed in September 2017 that attackers had accessed personal data on roughly 147 million consumers. Public accounts from the US GAO and the House Oversight Committee describe a chain that was not primarily a technology failure: a critical Apache Struts vulnerability (CVE-2017-5638) was publicly disclosed in early March 2017, an internal notice to patch was circulated by email, and the patch was still not applied to a legacy consumer dispute portal (ACIS) when attackers used it in May. A follow-up vulnerability scan did not flag the unpatched system, and an expired certificate on a network traffic-inspection device meant encrypted exfiltration ran unnoticed for roughly 76 days. Treat this as a RACI case: rebuild the grid for how patching actually ran, and the failure pattern becomes visible before you touch a single line of code. All figures below are as publicly reported and rounded.
Consumers affected (reported)
~147 million
Days exfiltration undetected
~76
Inspection certificate expired for
~19 months
CVE disclosure to internal scan
~6 days
Settlement value (approx.)
up to ~$700M
Step 1: Set the rows as decisions and deliverables, not tasks
Resist writing 'run scan' or 'apply patch' as rows, because those are activities and activities hide owners. The honest row set is six milestone-level outputs and decisions: patch every internet-facing application affected by a disclosed critical CVE within the stated SLA; certify that the verification scan actually covered every in-scope asset; keep traffic-inspection certificates current so encrypted traffic remains visible; decide whether a consumer-facing portal stays online while it is known-unpatched; own the legacy ACIS dispute portal end to end through its sunset; and notify regulators and consumers once a breach is confirmed. Notice that four of those six are decisions, not deliverables, which is exactly where the chain broke.
Step 2: Set the columns as roles, including the reporting line itself
Columns: Global Threat and Vulnerability Management, the ACIS application owner in the business line, IT Operations under the CIO, the Chief Security Officer's function, Legal and Compliance, Internal Audit, and the Board Audit Committee. One structural fact matters more than any cell: public reporting notes the security function reported into Legal rather than into the CIO. In RACI terms that means the column that could see the risk and the column that controlled the servers sat in different chains of command, with no shared A above them below the CEO. That is a column-level defect you can spot before assigning a single letter.
Step 3: Assign the A first, and find the row that has none
For 'patch all affected internet-facing apps', the A cannot be the security team, because security can detect and demand but cannot take a revenue-facing portal offline or schedule downtime. The A must be the ACIS application owner in the business, who alone can trade availability against risk. What actually happened is the RACI failure mode in its purest form: a notice went to a broad internal distribution list. A broadcast is an I. Sending an I to forty people and expecting one of them to behave like an A is the single most common way organisations lose a deliverable, and it is why the framework insists the A is named before anything else.
Step 4: Fill R, C and I, and keep the fixer separate from the verifier
For the patch row, R is the ACIS engineering team, C is Threat and Vulnerability Management on whether a compensating control is acceptable, and I is the CIO and Audit. The verification row is the subtle one: whoever is R for applying the patch must not also be R for confirming it was applied, or you have written a self-certification loop into your own control. Give the scan row a separate R in security and an A in IT Operations who must reconcile scan coverage against the asset inventory. The certificate row is starker still, on the public account it effectively had no letters at all, which is the fourth failure mode: a deliverable everybody assumed was somebody's.
Step 5: Audit the grid horizontally and vertically
Read horizontally and two rows fail immediately: the patch row has an R and several Is but no A, and the certificate row has neither. Read vertically and the pattern is worse. The security column is R on almost everything (detect, notify, scan, monitor) and A on almost nothing, which is the classic pattern of a function that can raise its hand but cannot stop the business. The CIO column is A for uptime but only I on vulnerability status, so the one executive with authority over the servers was structurally the last to know. Split accountability between the CSO line and the CIO line is the two-A problem dressed in an org chart: each side could reasonably assume the other was watching.
Step 6: Make it operational with an SLA and an escalation clock
The fix that falls out is not more tooling, it is dated accountability. Every critical internet-facing CVE gets a row with the application owner as A and a 48-hour patch SLA; if the A chooses not to patch, the A signs a documented risk acceptance rather than letting silence pass as a decision. Unpatched at day 7 escalates to the CIO, at day 14 to the Audit Committee, so the clock, not a human's memory, does the chasing. Every certificate and every legacy application heading for sunset gets a named accountable owner at the moment it is deprioritised, because that is precisely when things get orphaned. Re-baseline the grid whenever an application changes owner, since the previous A leaving is how rows silently go blank.
Takeaway: The RACI reframes a headline cyber failure as an ownership failure you could have diagrammed in an afternoon: one row with an I where an A belonged, one row with no letters at all, a verifier who was also the fixer, and two senior functions in separate reporting lines each assuming the other held the outcome. Better scanning tools would not have fixed any of those four. In an interview, the transferable line is that when a control 'exists' but keeps failing, do not audit the control, audit who is accountable for it — an unpatched server is a symptom, an unowned row is the disease.
Worked example: quick-commerce dark-store rollout across 12 Indian tier-2 cities+
Your client is a top-three Indian quick-commerce player that has saturated the top 8 metros and has board approval to open 180 dark stores across 12 tier-2 cities (Nashik, Nagpur, Vijayawada, Rajkot, Coimbatore and similar) in 9 months. Wave 1 covering 3 cities and 46 stores has slipped roughly 11 weeks. Real estate signed leases fast on the promise of aggressive rent, fit-out finished on schedule, and 46 stores are now sitting complete and dark, waiting on FSSAI registration and fire NOCs, because a large share of the sites are in mixed-use residential buildings where a fire NOC for commercial storage is slow or simply unobtainable. The CEO's brief in the room is blunt: the unit economics still work, so tell us who has to own what so wave 2 does not do this again. Figures below are illustrative.
Rollout target
180 stores, 12 cities, 9 months
Capex per dark store (illus.)
~Rs 28 lakh
Wave-1 slip
~11 weeks
Stores fitted out but dark
46
Idle burn, rent + depreciation (illus.)
~Rs 1.7 crore
Step 1: Rows at milestone altitude, with the real gates included
Ten rows, each a verb plus an output or a genuine go/no-go: approve the city entry sequence and store count per city; approve the site shortlist against a written site standard; sign the lease; obtain the licence pack (FSSAI registration, shops and establishments, trade licence, fire NOC); complete store fit-out and cold-chain commissioning; lock the city assortment and its dark-store planogram; contract rider supply with the 3P fleet aggregator; switch the store live in the app and open the delivery polygon; run the launch offer and hyperlocal marketing; and take the city-level go/no-go at week 12 on contribution margin. A student instinct is to write 40 rows down to 'order racking' — resist it. Racking never stalled this project; the licence gate did.
Step 2: Columns are the eight functions that touch a store, including the outsiders
Head of City Expansion, Property and Real Estate, Legal and Licensing, Supply Chain and Network Design, Category and Merchandising, City Ops (store managers and dark-store staffing), Tech and Product, and the 3P Rider Aggregator, with a Steering Committee chaired by the COO. Two of those columns are the ones students forget and interviewers reward. The rider aggregator is external and controls whether a live store can actually deliver in 10 minutes, and Legal and Licensing is internal but usually treated as a back-office rubber stamp rather than a function that can gate Rs 28 lakh of capex per site.
Step 3: Assign one A per row, and force the political ones
City entry sequence: A is Head of City Expansion. Site shortlist approval: A is Head of City Expansion, not Property, because Property's incentive is signed leases per month and the A must be able to reject a cheap site. Lease signing: A is Property. Licence pack: A is Legal and Licensing. Fit-out and cold chain: A is Supply Chain. Assortment: A is Category. Rider contract: A is City Ops. Store go-live: A is City Ops. Launch marketing: A is the CMO. City go/no-go at week 12: A is the COO as Steering chair. The hard one is the shortlist row, and it is worth arguing out loud in an interview — separating the A for 'is this the right site' from the A for 'sign the paper' is the structural fix for a real-estate team optimising the wrong metric.
Step 4: Fill R, C and I, and put Legal upstream where it costs nothing
Site shortlist: R is the city property manager, C is Legal and Licensing and Supply Chain, I is Category and Tech. That single C is the whole answer to the case. Legal was previously only I on the shortlist row and A on the licence row, meaning they first saw a site after the lease was signed and the capex committed. Consulted at shortlist, Legal supplies one page of NOC-ability rules (standalone commercial building or industrial-zoned plot, ground floor with independent access, fire NOC feasible for the storage category), and the unbuildable sites are killed at zero cost instead of at Rs 28 lakh. Keep C discipline elsewhere: the rider aggregator is C on go-live and the delivery polygon only, and I on everything else, so a vendor is not consulted on assortment and does not add a week to every decision.
Step 5: Audit the grid both ways
Horizontally, the launch marketing row initially carried two As, CMO for national brand and the city lead for local spend, so it is split into national creative (A: CMO) and city launch budget (A: Head of City Expansion), because a single row that two people genuinely own is always two rows. Vertically, City Ops turns out to be A on three rows and R on four more across 15 stores at once, a guaranteed bottleneck, so a dedicated launch manager per city takes R on fit-out coordination and staffing while City Ops keeps the A. And the classic hidden blocker shows up: Tech appears only as I everywhere, yet no store can transact until the store ID, polygon and inventory feed are configured, so Tech gets an explicit R on the go-live row with a 5-working-day standing SLA.
Step 6: Sequence it, date it, and re-baseline at the wave gate
The sequencing audit is the money step. Today the order is shortlist, lease, fit-out, licence, and that ordering alone created 46 dark stores and roughly Rs 1.7 crore of idle burn. Re-sequenced, the licence pre-check sits inside the shortlist row and the licence application is filed at lease signing, in parallel with fit-out rather than after it, which pulls roughly 6 to 8 weeks out of the store cycle at zero incremental cost. Each row gets a target date per store cohort and an RAG status, the grid becomes the weekly expansion review agenda, and the escalation rule is written down: an R and C deadlock unresolved in 5 working days goes to the A, an A-level deadlock in 5 more goes to the COO. Re-baseline at the wave-1 to wave-2 gate, because once stores are live the A on store performance moves from the central launch team to the city P&L owner.
Step 7: Say what the grid does not do
Be explicit with the interviewer that RACI has not improved the unit economics by a single rupee. It has not told the client which 12 cities, what basket size supports a Rs 28 lakh store, or whether the 10-minute promise holds in Nashik. Those are separate analyses. What it has done is convert an 11-week slip with no culprit into a named owner per gate and a re-ordered sequence, which is the difference between a plan and a slide.
Takeaway: The strategy did not change: 180 stores across 12 cities is still the right call. What the matrix produced is one function moved upstream from Informed to Consulted so that unlicensable sites die before the lease rather than after the fit-out, one row split because two people genuinely owned it, one overloaded City Ops lead unloaded, and a licence step run in parallel with fit-out instead of behind it, worth roughly 6 to 8 weeks per store cohort. The interview-ready version is five rows spoken aloud plus the one-A rule stated explicitly, then the offer to extend it to ten rows on the engagement.
Common pitfalls
- •Two people accountable for the same row. This is the most common failure and it is worse than having nobody, because each A assumes the other is watching. If a row seems to need two owners, the row is really two deliverables and should be split.
- •Confusing Responsible with Accountable. R does the work, A answers for the result. A junior analyst can be R on the pricing model while the Head of Retail Products stays A; collapsing the two either makes juniors carry blame they cannot control or makes executives micro-manage spreadsheets.
- •Consulting everyone. Every C is a queue you have voluntarily joined. A matrix stuffed with Cs looks inclusive and produces a project where nothing ships because someone is always still reviewing. Ask what decision would change with their input; if nothing, they are an I.
- •Writing it at the wrong altitude. Sixty task-level rows turn the matrix into an unread project plan, while three vague themes hide the exact handoff you were trying to fix. Milestone-level deliverables and real decision points are the right grain.
- •Treating it as a one-time artefact. Ownership legitimately changes between pilot and scale, and a RACI that is never re-baselined quietly becomes fiction that people cite in arguments. Refresh it at each phase gate.
- •Building it in a room the accountable people never entered. Accountability assigned without the owner in the conversation is not accountability, it is a consultant's wish. Get explicit acknowledgement from every named role before the deck goes out.
Interview tips
- •Do not lead with RACI. It is an implementation tool, so earn the right to use it by first sizing the prize and landing a recommendation. Bring it out when the interviewer asks about execution, risks, or how the client makes this stick.
- •Say the one-A rule out loud. Stating that each deliverable gets exactly one accountable owner, and that two owners means no owner, is the single line that signals you understand the framework rather than the acronym.
- •Name three or four real roles from the case, not generic ones. Saying the Chief Risk Officer is accountable for the credit policy while the fintech partner is only consulted shows you have absorbed the client's actual org, which is what interviewers score.
- •Use it as a diagnostic when the prompt is about a stalled project. Mapping how ownership works today often reveals the answer directly: an overloaded executive, a function with a veto but no seat, or a decision nobody was assigned.
- •Keep the verbal version to about five rows. You cannot draw a full grid in a live interview, so walk through the highest-risk deliverables and their owners, then say you would extend it to roughly ten rows on the engagement.
- •Pair it with a timeline and one or two risks. Interviewers want the implementation answer to have sequence and ownership together: what happens in the first 90 days, who owns it, and what breaks if that person is unavailable.
Test yourself
Best video explainers
What is RACI Matrix | Responsibility Assignment Matrix | RACI Chart Tutorial for Beginners [Example]
Passionate Business Analyst
The most complete beginner walkthrough of the four letters, with a worked matrix built on screen. Start here if you have never seen a RACI.
What is a RACI Matrix? [CLEAR BREAKDOWN]
Adriana Girdler
A practising project manager explains the one-accountable rule and the politics of assigning it, which is the part students consistently get wrong.
RACI Charts Explained | How to use a RACI Matrix as a Project Manager
The Digital Project Manager
Focuses on how the chart is used week to week through handoffs and escalation, rather than just defining the acronym.
RACI Matrix Basics Explained with Examples | TeamGantt
TeamGantt
Short and example-heavy, showing how RACI rows connect to a real project timeline, which is exactly the implementation-slide framing.
What is a RACI matrix?
TECHtalk
A crisp few-minute overview, useful for revision right before a mock interview rather than a full tutorial.
Go deeper
RACI Chart: What is it and How to Use It
Atlassian (The Workstream)
Clean practitioner explanation of the four roles plus guidance on when a RACI is worth the effort and when it is overkill.
RACI Charts: The Ultimate Guide, with Examples
Asana
Step-by-step build instructions with several filled-in example matrices whose structure you can copy.
Responsibility Assignment Matrix
Wikipedia
The neutral reference for the formal rules (at least one Responsible, normally one Accountable) and the full list of variants such as RASCI, CAIRO, DACI and PARIS.
RACI Chart Explained: Roles, Responsibilities and Project Management
Smartsheet
The most detailed free guide, covering common mistakes, alternatives to RACI, and downloadable templates.
What Is a RACI Chart? Meaning, Uses, and Benefits
Coursera
Short, plain primer that works well for last-minute revision the night before an interview.
Now use it on a real case
Reading a framework isn't the same as applying it under pressure. Practise with an AI interviewer that pushes back.
Practise a case free