Dariusz Grabka

Writing for the Next Gen of Software Leaders

Accountability on Projects

Once projects get too large for a small team to execute, leaders need ways to formally identify who is involved, and their responsibilities.

Accountability matrices are simple systems used to identify communicate responsibilities on a project.

Two things all the accountability matrices have in common: they have memorable acronyms (that someone trademarks), and they have a point person who tries to wrangle people into that matrix.


That point person is often known as the “Accountable.”  A really common, basic matrix is RACI (or ARCI).  The acronym identifies the roles:

  • Accountable: single person who answers for the execution of the project.
  • Responsible: people engaged in the work of the project.
  • Consulted: people who weigh-in on the project, as SMEs. (Two-way communication)
  • Informed: people who want to know what’s going on. (One-way communication)

One person can perform many roles. For example, an Accountable is often Responsible as well.

RACI has many critics and detractors.  Most of the criticism reflects that organizations take the matrix too seriously.   I like the point that Grumpy PM makes: the best use of RACI is identifying the various dysfunctions in the organization :-)

Define Responsibilities

No matter what the role breakdown is, roles have to be assigned responsibilities.


  • A and R’s attend all project meetings.
  • R’s do most of the actual work.
  • C’s provide timely information, and attend meetings as invited.
  • I’s consume the communication.

If someone can’t be relied on to do any of the above, they are likely not involved in the project.

This let’s you identify if someone is a C (book meetings around them), or an I (don’t).  Changing people’s role on a project is straightforward: they get a new letter.

In Software Development Teams

Accountability matrices raise eyebrows and roll eyes due to their origins in consulting and Deloitte-like environments.  I still like them; the concepts are fairly lightweight and adaptable to help at a team level.

Things I find helpful about a matrix:

  • Calls out when someone will actually need to be engaged. ex. the Security person doesn’t need to be Consulted for a project kickoff, only once a specific feature gets planned.
  • Divides work without stepping on toes.  ex.  Product Manager or Engineering Manger can be Accountable for a project, in light of their shared ownership of a product.  But you only need one.
  • Fun to make up your own acronyms.

My observation is that matrices that break up R into other roles (Supporting, Tasked, etc.) tend to be too specific, and categorize people that can’t help the project directly, instead throwing in names as a CYA exercise.

Step one is usually to add a bit of RACI to the “epic” or “feature” or “project” templates in your work management software (Jira, Rally, or whatever). Your project manager will thank you.