team
Defining a RACI matrix takes one sentence. It is a grid that sets out, for each deliverable in a piece of work, who does it, who owns and approves it, who must be asked, and who must be told. The definition is not where teams get stuck. They get stuck at the next question, which is where to draw the lines when the same four people appear in every column and one of them is the person asking.
The definition given in project management references is broader than the acronym. A responsibility assignment matrix is any table that maps work to roles, and RACI is the most common set of markings used inside one. That distinction matters in practice because it means the four letters are a convention, not a law. A small team is entitled to adapt them, and the useful question is which of the distinctions are load bearing and which are borrowed from organisations with sign off chains that a team of six does not have.
Rows are deliverables. Columns are roles. Cells carry one of four markings.
Responsible is assigned to whoever performs the work. More than one name is permitted, because two people can share production of a single deliverable. It confers no authority.
Accountable is assigned to the single person who owns the outcome and has the standing to approve it. This is the letter with the decision in it, and the definition breaks the moment two names appear in it on one row.
Consulted is assigned to people whose input must be obtained before the deliverable is finished. The definition includes an obligation running the other way: a person marked Consulted owes an answer, and the deliverable is entitled to wait for it.
Informed is assigned to people who must be told once a decision is taken or the work is complete. There is no obligation to respond, and no expectation of influence.
Two properties follow from these definitions and are worth stating because they are frequently violated. The matrix is defined over deliverables, not over activities: a row must be something that can be declared finished. And every marking is a commitment by somebody, which means an over-marked matrix is not a thorough matrix but an over-committed team.
Definitions written in a workshop are tested the first time somebody wants to skip a step. What makes them hold is stating the boundary as well as the duty.
Accountable means this person approves the result and answers for it. It does not mean this person does the work, and it does not mean they must be consulted on every intermediate choice. Charts collapse when the Accountable person is treated as a mandatory checkpoint at every stage rather than at the end.
Responsible means this person produces the deliverable. It does not mean they decide its scope, and it does not mean they are the only person permitted to touch it. Small teams depend on people fixing things outside their rows, and the definition should say so explicitly.
Consulted means an opinion is sought and given before completion. It does not mean a veto. Where a person genuinely holds a veto, they are the Accountable name for that row, or the row needs splitting so that the part they control has its own line.
Informed means told afterwards. It does not mean copied on everything as it happens. A definition that slides into continuous visibility turns the Informed marking into noise, and once people stop reading the notifications the marking is worthless.
The convention belongs to a family of tables that project management references call responsibility assignment matrices, also described as linear responsibility charts. They were formalised for work where the people involved did not share a room: multiple departments, external contractors, formal approval chains, and a volume of deliverables large enough that nobody could hold the whole picture. In that setting the four markings solve a specific problem, which is that the person producing a deliverable and the person answerable for it are almost never the same, and the gap between them is where work goes missing.
A small team has the opposite problem. Everyone can hold the whole picture, and the doer and the owner are usually one person. What a small team lacks is not visibility but resolution: a way to settle, quickly and without a meeting, which of two reasonable people gets the final word.
This is why importing a matrix template unchanged tends to disappoint. The template is answering a question about coordination across distance, and the team is asking a question about authority across a table. Reading the definition with that difference in mind changes what to keep. The Accountable marking earns its place immediately, because it names a decider. The Consulted and Informed markings earn their place on the handful of rows involving people outside the team. And the elaborate variants, with separate markings for support and verification, are solving coordination problems that a team of six does not have yet.
Most published guidance assumes an organisation where the doer, the approver and the sponsor are three different people. On a small team they are often two people or one, and forcing an artificial split produces a matrix that nobody believes. The question is which lines to keep.
| The line | Keep it on a small team | Why |
|---|---|---|
| Responsible against Accountable | Only on rows involving money, contracts, customer promises or irreversible changes | On everything else the same person holds both, and pretending otherwise adds a checkpoint without adding a check |
| Accountable against sponsor | Keep, if a founder or client approves budgets | The person who approves spending is rarely the person who owns delivery |
| Consulted against Informed | Keep, always | This is the line that controls how much waiting is built into the work |
| Consulted against Responsible | Keep | Advising on a deliverable and producing it are different amounts of work in someone's week |
| One row per task | Do not draw | Task level rows make the matrix a duplicate of the board and it will go stale |
The pattern is that the lines worth drawing are the ones that change what happens when people disagree or when something goes wrong. Lines that only formalise a hierarchy are cost without benefit at this size.
There is a second line worth defining explicitly, and it is not in the acronym: the line between the team and everyone outside it. Clients, suppliers and reviewers belong in columns. Matrices drawn only over internal roles omit the rows where most delay actually lives, because the work owed by an external approver is invisible until it is late.
A matrix needs a boundary, and three boundaries are common.
A project matrix covers one project from start to close, and is redrawn at phase boundaries. This is the default and the easiest to keep honest, because the project has an end.
An operations matrix covers recurring work: monthly invoicing, the release process, incident response, security reviews. These matrices are longer lived and more valuable than project ones, because the rows repeat and the cost of an unclear owner is paid every cycle. They also need fewer updates, which makes them cheap to maintain.
A decision matrix covers choices rather than deliverables: which vendor, which framework, whether to take on a client. Mixing these rows into a deliverable matrix is what pushes teams toward heavier variants with extra letters. Keeping a short separate list of recurring decisions, each with one named decider, usually removes the need for any variant at all.
Whichever boundary is chosen, the size that stays current is roughly fifteen to thirty rows. Beyond about fifty the matrix competes with the board for the same job and loses, since the board is the one people open every day.
Four disputes come up almost every time a team defines a matrix. All four are faster to settle if the answer is decided in advance.
Is the manager or the project lead Accountable? Whoever can change the deadline or the scope without asking anybody else. If the manager has to approve a slip, the manager is Accountable and the project lead is Responsible. If the project lead can move a date and simply inform the manager, the lead is Accountable and the manager is Informed.
Can the client be Accountable? Yes, on rows where the client genuinely decides, such as visual direction or a go live date tied to their own launch. Writing this down prevents internal argument about questions the team does not control.
What if someone marked Consulted never replies? The definition has to include a default, agreed when the matrix is published: after a stated period, the Accountable person proceeds and records the decision. Without a default, one unresponsive person can hold a deliverable indefinitely, and the matrix that was meant to speed things up becomes the reason for the delay.
Who is Accountable when the owner is away? Name a deputy only for the rows where a week of waiting is expensive. Doing it for every row doubles the maintenance and dilutes the single owner rule that makes the matrix work.
A definition that exists only in a document is a suggestion. What makes it operative is that the same names appear where the work is tracked.
In practice this means three things. Each deliverable in the matrix exists as a card or task with exactly one assignee, and that assignee is the Accountable name. The people marked Consulted are tagged in the card's discussion, so the obligation to respond is visible to them rather than remembered by somebody else. And the decision, when it is taken, is recorded on the card itself, which is what makes it possible six weeks later to answer why something was done a particular way.
Tools differ on the first point more than their marketing suggests. A board that allows several assignees on a card cannot represent a single accountable owner, and teams that use one tend to rediscover the two owner problem the matrix was drawn to prevent. Where a tool keeps one owner per card and a comment thread beside it, the matrix stops being a separate document and becomes the shape of the board, which is worth checking against the feature list and against how other tools handle the same thing before committing to a format.
Write out the fifteen deliverables that matter most on the current work, and fill in only the Accountable column, allowing exactly one name per row and including people outside the team. Then check the rows against the four disputes above and settle any that are unclear while everybody is present. Moving those owners onto the cards themselves, as one assignee per deliverable in a board such as Pinateca, is what keeps the definition and the daily work from drifting apart.
Responsible, Accountable, Consulted, Informed. Responsible is who does the work, Accountable is the single person who owns and approves the result, Consulted is who must be asked before completion, and Informed is who is told afterwards. The four markings are applied to a grid of deliverables against roles.
A responsibility assignment matrix is the general form: any table mapping work to the roles involved. RACI is the most widely used set of markings placed inside one. Other sets exist, such as adding a Support marking or using Driver and Approver instead, and all of them are responsibility assignment matrices.
Whoever can change scope or dates without asking anyone else. If a slipped deadline needs the manager's approval, the manager is Accountable. If the project lead can move it and simply inform the manager, the lead is Accountable. Deciding this in advance avoids the common situation where both assume the other will act.
Yes, and on a small team this is the normal case. The two markings should be split only where the split changes something, such as rows involving money, contracts, customer commitments or changes that cannot be reversed. Splitting every row adds approval steps without adding oversight.
Consulted carries a two way obligation: input is sought before the work is finished, and the person owes an answer. Informed is one way and happens after the fact. The practical consequence is that each Consulted marking adds waiting time to a deliverable, which is why capping it at two or three per row keeps a matrix workable.
Recurring work usually benefits more than projects do. Invoicing, releases, incident response and security reviews repeat, so an unclear owner costs something every cycle, and the matrix needs updating far less often than a project one. A short operations matrix is often the highest value version to define first.