The RACI matrix is a responsibility assignment chart that maps all the tasks, milestones or key decisions involved in completing a project and assigns these tasks to the various team members.
RACI gets its name from the descriptions of each of the four types of roles assigned in a project
R – Responsible – the people who do the work;
A – Accountable – the person who is responsible for the success or failure of the project result;
C – Consulted – stakeholders who need to contribute before the work can be completed.
I – Informed – the people who need to be updated in the project;
- Everyday decisions
- Task oriented
- Focus on smaller projects
- Applicable to: Tasks and projects
The person performing the task/job.
They are the ones who ensure that everything runs smoothly and that everyone has what they need to progress. They schedule meetings, make sure things get done . They are also responsible for ensuring that the other people involved in the project are kept up to date.
Tip: Generally, there should be only one person responsible per project.
For example, in a software company, the technical writer may be responsible for creating the FAQ texts. A developer would not create the documents, but could embed them in the product, which would be a different task.
The person responsible for the correct conclusion.
They NOT need to know if the project is on the right track, after all, it is their head that will roll if the whole thing goes to one side. Their responsibility is another: they wield ultimate veto power, remove barriers, provide feedback when asked.
Tip: Again, there is usually only one person responsible per initiative.
In the previous example of one of the writer and the developer creating the FAQs, a **[product manager](https://vidadeproduto.com.br/gerente-de-produto/)** may be responsible for verifying that the files are in the product.
The people who provide information for the project and with whom there is two-way communication.
They are the specialists (here, there may be more than one). They are consulted for decisions that fall within their area of expertise. Their input on the larger project/initiative, for the most part, is optional.
For example, a Scrum Master can be consulted because he is an expert on the subject. Consultants should be considered carefully, as too many people in this role can prolong task time and increase the risk of poor performance.
People who need to be informed about progress and with whom there is one-way communication
In the “Informed” function are those people who need to be kept in the loop. Graphing this function helps to illustrate dependencies and also ensures task status transparency. Identifying those that require status updates can be complex; therefore, it's worth taking the time to query various functions to determine if they need to know when a task is complete.
For example, the sales manager may require status updates on a specific feature that is highly requested by customers.
First I created a table listing the positions at the top and then the names of the people in each position. This highlights the first thing to decide when creating a RACI: do you list specific roles or people? Traditionally, you have defined functional roles at the top. But there are advantages and disadvantages to both approaches:
Reasons to specify by role:
- If a single person is fulfilling several functions;
- Avoids the need to update the matrix if there is a change in personnel;
- Avoid having a mix of names and broader groups, e.g. 'customer' or 'department X'
Reasons to specify by name:
- It is simpler to define who is involved in the project;
- If several people are fulfilling similar functions;
Roles are used most often as a single person occupies multiple roles. However, if there are multiple people filling a role and the tasks don't overlap very much, it might be better to use names.