You know RACI. Every project manager knows RACI. But how often does your team violate the single most critical rule of task assignment? While the definitions of Responsible, Accountable, Consulted, and Informed seem straightforward, the effectiveness of the model hinges entirely on a constraint many teams consciously ignore: the strict limitation on headcount for the two primary driver roles. If you want to rescue your projects from accountability gaps, you must confront the uncomfortable truth about who holds the final authority—the one person whose posterior will be kicked if the task fails.

While I believe the RACI itself is very well known, numerous times I've seen people using it in a strange ways. I think therefore bringing up what these letters means accompanied with some rules on how to use them might be helpful.
So, let's start from
four letters that specifies role of various people within a task or decision.
And the main rule that will help you be successful is to follow how many people can be attached to each of these categories within specific task or decision. You might have already noticed that in case of Responsible and Accountable I was writing only about Person, while for Consult and Inform I mentioned also in brackets People. And that was done in purpose - since Responsible and Accountable are actually a drivers of the task or decision (in many cases that might be one person, but not necessary and always), Consult are the people supporting and Inform are in most cases people dependent of the task or decision.
Therefore to avoid "split responsibility" and the situation of two people pointing fingers on each other in scope who should have done the task or who was accountable for the decision and consequences you have to avoid having more that one person within any of Responsible or Accountable categories. I know you might say, it is impossible, since the task needs to be done by more than one person (and therefore you need to have more people within Responsible) - but this means the task should be split into smaller pieces - and such split should be continued until you will be able to attach only one person within Responsible and Accountable roles.
In case of Consult and Inform - here you actually can have any number of people you want. These people as I mentioned before either supports or depends on the task or decision - therefore they are not the drivers. However please mind always a fact that the more people are mentioned in Consult - the more people needs to be contacted and actively provide their feedback on the task or decision. Also the more people you add to Inform - the more people needs to be reached after the task is completed (or decision made). Actually you might notice that the more people are mentioned as Inform - the more important task or decision is - hence the more other tasks/decisions are dependent on this particular one.
So generally even if Consult and Inform are sometimes treated as "less important" - they are not. Extending number of parties involved in task extends the time needed to complete it, while the more parties involved in decision making process - the harder to have a consensus. At the same time number of parties attached to Inform sets the importance of the task or decision.
I hope above guidelines will help you using RACI a bit more effectively and with more understanding than I've seen quite several times. I know that confronting the above with e.g. project documentation you have might feel I am going into too low level. I have also seen many documents where instead of people in RACI I've seen whole teams. The question however is how helpful such documents are ? Do they really help in solving who should be doing and who should monitor the tasks ? Or in whose area is specific decision ?
I know splitting the tasks into chunks small enough to assign them to single person is not an easy task. But believe me - this effort is paying off. And I strongly encourage you to do so - as for me, it helped me to rescue not one project in ma career
Strategic Technology, Delivery & Transformation Architect
Seasoned technology executive and transformation leader dedicated to bridging the gap between high-level business strategy and complex engineering execution. Specialized in stabilizing volatile IT environments, scaling agile delivery across international borders, and mentoring the next generation of technology leaders. Whether acting as a Fractional CTO or an Interim Program Director, establishes the operational discipline and strategic oversight needed to drive predictable, high-value outcomes in the most demanding industries.