RACI framework doesn’t give enough clarity on roles and responsibilities
The first time I did an organisational design project was for the Sales & Marketing function of an Automotive Company in South Africa in the nineties. As part of that prep, I studied our methodology and for the first time, came across the accountability framework for determining who is Accountable (A) for an activity or decision together with who needs to be Consulted (C) or Informed (I) and who is Responsible (R) -> The RACI framework.
A series of questions came to mind:
- What is the difference between being Accountable or Responsible?
- How important was it to really define who needed to be Consulted and Informed?
- What about other people who needed to be involved in actually doing the work?
- Making decisions is different to doing “stuff” – what about all those who have a veto on a decision or feel they do?
- The point of the A & R is there should only be 1 person/role. i.e. single points of Accountability. But, what if there are two decisions makers, i.e. two people have a veto
What I didn’t think of until much later, but after having done this numerous times since, is once this has been defined, how do you sustain it? How do you communicate it? How do you make it live? Too often we define things like a “RACI” as a one-off, people make a big fuss about whether they are consulted before a decision is made or Informed after it is made?
So, I did the project. We created a new organisation with clear processes and clarity on who was responsible for what? From this point onwards, for many years, whenever I did an org piece, the good old RACI or RASIC (the S stands for “Support”, i.e. who else needs to actually do something). But all those questions remained. I got tired at trying to explain the difference, in particular, between R & A. The “R” needs to make sure it happens; The “A” gets “shot” if it doesn’t; Yes, they are often the same person… Equally, having debates around who exactly needs to be informed or consulted is fairly painful. You really know you are on a losing wicket if you debate that one for hours. Shouldn’t the person responsible also be responsible for working that one out? Shouldn’t we just say that the R&A is the same person? If it is a decision, should we need to know who needs to approve it – i.e. who has a veto? From a workforce planning perspective, isn’t it important to know who needs to be involved?
Throw out the complexity – make it RAS
Therefore, at Concentra, we advise clients to throw-out:
- The difference between R&A -> just have R and define it as Responsible and Accountable
- The “I” and “C” -> Leave it to the person responsible to define who needs to be Informed and Consulted
- This just gives you the “R” – one acronym for defining the one person who is responsible. SIMPLE
But we equally, there are scenarios where it is useful to:
- Define who needs to approve a decision -> help clarify the governance
- Think through who else needs to provide time to getting the work or decision done
This leads to a “RAS” framework.
Equally, in OrgVue we enable you to define this link through a grid that feels very similar to that in Excel (download the OrgVue brochure here). More importantly, however, once defined everyone can see who is responsible for what within the org charts. As I often say, it is more important to define what is in the box rather than where the box sits.
Note: there are other frameworks other than RACI. The best one I know of is the RAPID framework, which was developed by Bain Consulting, see here. In Bain’s words:
“High-quality decision making and strong performance go hand in hand. Yet, in many companies, even clear, well framed decisions can be derailed by uncertainty over roles and responsibilities.
To address this common problem, Bain created RAPID®, a tool to clarify decision accountability. A loose acronym for Input, Recommend, Agree, Decide and Perform, RAPID® assigns owners to the five key roles in any decision.”
It is important to note, that whatever framework you select, OrgVue can configure its links between people and tasks to accommodate it. We don’t prescribe a solution, only we warn of adding too much complexity.
Latest posts by Rupert Morrison (see all)
- What’s the Difference Between Target Operating Model and Organisational Design? - October 20, 2017
- RACI, RASIC, or RAPID – throw-out the complexity - October 20, 2017
- Organisation Design vs Organisation Development - October 20, 2017