The next most important task after defining the process steps is allocating them to the people in the organization in order to ensure their execution. Several process roles are needed to support each process step. This information can be presented in a nice and structured way by using a RACI Matrix.
Let’s start with what stands behind the RACI abbreviation. Simply put, RACI comes from the first letters of the process roles assigned to each step, as defined below:
|Responsible:||the one doing the task|
|Accountable:||the one who ensures the task gets done|
|Consulted:||the one who receives the information and provides feedback (bi-directional information flow)|
|Informed:||the one who only receives the information (one-directional information flow)|
NOTE 1: We are strictly talking about process roles, not people. This means one person can be assigned multiple process roles, just like one process role can be performed by multiple people (see more below in the Rules for Creating a RACI Matrix).
NOTE 2: In this article, I will be discussing only the RACI model. However, there are many other similar models, some of which include even more (or different) process roles (see more on Wikipedia). Nevertheless, the logic in what all of these models represent, how to fill them out, and how to use them is essentially the same.
How to Create a RACI Matrix
The RACI Matrix looks like this:
|Role A||Role B||Role C||Role D||Role E||Role F|
The rows represent the process steps and the columns represent the process roles allocated to those steps. Their cross-section shows what the process role’s exact involvement is regarding a given process step: whether that role is Responsible, Accountable, Consulted, or Informed.
In your model, you can substitute Step 1, 2, 3, etc. with the actual names of your process steps and make as many rows as you need (one for each step). You can also substitute Role A, B, C, etc. with your defined process roles and make as many columns as you need (one for each role).
NOTE 3: When you start filling out the RACI Matrix, you will most probably be tempted to list the job titles of people, instead of their process role(s), esp. if you have not thought of any specific roles that you need for your process. This might turn out to be a double-edged sword: On one hand, it is a great idea to link process roles to job descriptions (see more below in NOTE 5). On the other hand, however, having a process role, as opposed to a job title, gives you the flexibility of NOT being attached to the organizational structure. This essentially means that when the organization restructures (which I am sure it will at some point, esp. if you are in the IT business), your already defined RACI Matrix might still be very relevant to the new ways of working. Moreover, there are process roles that do not exist as job titles in an organization: e.g. Author, Reviewer or Approver of documentation, acting as a Project Manager for internal projects, being a Stakeholder or a Subject-Matter-Expert, i.e. a process role which in reality encompasses a lot of job titles in itself (or even other process roles), etc.
Rules for Creating a RACI Matrix
Filling out the RACI Matrix does not look very complicated, however, some serious thought has to be put in place as to what the implications of it are in reality. Here are the rules that guide me:
1. There should be no duplication of roles per process step.
This, in other words, means the following:
1.1. Accountable and Responsible cannot be the same role.
Someone else should be supervising the Responsible, guiding them, and helping them to remove obstacles when needed. If I am the Responsible, for example, I should not be the one supervising my own work, just like I should not be the one reviewing or approving the documents, SW code, etc. that I have created. We need another point of view on the matter (usually, higher up the hierarchy) and another pair of hands to minimize the risks.
Here is another example: Imagine that you are running a complex program with tight deadlines (i.e. you are the Responsible). There are too many things to do and not enough time. Even with your best intentions, you cannot do (or remember to do) everything. Who should then tell you what the company priorities are? Who should make sure you do certain tasks at the expense of others? Who should keep you honest and grounded, when you start approaching deadlines or even missing out on your deliverables? Who should lobby and vouch for you and your program in front of others in the company, esp. the higher Management? If the answer to these questions is again you, then a) you are adding even more tasks to your already overloaded plate, and b) strictly psychologically speaking, you will act a lot more responsibly if you have committed on those project deliverables to someone else, rather than if you have committed only to yourself. All of this is to say: If you are the Responsible and at the same time the Accountable one, the risk of you not delivering an even bigger portion of what you have promised to deliver becomes higher. Hence, it is always best to keep the Responsible and the Accountable roles separate.
NOTE 4: If you are experiencing troubles identifying the Accountable when filling out the RACI Matrix, see Rule #2 below.
1.2. Whoever is listed as Consulted does not have to be listed as Informed too.
As per the definition, Consulted requires a bi-directional information flow (from the Responsible to a third party and back) and Informed requires only a one-directional flow (from the Responsible to the third party). Meaning, if someone is being Consulted, they certainly have already been Informed.
1.3. If someone is already Accountable or Responsible, the bi-directional information flow is assumed.
In the case of the Responsible, I believe this goes without saying – whoever is doing the job does not need to consult or inform themselves of anything.
For the Accountable, though, why would I not list them as Consulted or Informed? Because the Accountable absolutely has to be informed, otherwise, they cannot be held accountable for things they do not even know. And if we want them to be truly accountable, then they also have the authority to say whether things should be performed as planned by the Responsible. Therefore, the Accountable is, in essence, being in an active and constant Consulted position and I do not see a reason to point it out specifically.
2. There should be exactly 1 Accountable per process step.
This aims to ensure the process step indeed gets done. Otherwise, if we have 0 or more than 1 Accountable people, the risk of things falling in between the cracks grows exponentially. How to address this issue?
2.1. No Accountable:
If you cannot identify the Accountable person for a given process step, then point out as Accountable the direct Manager of the person, who is listed as Responsible (as per the organizational structure).
2.2. More than 1 Accountable:
In this case, you probably have not cut out the process correctly – see Know Your Limits for the solution.
Some colleagues argue that there also should be exactly 1 Responsible per process step for those same reasons – to ensure that the task gets done. However, I do not think this is very realistic: Quite often we have many people performing the same activity in their specific domain and one person overseeing the whole effort. Therefore, I would prefer to focus on having exactly 1 Accountable and list as many Responsibles as needed per any given process step.
3. Accountable and Responsible are mandatory for each process step; Consulted and Informed are not.
In other words, we can very well have steps in the process, for which we do not consult with or inform anyone. However, we cannot have a process step without at least 1 Responsible and exactly 1 Accountable.
TIP: In the RACI Matrix example above, I have marked with a dash the places where no one is Consulted or Informed. Typically, this is a blank space. However, I do not like leaving it blank because it might look like I have not completed the RACI Matrix, especially when the process is still in a draft version and I am sending it out for review.
How to Read a RACI Matrix
A RACI Matrix is first and foremost a matrix. We need this table view so we can read the presented information bi-directionally. Here are a few examples to explain why:
If I am assigned Process Role A, I will be able to immediately see which process steps are attributed to my role and in what way: which steps I have to perform, which I have to ensure, for which I need to provide feedback, and for which I will only receive the information.
NOTE 5: It is always a good idea to make a list of all those process steps assigned to you (to your process roles) from all of the respective processes. In the best-case scenario, the summary of those steps will essentially be your job description and/or your personal objectives (see more in Personal Objectives). But even if that is not the case, knowing all that is assigned and expected of you can help you better plan, prioritize, commit or reject, negotiate for deadlines, ask for additional resources, etc.
If I am executing e.g. Step 1 (i.e. I am the Responsible for it), I can see who else I need to involve in this step and in what way.
If I am an Auditor and I want to audit Step 1, I can immediately see who is supposed to perform it, who is ensuring it happens, who has to provide feedback, and who has to receive information that the step has been performed – and check if all of these activities really happened.
If I am a stakeholder in this process (i.e. I have another process I execute, but I have to receive some information from this process), I can bring up the topic that my process role has to be listed as e.g. Informed inside the RACI Matrix, so that my dependant process gets what is needed in order to operate in its optimal way (i.e. whoever is executing the step will see they have to inform me too when the step is done).
How to Implement a RACI Matrix
Defining Process Roles
As already mentioned above (see more in NOTE 3), keeping separate process roles from the organizational job descriptions might be a good idea. And like the job descriptions, the process roles have to be defined too. In order to make a complete definition of a process role, the following attributes have to be explained for each role:
|Responsibility:||the task that needs to get done|
|Accountability:||the ownership of (someone else's) Responsibility|
|Authority:||the rights (access to tools, financials, networking, etc.) needed to fulfill the assigned Responsibilities and Accountabilities|
|Competency:||the skills (knowledge, experience, etc.) needed to fulfill the assigned Responsibilities, Accountabilities, and Authorities|
Assigning Process Roles
Once the process roles are defined, they have to be assigned to the people who will execute them. To do that, we have to match the actual skills of the people to the required Competencies for each process role. In the best-case scenario, we are always aware of what skills we have in our team. We can use this information to assign the process roles to the most suitable people.
As you might have guessed already, the Competencies are not static – they are constantly changing and, therefore, they have to be tracked and updated. People can acquire new skills or lose existing skills. Just as like, the process role’s Responsibilities and Accountabilities might change (due to a change in the process – see more in Process Purpose) and, thus, require a different set of Authorities and Competencies. That is why we have to constantly monitor for gaps between the actual and the required Competencies and work to close those gaps.
Another important thing to mention (and monitor) is the process role’s Authorities. It is somehow assumed that once someone is assigned to do or to own a certain task (Responsibility or Accountability), they are also automatically granted all needed to achieve it (Authority). In reality, however, we very often have contradictions like: a person in Sales has to negotiate an optimal price, but they are not given the Authority to make a discount off the market price; a person in IT has to extract a report concerning the employees’ salaries from the HR database, but they are not given the Authority to view everybody else’s salary; a person in Quality has to ensure the customer requirements are met, but they are not given the Authority to read the contract signed with the customer; and many more. Therefore, when defining the process roles, we have to carefully think what is needed (Authority) in other to achieve what we want (Responsibility or Accountability), and when assigning a process role, we have to again carefully think if we can grant those Authorities to the person (or to the job description, if you prefer) we are planning to assign the process role to.
Delegating Process Roles
The assignment of process roles is also not static, but it keeps changing. People delegate and that is a good practice to ensure more gets done. However, delegating should also follow a few strict rules in order to work optimally.
A process role’s Responsibility is the main thing that gets delegated. To ensure the new Responsibility can be immediately picked up and carried out by the delegate:
- the Authorities that go with this Responsibility have to be delegated too, and
- the delegate has to possess the needed Competencies for the delegated Responsibilities and Authorities (if they do not, plan for them to acquire the needed Competencies ASAP).
See more above in Assigning Process Roles.
Accountability is very often tied to the organizational structure – a person is assigned Accountabilities within the scope of their job description, i.e. as per the organizational structure. This serves a double purpose: On one hand, it ensures that the person has formally the mandate to establish an environment, which will foster the fulfillment of the respective Responsibilities. Without such a mandate, an Accountable person cannot truly be accountable for anything because their hands will be tied. On the other hand, though, it means that Accountability cannot be delegated – we can delegate a task (Responsibility), but we cannot delegate the ownership of a task (Accountability).
There are multiple examples of Accountability display in practice: one of them is having a sports team of any type – the Accountable person is always the coach. No matter how each team member performs on a given day, what obstacles there are, and who is or is not doing their Responsibilities properly, at the end of the day the coach is the ultimate Accountable for the overall team performance. The coach cannot make someone else Accountable even if they want to, because that someone else is not the coach as per the formal organizational structure and, therefore, will not be recognized as the Accountable one by anyone else.