RACI charts are a sign of a dysfunctional organization


#1

So, in an (granted, self-perceived) futile effort of reviewing/updating a RACI spreadsheet that involved effort by both development and infrastructure groups, it dawned on me yet again after the discussion on it that a RACI chart is another organizational dysfunctional cover up to a silo’d / turf environment where no one wants to admit something is wrong with the structure (the elephant in the room); that or be accountable for work. A RACI chart no matter how you look at or how perfect it is, leads to a potential missing item that results in work not being done. But do to different groups of all whom don’t have same priorities results in “not my job” finger pointing exercise. In an environment where the teams have the same vision (i.e. on the same organizational journey) this would not be an issue as they identify the missing task and work as a team to determine who should work on it. (in fact, teams would self-identify / self-take the work to be done).

Am I wrong in these fragmented thoughts? (or has it been just one of those messed up weeks?)

Note: not sure where this should have been categorized under so if there is better spot I apologize


#2

Seems like a good place for it. For other members who were wondering (as I was), RACI stands for responsible, accountable, consulted and informed.

I’ve certainly seen responsibility matrixes (I didn’t call them RACI) used by people higher up the chain, personally, I find that they get in the way of getting things done or they get ignored as another piece of irrelevant documentation.

Let me think about this a bit, understand how the specific implementation works. This may be a case where working software OVER documentation applies, where the doc gets in the road of getting on and doing things.

What is the practice you see happening on the ground? Is there a better way and if so, what is it?

I saw this at the bottom of the article that I linked to:

RACI is a useful tool which can become overused and be a catch all for all types of problems, so be sensible about the level of granularity for the definition of tasks/activities. Take it to a deep enough level that it is meaningful and at a level of that is sensible. Who is responsible for making the coffee is not required. It is also important to stay focused on the original reason for undertaking the RACI exercise and ensure that this goal is achieved. Rather than creating a perfect RACI covering the organisation in exquisite detail be realistic and understand that 80% of the reality of a situation will be more than the organisation ever knew before the exercise was started.

It seems that a RACI (kept light enough to be useful) is a discovery tool. Worth using, stimulating the conversation and then once you’ve figured out the gaps and how to get things moving again, thrown out the window as you get on with work. I’m guessing from what you said above, that this isn’t your experience…


#3

I totally understand why this was posted. I would challenge, however, if a tool itself is an anti pattern or if it is the application of the tool. Perhaps a team that is using a RACI is using it to uncover gaps in the op model. Perhaps they are looking to ensure the team has that shared vision. Or perhaps they are super early in a journey and want to take the first step and this is a translation layer that brings them closer to flow.

If it is intended to be a contract that weaponizes management or silos, then the intent itself is an anti pattern but methinks the issue in that context is not the RACI itself.


#4

thank you for the identification of the term and link to it.
like you said, the key part being discovery tool. With that being said, I don’t believe it’s going to be used that way but rather a finger pointing exercise and nothing more. the detail is too low but if it isn’t found I sense the answer will be “it wasn’t defined so I was waiting for someone else to do it”. Organizational silos. (of course, I hope I am wrong)


#5

most likely an anti-pattern as accountability is an issue (one of many).
If I read the room correctly on discussions, they are trying to establish working relationships/agreements between the different silos. Which, Ryan, as you mentioned, could be a journey in the beginning, could be true. but I have my doubts. One thing that is and would be missing with the challenges related to organizational priorities that trump RACI charts.

When an entry in the list says configuring application server, you know it’s an uphill battle… :frowning:

As this “journey” evolves, I will continue to report; it will take time though…