8 Reasons to Use a RASCI Chart on Your Project

There are many tools that help to organize projects, processes, and own tasks, such as ToDo lists, Kanban boards, spreadsheets, task management systems, chats, emails and various communication tools. And they all can be pretty effective. However, oftentimes, when organizing work, we do not think beyond the “task assignee” concept as we associate a task only with a person who’ll fulfill it.

More than that, most common project management tools usually have one field for an assignee, which also gives the impression that there are no other roles apart from the person who does the task and, perhaps, a manager who can answer questions or provide details.

But the reality of modern projects is much more complex, and many more people are involved, usually implicitly. This is where a responsibility assignment matrix (RAM), like RACI or RASCI, comes in handy. Such a matrix takes into account all the roles involved and makes it clear what roles and people are involved and in which way. In this post, we talk about the most popular responsibility assignment chart, benefits a team can get when using it, a step-by-step instruction to create such a chart for your team, and some RASCI matrix examples from our experience.

What is a RASCI chart

RASCI chart is a popular management tool to categorize participants and define their roles and responsibilities within a project or process. The origin of the tool is clearly unknown. However, it is often associated with the project management approach called “Goal Directed Project Management” (GDPM) that got its fame in the 1980s after the publication of Kristoffer V. Grude, Tor Haug and Erling S. Andersen’s works. 

RASCI is a more modern version of the original RACI chart that was meant to define responsible, accountable, consulted, and informed stakeholders for each critical task on a project. The difference between RACI and RASCI charts is in the additional role (supportive) that the RASCI chart acquired over the time. Here’s what each role means in a RASCI chart:

• Responsible – is a person who drives the project and the team to achieve the intended goal. Holding that role, a person will be in charge of making an important decision, overcoming blockers, leading the team to do the right thing, and deciding what NOT to do. Responsibility can be shared but cannot be passed to another person. 
• Accountable or Approver. A person holding this role is answerable for the success and completion of the project while having the least involvement in implementation but the most in the decision-making process. The Approver will contribute ideas, knowledge and anything else that can help the Responsible and the team make the right decision and achieve the goal. In rare cases, an Approver can jump into the critical part of work. Check out our article on how to keep balance between authority, responsibility and accountability, to avoid most common mistakes in project management.
• Supportive. This role supports a Responsible in project implementation/delivery. People holding this role can be involved to varying degrees. Supportives may become a workforce buffer for the team to deliver projects on time.
• Consulted – are usually subject matter experts that want a Responsible to talk to them before the final decision is made. Consulted roles will contribute their opinions or knowledge as holders of context. They don’t do any work but may be involved in decision-making. 
• Informed. An Informed will want a Responsible to provide them with updates on the progress of the project. People who have been committed to being Informed will get passively updated on the critical project decisions and the key turns.

This model is very flexible, and based on the project size and nature some roles can be added or omitted. At Railsware, we use the RAtSCNIuo chart with some extra roles which we will discuss a bit later.

How a RASCI chart looks like

A classic RASCI chart consists of project tasks that are listed in the left column, while all the team members necessary to complete a project are mentioned in the upper line in the chart, and the roles that the team members hold are indicated as letters – A, R, S, C, and I.

As you can see from the chart, one participant can hold different roles on different tasks of one project. For instance, a CTO can approve some tasks, be consulted and informed on other tasks.

8 reasons why you need a RAM on your project

When creating a RACI or RASCI chart for your team, you get a powerful tool for efficient project management that contributes to smooth cooperation in cross-functional teams. Below are the things that a RASCI chart brings:

1. Simplified communication 

Without knowing who is responsible for what, a team will eventually face misunderstandings, mistakes, and sometimes even conflicts. It happens when new members join the team, when workers are engaged in several projects, or when one specialist passes their work to another one. With a RASCI chart, all team members have a single source of information they can address throughout the entire project. 

2. Fast decision-making

A responsibility assignment matrix clearly defines who is the Responsible and Approver of a task, which then makes it obvious whom to contact for implementation and decision-related questions.

We’ve tried and tested multiple decision-making frameworks over the years, and made sure to let you in on our thoughts. Check out the linked article where we put them in action with the same use case.

3. Better work coordination

When all the roles are clear, each team member knows what tasks they are responsible for, and whom to contact for which questions, they can start working straight away. Responsible people are aware of who they should consult, who will approve their task, what to do next, and what’s the goal and expected result of the project. They understand the workflow and don’t waste time searching for the necessary stakeholders.

4. Risk mitigation

The development of a RASCI chart requires you to decompose the project into smaller chunks of work and share responsibilities among team members. By doing so, you see the scope and what part each specialist is responsible for, which decreases your chances of missing something. It also shows whether you have enough resources/talent to complete the project.

5. Better workload distribution

The chart is also easy to analyze to see how many areas of responsibility each person has. It’s a simple way to determine if a team participant has too many responsibilities and, if so, prevent specialists from burning out or leaving some tasks incomplete by redistributing the workload.

6. Saved resources

RASCI chart allows for a more efficient workflow that reduces reworks, pauses, duplicated tasks, or, conversely, non-completed tasks.

7. Easier to manage changes

The Agile development methodology lets teams adjust project scope during the development. When using a RASCI chart, a team can easily track who will be affected by each change and how team members’ workload will vary.

8. Fast conflict resolution

A RASCI chart adds to the project management transparency. With this tool, you know the expected outcome from everyone, to which everyone committed. The chart allows a team to track back who was Responsible for a non-completed task and understand where blockers appeared. Such analysis is helpful in detecting bottlenecks and preventing them in the future.

Simple steps to create a RASCI chart 

If it’s the first time your team is creating a RASCI chart, follow the steps described in this paragraph and make it formal. Later on, you may not need to formally create it because everyone will know the process. Here are the steps to follow to create a responsibility assignment chart that your team can successfully apply:

• Define the project and its goals. Not all projects need a RASCI model to be created. If the project scope is small and can be successfully finished by one person, the chart development is a waste of time. For bigger projects RASCI chart will help to understand the workload and the team that you’ll need.
• Prioritize the project compared to other projects and tasks. When thinking about a new project, make sure its value is large enough to initiate the project. If you see that the project isn’t urgent and there are other more critical tasks in the queue, postpone it. 
• Decompose the project into smaller tasks. This step is only required if the project is big enough and includes several tasks that different team members should perform. Usually, project decomposition takes place during the product development roadmap creation. There’s no need to duplicate this step, simply take the tasks from your task management system and add them to the left column of your chart. If your roadmap is very high-level, you may want to decompose it further and use smaller tasks in the RASCI matrix.
• Define the specialists necessary to complete the project. Include all roles (e.g., project manager, designer, quality assurance engineer) that are required to successfully finish a project and list them in the upper line of the chart.
• Find people who can take each role. If you’ve got a small team with only one designer or business analyst, then it’s clear who needs to take each role. Yet, in a large company, with, let’s say, 15 designers, you need to find the right person who will fit the project. How to do that? At Railsware, we pay attention to specialists with the necessary expertise, skillset, and willingness to participate in a particular project. To simplify the team composition process, we offer our colleagues to check the list of all projects and specify their level of interest, using such commitments as “really want,” “want,” “ready to experiment,” “if really have to,” and “don’t want to participate.” The approach allows us to see if a chosen person will be motivated when performing an assigned task and also form a backup list of specialists who can replace a Responsible or other role if something happens. 
• Check the workload of each person to make sure they can participate. In our team, we don’t want specialists to participate in too many projects simultaneously as it decreases the productivity of a specialist and the project’s chances for successful completion. 
• Approve the matrix with the team. This step is especially crucial if it’s your first use of a responsibility assignment matrix. Run a short presentation of a created chart and allow your team to get familiar with it. The participants need to correlate their new responsibilities with their workload and volunteer in a project, re-balance already scheduled activities if needed, or refuse participation.

A chart itself is a handy tool. However, you shouldn’t ignore other project management tools and approaches that improve project coordination and team governance, like project management systems with assignees, dedicated communication channels with project participants, regular meetings with a team, automated business processes for budget approvals, etc.

Railsware experience with a RASCI chart

Our team has a long history of creating and using RASCI charts for both inner and external projects. Over the years, we have defined some additional roles that allowed us to distribute roles and responsibilities more accurately and achieve better outcomes. As a result, we have developed a RAtSCNIuo model. The RAtSCNIuo chart stands for responsible, approver, team, supportive, consulted, if no one else, informed, user, and occasional user. Let us explain what the new roles mean.

• Team. A specialist(s) holding this role on a project will work on a recurrent basis. Also, they will actively collect insights, do research useful for the vision or context, and collaborate with other team members or with the Responsible. The Team role has to stay on track with the project’s progress and push others to do things right. This role is usually occupied by the following positions: project manager, engineer, designer, HTML/CSS expert, copywriter, QA engineer, etc.
• If no one else. This role will identify people that are to be asked for help last of all, if no one else can assist. This would mean that the person holding this role has domain knowledge but wants to move away from the activity.
• User. Represents someone who uses the system or a project being developed and wants updates on usage-related topics.
• Occasional user. This is a rare user of the system or a project. Similar to a User, this role wants updates that are only relevant for an Occasional User. 

Not all projects require us to use all the listed roles and attract that many people, though. Each project is different. On some small projects, we may only have a Responsible and Approver.

When we create a responsibility assignment chart

It’s not mandatory to create the chart each time. Sometimes, the simpler approach works. It means you can define and confirm what role each person holds, and that’s it. No need to have the list of the tasks and the chart itself. Besides, you won’t always know the list of tasks in advance.

However, in case you think you’ll need a chart, you should start with the project’s priority. If a project appears to be less valuable than others in the queue, creating a chart for it is a waste of resources as the project needs to be postponed and, therefore, the chart is likely to be outdated by the time the project starts.

When we deal with an existing project, we create a RASCI (RAtSCNIuo in our case) chart if: the scope changes and we need to re-allocate the roles/scope; when the team composition changes and everyone needs to be reminded who’s doing what; when we see communication issues, people are lost and need this clarity.

In case of a brand new product development project, we create a responsibility assignment chart during or after the BRIDGeS discovery session. BRIDGeS is a flexible decision-making framework designed by Railsware that helps form a product vision and build a clear development strategy during one session. Find out more about BRIDGeS and the advantages a team can get using the framework.

RASCI chart examples

The Railsware team uses a RASCI model for every project that is large enough. Let’s take a look at some real-life examples from the experience of our team. 

Case 1. Organizing yearly summit

Every year, our team runs a yearly summit. This is an offline gathering that lasts a week where we get to know each other in person, build connections, collaborate, and have fun with our teammates and families.

Considering Railsware is a remote-friendly team with people from thirteen different countries, the organization of the yearly summit is a big and significant deal. The event organizer has to solve a number of problems and think through a lot of questions, like:

• Decide and agree on the destination of the event,
• Check the travel rules for a chosen destination,
• Define the number of participants,
• Organize the transfer for each teammate and their family members, 
• Find suitable accommodation for all participants,
• Create an agenda with various activities for any taste,
• Estimate and approve the budget,

and many, many other questions. The scope is obviously huge. This is why we used a responsibility assignment chart to distribute responsibilities and ensure everything would go smoothly. The questions we listed above formed a list of tasks which we placed in the left column in a RASCI chart.

Sergey, as a Managing Director, held the role of an Approver along with Agata, the Chief Financial Officer, who validated all financial questions. The Project Lead Anastasia, was the Responsible. She had to drive the project and was liable for its outcome.

The Responsible attracted a few colleagues (specialists in different areas with relevant experience and desire to participate in the project) to help her with the research, transfer organization, agenda, and other aspects crucial for the summit. They held the Team role. We contacted Railswarians who participated in organizing Yearly Summits in the past and who could help us with a piece of advice to be Consulted.

During the project, we set up several polls and discussions with all Railswarians to find out their opinion on one or another aspect related to the trip. Those who shared their ideas and suggestions also acted as Consulted. All Railswarians who decided to attend the summit became Users.

Additionally, we collaborated with an external travel agency responsible for buying tickets, booking accommodation and finding different services providers according to the event agenda. Those obtained the Supportive role.

Here’s how the final responsibility assignment chart looked for that particular project.

Case 2. Developing user management feature for Mailtrap

Mailtrap is a Railsware product aimed at safe email testing in dev and staging environments. The tool was initially created as an MVP for the needs of our team. When Mailtrap proved its viability, our team allowed other developers to use it as well. Now, the tool has more than half a million active users and is extremely popular among both individual developers and various agencies and companies.

Mailtrap is actively growing, and our team is regularly consulting our clients to find out what functionality they lack. The more corporate clients we got, the more often we were requested a user management feature. Before, users could share access to some parts of the system manually. That was enough for individual users or small teams of 2-3 people. At the same time, agencies have many more system users, so the manual user management process took a while.  

When we saw the real need for this feature and realized its value for our corporate clients, the team decided to give it a go. Before the project started, we created a RAtSCNIuo chart.

Sergey, our Managing Director, and Yevgen, a Mailtrap Product Manager, held the role of Approvers. Julia, who is also a Product Manager on Mailtrap, agreed to become a Responsible. To develop the feature, we attracted one backend and one frontend developer. We also required assistance from a content writer to work on UI texts. These specialists were the Team on the project. While all our designers in the company were busy with some urgent tasks, we contacted an external design agency to assist us with the UI/UX of the new feature. Last but not least, project participants were Mailtrap users who tested the feature and shared their feedback.

Here’s how the responsible assignment chart looked for this project.

Case 3. Upgrading error messages on the Plans & Pricing Page

This case is also connected with the Mailtrap product. Mailtrap offers its users a free subscription plan and several paid ones. Our data analyst constantly checks the conversion rate and detects aspects that have a negative impact on it. After one of the inspections, we found out that the error message free users saw when trying to use a paid feature was confusing and turned customers off.

Clients not only couldn’t understand what features they might use and which features were unavailable, but they also didn’t see the value a paid feature could bring and, thus, didn’t have an incentive to upgrade their subscription plan to a paid option.

To solve the issue and increase the conversion rate, our team initiated a corresponding project. The Approvers remained the same as on the previous project (Sergey and Yevgen) as well as the Responsible (Julia). We also required a content writer to create new, clear and appealing texts, a designer, front- and backend developers, and a data analyst for this project. All these specialists held the role of the Team.

Our team contacted a native speaker to check out texts and make sure they are straightforward and can’t be misinterpreted. This person held the role of a Consulted, as it was a one-time job. Also, we shared our findings with the team of marketing experts, as they might be interested in the project results. So, we added them to our responsibility assignment chart. Here’s how it looked.

All these charts helped us to launch, manage, and successfully finish each particular project. To create the charts, we followed the steps shared above and some best practices you also need to know about.

Do’s and Don’ts when creating a RASCI Matrix

• Don’t use names. Use the positions. Meaning, it’s better to write the position of a specialist required on a project (backend developer, designer, project manager) in the upper line in a chart instead of names because roles are static, but people can change.
• Assign one Accountable per task. Accountability can’t be delegated. There should be only one person to hold this role. Each task should have an Accountable person.
• Leave some cells empty. It’s okay when a chart has some blank spaces. The most important roles are Approver and Responsible, all others can be omitted. Don’t involve unnecessary people just because you don’t have a Consulted or Informed in your chart. It’s better to maintain the team small. Otherwise, you won’t be able to keep everyone focused. 
• Check your matrix when approving with the team. Make sure each person understands their responsibilities and that there is a commitment from them. Don’t just assume that they accept their role. It may happen that some people can’t participate, some aren’t interested in the project, or you may find a new person who fits the project better.
• Define a clear communication channel. Make sure that everyone on the team knows who has each role and how they are going to communicate with each other.
• Check periodically that the process is working and every role performs as it should. Simply planning the matrix doesn’t mean that the process will work on its own. Regularly get feedback from project participants and modify the chart if necessary.
• Get back to the matrix and update it when/if roles and tasks change. The projects can change as well as the team composition. To get all the benefits of a RASCI chart, it needs to contain only up-to-date information.

Wrapping up

A responsibility assignment chart is a relatively easy-to-use tool with a bunch of significant advantages. Developing a chart doesn’t take a lot of time, especially if you’ve done it before. When using a RASCI chart for your project and your team, the most important rule is to make sure that a person agrees with the role and responsibilities they were assigned. Also, it’s totally ok to modify the chart and tailor it to the needs of each particular project, as our team does. 

If you want to know more on how Railswarians compose teams, ensuring a high level of engagement and motivation, read our blog and subscribe to our Youtube channel!