Who owns the next step?
The release build is ready. The customer guide is unfinished. Fieldnote’s engineer thinks the product lead will decide whether to launch; the product lead thinks support has the final readiness check. Nobody intended to leave a gap. Everybody was busy completing a different piece of the work.
Fieldnote is a hypothetical software company launching a customer portal. Its product lead, engineer, support lead, and launch dilemma are fictional.
A RACI matrix makes involvement explicit: responsible, accountable, consulted, and informed. PMI describes it as a type of responsibility assignment matrix. Rows name activities or deliverables; columns name people or roles; letters describe participation.
Find the decision hidden between deliverables
Fieldnote starts by naming the build, acceptance criteria, guidance, and launch decision separately. “Launch portal” is too broad to reveal the handoff. People can finish three deliverables and still disagree about whether the fourth decision has an owner.
The first map shows the gap rather than pretending a letter solves it. The team needs somebody who can decide, somebody to assemble readiness evidence, and a shared understanding of the conditions under which launch is acceptable.
An empty cell means no involvement is assigned on that row. It does not mean the person is unimportant.
The four roles in practice
| Work | Product lead | EngineerEng. | Support lead |
|---|---|---|---|
| Acceptance criteria | R/A | C | C |
| Release build | C | R/A | I |
| Customer guidance | C | I | R/A |
| Launch readiness | A | C | R |
Read across a row to see who does the work and who owns completion. Read down a role’s column to check its total involvement. The diagram’s fictional launch example has one accountable role per row, which is FrameworkWorld’s recommended default for clear ownership.
Responsible: performs the work
The responsible role carries out the activity or produces the deliverable. More than one person can contribute, but the team still needs a clear handoff. A row with no responsible role describes work that nobody has agreed to do.
Accountable: owns the result
The accountable role answers for completion of the row and ensures the relevant decisions are made. For this working method, choose one accountable owner per row. That owner needs the authority to resolve the row’s normal decisions, not merely a name beside a letter.
One person may be both responsible and accountable on a small task. Write R/A if that makes the combined role clearer.
Consulted: contributes before the decision
A consulted role provides input before the work or decision is finalized. Make the question and timing explicit. Adding someone as C should create a real opportunity to contribute, not a last-minute request to endorse a finished result.
Informed: receives the relevant update
An informed role needs to know the outcome or status. Specify when and through which channel. Being informed does not automatically grant approval authority.
The definitions organize participation. The one-owner rule and review steps here are practical editorial guidance, not a claim that every organization’s governance uses identical conventions.
Choose rows that make ownership possible
A row should describe something clear enough to finish or decide. “Customer portal” is usually too broad: engineering, support, and product may each own different parts. “Agree launch acceptance criteria” and “prepare customer guidance” make the boundaries easier to discuss.
Do not turn the chart into a list of every tiny action. If several actions share the same owner and handoff, a deliverable-level row may be enough. Add detail when a boundary or decision would otherwise be ambiguous.
For this working method, prefer one accountable owner per row. That person must be able to resolve its normal decisions. A senior name with no time or authority is not useful accountability.
Consultation also needs a boundary. State what input is requested, when it is due, and what happens if the reviewer cannot respond. C does not automatically mean veto, and I does not create a hidden approval gate.
These conventions need agreement with the participants. Some organizations have formal joint approvals that a single letter cannot explain. Write those requirements beside the relevant decision rather than pretending the default rule replaces governance.
Assign Fieldnote’s deliverables and launch decision
For the acceptance criteria, the product lead is both responsible and accountable. Engineering and support are consulted because they can identify technical and customer-service gaps before the criteria are settled.
For the release build, the engineer is responsible and accountable. The product lead is consulted to confirm the agreed scope, while support is informed when a candidate build is ready. Giving the product lead an accountability letter on every technical row would obscure which decisions engineering can make.
For customer guidance, the support lead is responsible and accountable. Product is consulted about commitments, and engineering is informed when the guide is ready.
The review exposes a missing decision: who decides whether the portal launches when the guide is unfinished? The team adds a launch-readiness row: the product lead owns the decision, support assembles the evidence, and engineering is consulted. It also writes the required readiness checks beside that row. RACI uncovered the ownership gap, but the team had to define the decision criteria separately.
Make the launch decision its own row
| Readiness evidence to record beside the RACI row | Question it helps resolve |
|---|---|
| Status of the agreed technical checks | Is the release build ready for this scope? |
| Status of customer guidance | Can support explain the workflow being launched? |
| Outstanding blockers and dependencies | What prevents the launch conditions from being met? |
| Decision and reason | What was agreed, and what happens next? |
These are suggested readiness questions for the hypothetical launch. In the matrix shown earlier, support assembles this evidence and the product lead owns the decision after consulting engineering. The criteria and evidence sit beside the role assignments, where everyone can inspect them.
That last distinction matters. Giving someone A does not tell them whether an incomplete guide is acceptable, which technical checks are mandatory, or whether a staged release is possible. Record those criteria and escalation rules alongside the matrix.
Walk through a difficult handoff before relying on the chart. If engineering reports a late blocker, who receives it? Who can delay the release? How is support told which customer guidance remains accurate? A brief rehearsal can reveal gaps that a tidy table conceals.
Read down the columns too. If the support lead is responsible for both guidance and assembling readiness evidence in the same hour, the plan may contain a bottleneck. Change timing, resources, or ownership before calling that person’s name the solution.
Keep the agreement somewhere the team actually uses and revisit it when roles or scope change. An outdated matrix can create as much confusion as an absent one, especially when it is treated as proof that a handoff happened.
Rehearse the uncomfortable handoff
Imagine engineering finds a blocker just before release. Support assembles the readiness evidence, engineering explains the technical concern, and the product lead owns the launch decision within the agreed governance. The decision criteria still need to be written beside the matrix.
This rehearsal tests the agreement more effectively than asking whether everyone likes the table. Who can delay launch? How does the decision reach support? If those answers are unclear, revise the row and escalation route before relying on it.
How to create a RACI matrix
- Select a bounded project or process. List its important deliverables and decisions as rows. Avoid trying to describe an entire department in one chart.
- Add the roles involved. If a role has several occupants, name who will act for it on this project.
- Assign responsible and accountable roles first. Confirm that the people have capacity and authority, and that the work has an agreed completion condition.
- Add only the consultation needed to improve the decision. Define when input is due and how unresolved concerns are escalated.
- Add informed roles and a useful update point. Use an existing project channel when it serves the need.
- Review rows and columns with the participants. Resolve missing owners, overloaded roles, and unnecessary approval chains.
- Walk through the first real handoff. Revise the matrix if it does not match how work can actually proceed.
Do not finalize assignments by sending a spreadsheet that nobody has discussed. A matrix is useful because people agree to act on it.
Check the matrix before relying on it
A row with several accountable roles can leave a disagreement without a clear resolver. Split the deliverable or decision if genuinely separate owners are needed. Where formal joint approval is required, document that governance explicitly instead of pretending a single letter explains it.
A column filled with R and A may reveal a capacity bottleneck. A chart cannot give an overloaded person more time. Change the assignments or the project scope.
Too many consulted roles can turn every task into a committee. Ask what input each person provides and when it matters. Too few consulted roles can exclude people who will absorb the consequences of a decision.
Limitations and alternatives
RACI does not sequence work, estimate effort, specify quality, or decide priorities. Use a delivery plan for timing and dependencies. For a decision alone, DACI can be a simpler way to distinguish the driver, approver, contributors, and informed audience.
Do not use the matrix as a blame chart after something goes wrong. Review whether the assigned owner had the information and authority needed. An agreed role is not proof that the surrounding process was sound.
Related frameworks
SMART Goals clarifies what result is expected and how it will be reviewed. Use it alongside RACI when an owner has been named but the completion condition remains vague.
Situational Leadership helps choose the direction and support someone needs. RACI assigns responsibility; it does not establish that the responsible person is ready to work without support.
Sources and further reading
- Project Management Institute, PMI Lexicon of Project Management Terms, version 5.0, accessed October 21, 2026, “RACI (responsible, accountable, consulted, informed) matrix” entry. Defines the matrix type and four involvement statuses; downloading the lexicon requires registration.
- Project Management Institute, Partnering: Project Manager and Business Analyst Collaboration, accessed October 21, 2026. Explains the involvement statuses in a collaboration setting. The operating recommendations and fictional example here are FrameworkWorld’s application.