From risk owners to role clarity
Session 4 taught you that a risk owned by "the team" is owned by nobody. The same truth governs every activity on the build. When the raw load stalls, when governance has not signed off, when architecture is waiting - the first question is always "whose call is this?" RACI is the one-page answer: for each activity, exactly one letter per role, with a single accountable owner who cannot be shared. Today we fill it in for Northwind, internal seats and external partners together.
RACI: one letter per role per task 5 min live
RACI assigns each role one letter for each activity. Responsible does the work. Accountable is the single owner who answers for the outcome - only ever ONE per row. Consulted gives two-way input before the work is done. Informed gets a one-way update after. The grid below is Northwind's, four activities against six roles.
LiveThe one-accountable rule3 min▶
The whole matrix hangs on one discipline: exactly one A per row. Responsible can be shared (two teams do the work), Consulted and Informed can be many. But Accountable is singular - the one person who answers for the outcome and makes the final call within that activity. Two A's mean a stand-off; zero A's mean an orphan.
- R - Responsible: does the hands-on work. Can be more than one role.
- A - Accountable: owns the outcome, signs it off, one per row, no exceptions.
- C - Consulted: two-way input before the work - their view shapes it.
- I - Informed: one-way update after - kept in the loop, not asked.
Self-studyRACI vs RASCI / DACI variants2 min read▶
RACI is the base model; the variants add a letter for a specific gap. Use the simplest one that removes real confusion - extra letters that nobody enforces just add noise.
| Model | Adds | Use when |
|---|---|---|
| RACI | the four base roles | most projects, default choice |
| RASCI | S = Support (helps the R do the work) | large teams where "who assists" is unclear |
| DACI | D = Driver, focuses on a single decision | decision-heavy work, one call at a time |
For Northwind, plain RACI is enough - the one addition worth making explicit is that external partners get letters too, which we handle next.
Internal owners vs external cross-functional parties 5 min live
A data platform build is never all in-house. Northwind's RACI spans two lanes: internal seats who own outcomes, and external cross-functional parties who own deliverables you depend on but do not control. Mapping both - and being honest about which A's sit outside your own org - is what stops the "we assumed they were handling it" gap.
LiveMapping external accountability3 min▶
The instinct is to make every A internal - "we own everything." It is wrong and it is dangerous. If the source dev team owns the data dictionary, they are Accountable for it; pretending Priya owns it means nobody chases the real deliverable and the gap surfaces in month three.
- Source dev teams (external) own the dictionary, ERDs, keys, and table clarifications. They are Accountable for those deliverables; you are Consulted and Informed.
- Cloud / infra partner (external) owns the landing zone, VPC, IAM, and security baseline. Accountable for the environment; you set the requirements.
- Governance office (external to the delivery team) owns classification, PII policy, retention, and lineage. Accountable for the sign-off that gates M2.
When an external party owns an A, the RACI is only half the tool - the other half is a written expectation (an SLA, a due date, a definition of done) that the internal PMO tracks. RACI names the owner; the delivery agreement makes the ownership enforceable across an org boundary you cannot manage directly.
Self-studyKnowledge transfer as a shared responsibility2 min read▶
Knowledge transfer is the one activity that genuinely spans the boundary - the source dev teams hold the knowledge, the internal data team needs it. Getting the RACI right here prevents the classic KT failure where handover happens once, informally, and is gone the moment the source team moves on.
- Source dev = Responsible for delivering the walkthroughs, docs, and answers.
- Head of D&A = Accountable that KT actually lands - not "was scheduled", but that the receiving team can operate the data.
- PMO = Consulted / tracking that the KT programme is formal and evidenced, not a single ad-hoc call.
Escalation & the RACI anti-patterns 5 min live
RACI names owners within an activity; escalation names who breaks a tie when owners disagree or a decision sits above the activity. And the matrix itself has failure modes - four anti-patterns that make ownership look documented while decisions quietly stall. Here are three, each with its fix.
LiveDesigning escalation paths3 min▶
Escalation is the answer to "what happens when the A's disagree, or the call is bigger than any single activity?" It is a short, named ladder - not a vague "raise it to management." For Northwind the ceiling is the CEO, who set the mandate and is the final yes.
- Name the ceiling: the single final decision-maker. For Northwind that is the CEO; the Executive Sponsor is the step below.
- Name the rungs: activity owner (A) → Head of D&A → Executive Sponsor → CEO. Each rung is a real person who can actually decide.
- Set the trigger to escalate: a decision stuck past a defined point, or a risk trigger firing (from Session 4), moves up one rung - it does not float.
Self-studyThe over-Consulted slowdown2 min read▶
Of the four anti-patterns, over-Consulted is the sneakiest because it looks like good inclusion. Every stakeholder gets a C, so every decision waits on every voice, and a two-day call becomes a two-week round-robin. The matrix is "complete" and the project is stuck.
- Consulted means two-way input before the work - reserve it for roles whose view genuinely changes the outcome.
- Demote the rest to Informed: people who need to know but not to weigh in get an I, and the decision keeps moving.
- The test: if a Consulted role has never once changed a decision, it should have been Informed. Count your C's per activity - a column of them is a red flag.
Fill RACI for four Northwind activities ★ 7 min · everyone fills
Take the four activities: M1 raw load, governance sign-off, hiring panel, architecture approval. For each, assign every internal role (Sponsor, Head of D&A, PMO) one letter.
Enforce the rule as you go: exactly one A per row. If a row has two A's, argue it out until one owner stands; if it has none, you have found an orphan.
Fill the table below, then scan the A column top to bottom - it should read Head D&A, Gov, Sponsor, Head D&A. One clear owner per activity.
| Activity | Sponsor | Head D&A | PMO | Src dev | Cloud | Gov |
|---|---|---|---|---|---|---|
| M1 raw load | I | A | R | C | R | I |
| Governance sign-off | I | C | I | I | I | A |
| Hiring panel | A | R | C | I | I | I |
| Architecture approval | I | A | I | C | R | C |
Add the external parties to the grid ★ 9 min · everyone extends
Add three external columns: source dev team, cloud / infra partner, governance office. These are the parties you depend on but do not manage directly.
Give each their real A: source dev is Accountable for the data dictionary and keys; cloud partner for the landing zone; governance office for the classification sign-off. Resist the urge to make every A internal.
For every external A, note the delivery agreement that backs it - a due date or definition of done the PMO tracks across the org boundary. RACI names the owner; the agreement makes it enforceable.
Compare with a neighbour: did you both put governance sign-off's A on the governance office, not on Priya? That is the honest map.
The most expensive RACI mistake on a platform build is a silent external A - a dictionary the source team was "obviously" going to finish, that nobody wrote down as their accountability. It becomes R1 in the risk register. Naming the external A here is what lets the PMO chase it before it slips.
Find and fix one broken row ★ 6 min · everyone fixes
Here is a deliberately broken row for "certified dataset release": Sponsor = A, Head of D&A = A, PMO = C, Source dev = C, Cloud = C, Governance = C. Spot the anti-patterns.
Two problems: two A's (many-A stand-off) and four C's (over-Consulted crawl). Fix the A first - one owner. Certifying a dataset is a data-quality outcome, so the A belongs to the Head of D&A; the Sponsor drops to Informed.
Trim the C's: keep governance as Consulted (their classification genuinely shapes certification), demote the rest to Informed. Read the fixed row aloud - one A, one meaningful C, the rest I.
This week ◐ 30 min total
- Build a RACI for a real project at your desk - list the activities, list every role including external partners, and put exactly one A in each row.
- Hunt your own anti-patterns: scan an existing project's ownership and find a no-A orphan, a many-A stand-off, or an over-Consulted column. Fix one.
- Read the self-study cards above: RASCI/DACI variants, knowledge transfer as shared responsibility, the over-Consulted slowdown.
- Optional deep end: read a responsibility-assignment-matrix primer, and sketch the escalation ladder for your current initiative - name the ceiling.
Three questions before you go 🎯 ◐ 90 seconds
1 · What does the A in RACI mean, and how many per row?
Accountable is singular by design. R can be shared and C and I can be many, but exactly one A per row - two means a stand-off, zero means an orphan. Scan the A column first when reviewing any RACI.
2 · Who should be Accountable for Northwind's governance sign-off?
Governance sign-off is the governance office's deliverable, even though it sits outside the delivery team. Making its A internal would leave the real owner unchased - and it is a hard gate on M2.
3 · What is the over-Consulted anti-pattern?
It looks like good inclusion but stalls delivery - a two-day call becomes a two-week round-robin. Reserve C for roles whose input truly changes the outcome; demote the rest to Informed.
Frameworks covered & their origins
This course teaches the working 80% of each tool and cites the canon - full standards stay the deep end for anyone who wants them.