Too rigid and poorly suited to the new complexity of firms, RACI must evolve into a matrix of responsibilities.
At Alenia Consulting, we carry out many consulting missions focused on setting up operational models around Production. In these missions, it is mandatory to understand the problems we aim to address in the first place. The next step involves to understand the existing situation in which we could find different realities from one client to another, as well as across different areas within the same company. At the end, we seek to establish the target and the best way to get there. One of the main deliverable of these missions is the Target Operating Model.
In this document, almost all managers will expect to find RACI model, and conversely, the lack of RACI model will cast a veil of discredit over the entire approach. However, this same RACI will be a major turnoff for teams that primarily identify with the Agile manifesto, DevOps practices, and the concept of Craftsmanship. We will attempt to analyze why there are such opposing positions regarding a tool that has now been in existence for over 60 years.
First, let's clarify what RACI is not, is not anymore, never was or worse, what it claims to be, but where it produces the opposite effect. Here are the points that emerge from reading articles and ChatGPT:
If it’s not for the reasons mentioned above, why do managers systematically seek out and request a RACI?
It's the only known way of ensuring that all the tasks involved in a process, project or team have been considered, and that there are indeed identified stakeholders at each stage. This commonly occurs during the creation of a new process, a new project, or when there is a complete or partial teams reorganization. This is especially true in large organizations, where it is very challenging to understand all the complexity, so this document, which aims to capture it all, seems to be an ideal tool.
Alongside this managerial perspective, a question will remain: why these four letters quickly become an insult to those who advocate for Agile principles. In my opinion, there are three main reasons:
The first reason can be found in the Agile manifesto:
"Individuals and their interactions with each other rather than processes and tools.
Operational solutions rather than an exhaustive documentation.
Collaboration with customers rather than contract negotiation.
Responding to change, instead of sticking to a plan
While we recognize the value of the items on the right, we value the items on the left more."
The RACI is a document that describes fixed and planned processes, often found within a contractual document, even if it is implicit. This places the RACI within the elements on the right of the manifesto, which are considered less important, and in some extreme interpretations, should be completely eradicated.
The second reason is that Agile is often associated with the principles of small squads and feature teams, which are meant to be autonomous and focused on a specific goal and that writing a RACI is therefore useless or even dangerous, as it seems to impose on everyone what they must do and how they must do it, even before they actually do it!
The final reason is probably the trauma many have experienced from poorly thought-out and poorly written RACIs, which are often the visible manifestation of unwanted or undesirable changes.
First of all, anyone involved in managing human changes in large, complex organizations must always ensure that what they implement does not disrupt the existing system. It is mandatory that they have a tool to help them understand the main role of each one and check whether the target is coherent or not.
In addition, the authors of the manifesto make it clear that “the elements on the right have value”. There's never any question of avoiding processes, documents and a certain amount of planning when it brings value.
Finally, I don't know of any company that can claim to have only small, autonomous squads. The Spotify model is merely a theoretical model, which inspires and has inspired many, and rightly so, but let's remember that it has never been applied as rigidly as Spotify itself.
Consider that Spotify has a major incident during the squad's working hours, we won’t be able to wait until it’s back to normal the next morning, we will need to set-upon-call duty for the entire team at a high cost to a large organization. This also requires internal and external communication and the resolution of an incident that may involve a low-level infrastructure component. In this example, it seems complicated to involve fewer than three teams, and we are talking about an organization that is already very well optimized. The higher the level of complexity, the more useful it is to have a document to ensure overall consistency.
I would like to share how we can write a RACI that adds value in large organizations while ensuring not to take responsibility away from the teams as it would claim to capture all the actions they are allowed to undertake:
As a preamble, a RACI does not solve organizational or governance issues; it may, at best, make them visible. Therefore, the primary goal is to simplify processes and project governance. When it comes to teams, we define their goals and their reasons for being, rather than providing a list of what they must do. I highly recommend reading "Turn the Ship Around" by L. David Marquet in this regard.
For instance, at Alenia Consulting, the"Recruitment" domain has a mission: "Find new Alenias and ensure each candidate experiences an optimal recruitment journey." We do not specify how or who should conduct the recruitment since today’s solution is not tomorrow’s. The best solutions will be found by the people on the ground who are empowered, which means, first and foremost, being confronted with the consequences of their actions.
Let's move on to writing the RACI:
1- Few lines, each adding value
The creation of a new process, project, or even a reorganization always takes place within an existing framework of constraints. The key is to write steps of the process in a way that gives meaning for each one, avoiding excessive length or precision, since technology, tools, and processes have become increasingly powerful in IT. Otherwise, we risk producing a document that is outdated and/or unreadable.
2- Few columns, with clear team names
The first purpose of the document is to ensure that the changes you make don’t break down everything that already exists. It is important to specify the teams though there is always at least one partial reorganization each year and exceptions in roles and responsibilities. Therefore, finding the right level of detail in the organization is crucial. If the purpose for a team is not found, even a large one, it may be necessary to rethink that division.
3- Give up on letters
The most debatable point of RACI is, strangely, the letters it uses. The existence of dozens of variants with different letters is already a sign in itself.
Here’s what RACI presented above might look like with these considerations. You will notice that there are no more letters, and we prefer to call it a responsibility matrix.
Upon reviewing this matrix, we notice that there are many different stakeholders involved in the Incident Management process. At Alenia Consulting, we are sometimes called upon to improve this process, and the creation of a role, known as APS, enables us to manage incidents end-to-end with as much autonomy as possible for maximum responsiveness. Here’s what the new Incident Management matrix might look like when the APS role is created.
What can we conclude? Defending RACI but without the R, A, C, or I—isn’t that like defending cheeseburger without cheese? RACI in its theoretical form seems mainly suited to a static environment with intermediate organizational complexity. Today, companies are increasingly complex and operate in ever-changing international environments. Should we give up on it? I don’t think so; this growing complexity makes interaction modeling even more essential, as long as it does not to cover every action of every employee. That’s why at Alenia, we are moving towards responsibility matrices.
