Forget RACI Analysis, RATSI makes it clearer!

this post was updated on 28/10/19

In this post we explore the use of RATSI analysis 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 to this is normally RACI analysis. However at Skore we have a better and clearer alternative – RATSI. Read on if you’d like to find out more about how RATSI differs to RACI.

An activity described in Skore

Why do we need an ‘approach’ for identifying responsibilities?

You will always need 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 roles and responsibilities, allows a process to remain high level while still capturing all the elements involved.

RACI analysis and alternative solutions

RACI is the most popular notation for R&R analysis but it falls short of being as clear as it can 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 had experience of using 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!).

Its important to remember that these are cumulative: someone could have Authority / Responsibility / Task on a given activity.

Arguments for RATSI over RACI analysis

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

In many languages “Accountability” translates literally to “Responsibility”. In the world of global business this lack of clarity can lead to mistakes or confusion. In comparison RATSI does not use this concept of “Accountability” at all.

Instead it uses :

  • 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

Even in an native-English speaking environment, Accountability and Responsibility have various interpretations. RATSI focuses on Responsibility — that the job is done – enabling clear ownership.

3. Accountable for what?

RACI does not allow detail -leading to uncertainty whether the activity is done or 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?

With RACI are you certain if the activity is done (by yourself) or by someone else?

RATSI makes a clear distinction between both roles

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

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

Did you know? With Skore you can apply RACI, RATSI or any responsibility matrix you wish to your process maps. Find out more here

Now, some practical tips

Can I have multiple Accountables or Responsibles for a given task?

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 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.

When do I use Support vs. Task

If the person is involved in every occurrence of the process, they have a Task. Having any doubt about whether it’s Support or Task is often a good enough reason to “upgrade” it 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.

Tips 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 an attachment if you want to capture it separately from the activity.

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 one where possible

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

If you’d like to try out Skore and learn how to incorporate responsibility matrices into your process maps in an effective, easy and eye catching way then why not have a free trial:

LinkedIn
Facebook
Facebook
Twitter
Visit Us
YOUTUBE
Instagram

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