In a large corporation, a small team of project adventurers found themselves lost in a maze of confusion. Each member, be it a developer, a designer, or a quality assurance talent — struggled to deliver their assigned tasks. Thanks to the lack of clear project direction, and the confusion around responsibilities, the project was becoming a graveyard of missed deadlines. That was until a wise project manager handed them a grid-style chart — a RACI chart, a compass that guided them through the treacherous terrain of project responsibilities and milestones. With the RACI chart, they were able to find their way out of the confusion, and a project that was enveloped in uncertainty, all of a sudden was illuminated with clarity.
What is so magical about the RACI charts? Can it be handy to your software development team as well? Read this article to find out by yourself.
What is a RACI chart?
RACI chart is a tabular or grid-style chart that defines the roles and responsibilities of a project’s stakeholders at an individual level. This improves the communication and collaboration among the stakeholders, increases the team’s productivity & efficiency, and helps complete the project in a timely manner.
A typical RACI chart, lists all the product backlog items (features), project processes, and activities on the extreme left side. The stakeholders are listed in the top cells of the columns. The cells underneath the stakeholder’s names represent the involvement levels (RACI) of stakeholders — Responsible, Accountable, Consulted, and Informed (RACI). It’s not a convention, but sometimes the Title, Role, or Position of an individual is used as the column label. This is especially when we know the roles of the people who would be working on the project but the team is yet not decided.
Here’s a deep dive into each of the stakeholder involvement levels—
Responsible — the execution hand
These are stakeholders who are actual doers i.e., people whose contribution to a project can be measured with tangible results.
In a software engineering project, a doer is someone who actually designs, develops, tests, integrates, fixes bugs, or deploys a software build.
Ideally, there should be only one responsible person to accomplish one task. This makes the person accountable for delivering quality results. If 2 or more people are assigned to complete the task, there can be a lack of clarity and ownership challenges, and this may result in low-quality outcomes. You might wonder, ‘What if the task is too large?’ Well, in that case, the project manager should strive to make the task granular enough to be assigned to an individual doer.
💡Pro-Tip: Always assign a single person as an owner of a task. If a task is too large, split it into sub-tasks with defined ownership.
Accountable — The managerial hand
People who are assigned the Accountable are the ones who discharge managerial responsibilities. They own the entire task end-to-end and are answerable to other stakeholders for the final outcome. At times, they play the role of facilitators who help the doers (Responsible) by ensuring that they have no bottlenecks deterring them from completing the assigned task. And sometimes, they dawn the hat of a decision-maker, who gives feedback on the quality of work or enables the team to take tough decisions. In fact, they enjoy the authority of accepting or rejecting the work but they also bear the brunt of things going wrong or credit for producing effective results.. In a software engineering project, a project manager, an engineering manager, or a tech lead is best suited for this.
In nutshell, the accountable empowers the responsible ones to sail through the software development lifecycle seamlessly, overcoming the challenges/bottlenecks and paving the way forward.
[Read more: 5 Challenges Every Engineering Manager Must Overcome]
Consulted — The guide
These are the experienced & skilled stakeholders who are assigned to the project to help Responsible & Accountable people smoothly navigate the bumpy road to task completion. The best people to wear this hat are the ones who have previously traveled the road and have worked on similar projects in the past. In IT projects, these can be senior developers who have worked on a similar task, or engineering managers who have achieved success with similar projects. In general, there can be multiple people who can be involved as consultants for a task. But for clarity & ownership, the minimal it is the better.
The Consulted can be considered as that extra pair of eyes to help you look at the edge cases, outlier scenarios and deal with the unanticipated hiccups during the project.
Informed — The extra brain
These people do not have any active vested interest in the task, but may later take up a task where the learning or activities from the present task can come in handy. For instance, let’s say, a large edTech organization is working on a project to develop Augmented Reality capabilities to help students learn effectively. And the board members need to make a decision about allocating the budget for this project. Now, if a person whose involvement with a previous AR project was under the ‘Informed’ category, his/her inputs can help properly estimate the budget and save the team from future surprises in the form of Budget leakage or overshoot. This is because, as he had no vested interest in the project earlier, his inputs would be probably less biased compared to the rest. Normally, executive-level people are best suited to play the role of Informed stakeholders.
Who should use the RACI chart and why?
RACI charts are particularly useful for large projects employing 100s of individuals and spanning multiple departments and cross-functional teams. These projects often span a considerable amount of time and involve complex tasks, where the responsibilities of each team member may change throughout the project lifecycle. In such situations, using a RACI chart can help clarify each team member's role and responsibilities at each stage of the project, reduce confusion, and ensure that each team member knows what is expected of them, even as their responsibilities may shift over time.
The benefits of using RACI charts are—
- It avoids unpleasant surprises, and project complications
- It avoids the confusion around the role, ownership, and accountability of stakeholders from becoming a project bottleneck.
- Facilitates better communication and effective collaboration among stakeholders.
- It avoids stakeholder burnout by evenly distributing the workload without overwhelming stakeholders with multiple responsibilities.
[Read more: 6 Must-Have Software Metrics for Engineering Managers]
RACI Chart Example
Let’s take the same example of AR feature development. But for brevity, we are limiting the tasks to just 5, and the stakeholders to just 7. In an actual AR project, the numbers would vary a lot.
