Forget RACI Analysis, RATSI makes it clearer!

In this post we explore the use of RATSI as an alternative to RACI. If you’d like to learn about Visual RACI modelling read our post: Bringing RACI into the 21st Century.

Describing roles, and their responsibilities, (R&R) is one of the core benefits of process mapping. The most common approach is RACI analysis. Here I would like to present a better alternative for you.

An activity described in Skore app

Why do we need an approach for identifying responsibilities?

Because we want to know who will be involved in a piece of work and what is expected from them. This is all about role clarity and setting the right expectations for every member of the team.

Charting the roles, and their responsibilities, allows a process to remain high level while still capturing all the actors involved.

RACI analysis and alternative solutions

RACI is the most popular notation for R&R analysis but practically it falls short of being as clear as we want it to be.

RACI stands for Responsible, Accountable, Consulted and Informed. The problem is that in reality everyone has their own definition and understanding of what each of these terms means.

If you’ve used RACI, how many times have you argued with colleagues over the difference between Responsible and Accountable?

Introducing RATSI

RATSI stands for:

  • Authority – “owns” the activity or the decision to be made. Clearly not involved in the day to day work.
  • Responsible – for ensuring the activity is done (not necessarily doing the work but ensuring it is completed to an agreed standard).
  • Task – actually does the work as described.
  • Support – provides inputs in exceptional situations / edge cases (otherwise it would be Task).
  • Informed – is informed the activity will happen / has been done (successfully or not!).

These are cumulative: someone could have Authority / Responsibility / Task on a given activity.

Personally I do not use the S and I very often to keep my process flow readable.

Arguments for RATSI over RACI analysis

1. There is often no simple translation of  “Accountability”

In many languages “Accountability” translates literally to “Responsibility” … and now you see what I mean. You will need at least a few words to explain the difference between the two concepts. And be prepared to explain it every single day.

RATSI does not use this concept of “Accountability” at all.

We use instead :

  • Authority over the work (but is not involved) and decision maker
  • Responsibility  for ensuring that the work is done.

2. No consistent interpretation of Accountability and Responsibility

But even in an native-english speaking environment, Accountability and Responsibility have various interpretations. Even within a single business! I have seen a number of teams giving up on either the A or R to avoid the confusion.

RATSI focus on Responsibility — that the job is done

3. Accountable of what?

That the activity is done or the activity is being done?  Should someone “Accountable” organise the team so that the work could be done, or actually assign a given piece of work to a specific person?

With RATSI

  • Authority : decision maker, owns the way the activity is done. Not involved in daily operations
  • Responsible: ensures the job is done at the end of the day

4. Responsible for what?

That the activity is done (by myself) or being done by someone?

RATSI makes a clear distinction between both roles

  • Responsible: that the work is done
  • Task: does the job

As RATSI is cumulative I can assign someone both R and T.

 


Now, some practical tips

Can I have multiple Accountable or Responsible for a given task?

Rule of thumb : You should aim for one unique Accountable / Responsible per task.

But… so long as they don’t contradict each other you may have several on one activity. See this example:

Personal Care and Home Care being 2 different businesses, it’s obvious they don’t approve the same campaign briefs. There is no conflict in the roles & responsibility, and for someone reading the process it’s hard to be confused.

(Until the day they come up with an air freshener that washes your hair.)

When do I use Support vs. Task

Rule of thumb: if the person is involved in every occurrence of the process, they have a Task.

Why? RATSI is a great proxy to go from process mapping to role description. Writing a role description, you will likely ignore all the Support jobs to make it easier to read. If you add too many S you can start to question what the role is really about.

Personally: having any doubt about whether it’s Support or Task is often a good enough reason to “upgrade” to a Task.

How many roles in total?

Finding the balance between a comprehensive list of roles and a process that is easy to read is challenging. It comes down to your personal preference.

A long list of roles is often down to identifying variations of a given role.

  • Tip for keeping your list of roles short: Focus on describing the process clearly

Prioritise the Responsible.

Write a “generic” role for the Task

In Skore, you can write the complete list in a Sticky Note or attachment if you want to capture it separately from the activity.

  • Tip for managing a comprehensive list of roles: Focus on the detailed involvement of people

Don’t forget not offend anyone! Use the reporting tool frequently to ensure you have not missed anyone.

3 things to remember

  • Role clarity is at the core of your process mapping exercise, whether it’s RATSI, RACI or your own variation, it’s important to understand who does what
  • Limit the number of roles against an activity to keep the process readable
  • Limit the number of Authority and Responsible to 1 where possible

If you’d like to learn about Visual RACI modelling read our post: Bringing RACI into the 21st Century.

 

4 thoughts on “Forget RACI Analysis, RATSI makes it clearer!

  1. I enjoy your perspective, coming from process mapping and then leading into role definition! It’s unusual to me and makes me think.

    In my work environment, things usually start from roles and accountabilities (and unclear processes :)), and _then_ move to process mapping / definition.

    I will look deeper into how these two perspectives connect: As we develop more standard processes at Structure & Process, I believe we will have a perfect application for Skore and the RATSI-plugin, and we might gain some insight into how the kind of process / R&R description you describe in this post can go together with our Holacracy-Based Governance. (https://glassfrog.holacracy.org/organizations/161) And then there are plenty of application possibilities in client work and with collaboration partners too. Thank you for posting!

    1. Hi Martin,

      Colin introduced me to this idea just over a year ago. I too found it unusual as I had always been involved in projects that started with the roles and responsibilities and built out the processes from there. In 2014 I was involved in a transformation project that used the approach described in the article and it was impressive.

      I think we often get caught up in trying to force fit process to the roles that already exist. We don’t stop to think about whether these are the correct roles in the right places. By defining the work required to deliver the outcomes first you are designing the roles. Once you have this in place it’s very easy to create accurate job descriptions.

      If you already have roles in place, i.e. a transformation to an existing org, then there is some inevitable negotiation that needs to take place. But generally people seem to be happier as their new job descriptions are more accurate and achievable.

      That’s been my experience so far!

Leave a Reply