Blog
A post by Jem Jelly on LinkedIn regarding the role that RACI (aka the Responsibility Assignment Matrix) plays in teams engaged in knowledge work brought many proponents and practitioners of classical project management into the comment section doing two things:
- challenging the definition and interpretation of RACI used (leading to the classic “No True Scotsman” argument we see again and again in the world of Agile), and
- defending the use of RACI highlighted in Jem’s post as one that creates what the framework promises: clear roles and responsibilities.
Let’s focus on (2), since discussions of (1) reliably lead to debates around semantics and interpretation that are best left to theologians. In particular, and since Jem is talking about RACI in knowledge-work teams, let’s review and consider:
- Where have I seen a RACI matrix before?
- Is the RACI matrix useful in projects of a highly collaborative, non-transactional nature?
- When is RACI considered useful for creating clarity in project roles and responsibilities?
- What are the potential drawbacks and side-effects of RACI matrices?
- What could development teams do instead?
A checklist item eliciting a “meh” reaction
I’ve only used RACI a couple of times in projects; the first time, I was asked to create such a RACI matrix as part of a good practice in “how one does projects” for a project distilling the corporate strategy to a portfolio of projects that would put the strategy into practice across the global organization.
The matrix was created, was placed in a gate deliverable, and a box was ticked to indicate that yes, indeed, the project does have a RACI matrix before it proceeds. There were no vendors, but there was a double-digit number of stakeholders across organizational boundaries within the company, and across different functions. The most important part of the RACI matrix was not the content of the matrix (i.e. the R/A/C/I assignments) but the listing of stakeholders themselves, which were anyway known beforehand.
The R/A/C/I assignments themselves? Too many of them, delineating a very complex policy of expectations from each party. Still, it had been semi-mandatory to have such a deliverable available (i.e., a project sponsor requested it), and it hadn’t taken that long. It was also never again used for anything, and I often disregarded the alleged “guidance” of the RACI matrix as situations between stakeholders shifted. The project was a success, regardless.
A project manager’s stress-management tool?
The second time I had to deal with a RACI matrix was with one that I found in the documentation of a project I inherited. The project had been meticulously documented in countless Excel sheets and PowerPoint presentations over the years it had been ongoing, despite facing dismal traction among its internal “target customers”.
The RACI was gloriously documented; every single stakeholder and vendor was identified, and different versions of the spreadsheet showed how the stakeholder and vendor landscape had evolved over the years. Occasionally, new stakeholders had joined and others had changed or dropped out; the project manager had adjusted the R/A/C/I assignments. Hundreds of cells with these four letters caused an immediate sensory overload to anyone who gazed upon the matrix upon opening the spreadsheet file.
Had that exercise been helpful for the original Project Manager? I cannot know. Judging from the end result that I inherited, i.e. a stagnant endeavor that eventually needed to be “rebooted” with entirely new ways of getting it done , the RACI matrix could have been more helpful for the Project Manager himself than for the project overall. Perhaps it was a way of managing his own anxiety about the complexity of the endeavor that arose from the numerous human interactions. Thus, to some extent it was helpful; yet, its existence as a documentation artifact or even the thinking that went into it was probably not justified in retrospect. Obviously, the project’s state cannot be blamed on the matrix itself, but it can be attributed to everything that went into the project, including the obvious preoccupation with artifacts like the RACI matrix.
In both of those cases, the thought process behind creating the matrix was not entirely unwarranted or a waste; it is generally a good idea to map the roles that different project stakeholders (can) play in a project. This is doubly true when some are vendors external to the project, especially when there are SLA agreements and other contractual obligations in place. That is to say: it’s a good idea to do the homework of thinking about what would go into a RACI matrix. It’s a possibly useful practice, depending on the relationship (or lack thereof) between the supplier and the organization executing the project.
Is RACI useful? Maybe.
In the best of cases, a RACI matrix is not only useful, but a must-have in delineating transactional relationships between project members / stakeholders / suppliers. It creates clarity for everyone, especially when the respective people / organizations have not had prior contact and thus expectations of behavior cannot be set a priori; in other words, it creates clarity in situations of low trust or those with strong transactional character. Think of it as the definition of a “human API”; here are the interfaces of the project, and here’s what every interface is supposed to do: recommend / be responsible, approve / be accountable, be consulted, be informed. It could, for all intents and purposes, be the addendum to a contract.
In the worst of cases, and especially when it has been defined in collaboration with those on it, the RACI matrix is a truly fantastic instrument for empowering a blame culture within the project and across its boundaries. The best way to achieve this worst of cases is to use RACI between the departments internal to your own organization. Supposedly, when within the same organization, you benefit from lower transactional effort, yet there are plenty of proponents of putting everything and everyone into one of many little boxes of a framework like RACI.
In such cases it’s an obsession with the illusion of control that often is related to an organizational culture of blame, or a previous “traumatic” experience of the organization that leads to such extreme internal formalities. The organization overcorrects for past errors of omission or management by mandating the effortful definition and management of a RACI matrix as the miracle cure of misalignment and lack of collaboration among project members and stakeholders.
In effect, this turns the RACI matrix from an informational, potentially useful and insightful exercise into a blunt instrument of “alignment”. In other words, the RACI matrix becomes the contract that determines interactions between team members who are supposed to be competent multi-skilled individuals who can Recommend, Approve, be Consulted and be Informed dynamically and depending on the needs of the endeavor, regardless of what the holy RACI matrix prescribes.
Teams engaged in knowledge work therefore do not really benefit from a RACI matrix, as it can becomes an impediment and, most grievously, an excuse for playing the blame game. And, if the RACI matrix is followed religiously, it empowers malicious actors within a team (these do exist everywhere but in the utopia of the PMBOK) to play political games.
Every one of the 4 roles in the RACI matrix can be twisted to become a political instrument that creates impediments to the team’s progress. The recommender might blame those consulted for the information they (failed to) provide. The approver might block for capricious political reasons. Those being consulted might be at odds with each other, leading to confusion as each promotes his own agenda. And those being informed can gripe about not being informed about minutiae with zero impact on the endeavor. None of those behaviors, though entirely feasible within the political realm of human behavior, benefit the project.
A better alternative for development teams
My advice for teams engaged in knowledge work: instead of wasting time on a blame-game-empowering RACI matrix, make a skills-and-knowledge matrix instead. List every project team member and stakeholder across columns. In the 0-th column, list all the skills and knowledge domains that your development endeavor relies on or could benefit from. Then, for each skill / knowledge domain work across the columns and mark those who the team holds as a trustworthy subject-matter authority; by “trustworthy” I mean “not likely to promote their own agenda and expert ego to the detriment of the endeavor”.
Now, instead of pretending to manage the ever-evolving landscape of stakeholders with an administrative tool that brings little value, you have a map of whom to turn to, in order to move the ball forward. Provide the guidance that everyone who holds knowledge or skills that can help the endeavor uncover and fill knowledge gaps is expected to provide it. Guide the team to a) be open for this and b) express gratitude and appreciation to everyone who does so.
Don’t let the screwdriver operate the mechanic
The project is merely a means to an end (a desirable, viable product), and project management needs to take a back seat to the creation of value through the actual development endeavor. As such, resist the urge to neatly fill boxes and templates that look good on paper but bring little to negative value; one of those templates is the RACI matrix.
In the worst of cases, the RACI matrix is the same kind of transactional pretend-control artifact as Bain’s RAPID framework. If your organization is engaged in development endeavors and you perceive that it “needs” that kind of transactional, friction-causing formality between its internal stakeholders, you need to address the underlying pathological conditions (culture and incentives), not slap a fancy framework on top of interactions.
The RACI matrix is a potentially useful instrument; however, when the environment in which it’s used promotes or imposes (or suffers from) a transactional mindset despite the dire need of collaborative spirit and multi-skilling across team members, any such tool gives people under pressure (even those without malicious intent) a formal excuse to point the finger, i.e. it can promote a blame culture. Clear roles and responsibilities are also useful, no doubt; yet, too much emphasis on such delineation builds walls around those in the RACI boxes and stifles collaborative spirit within an endeavor, thus lowering the likelihood of a successful outcome.
This means, once again, that it’s not the tool that’s the problem but rather its nilly-willy application like a methodological plaster on an organizational gunshot wound . And yet, it’s the failure modes of those ideas that damage endeavors, not their absence from project documentation or rituals.
