Search This Blog

Monday, July 28, 2014

RACI: Errors and Implications in building the right one

Earlier in the blog, we had discussed about an overview of RACI. It is a great tool in every project and is an important tool in the Portfolio, Product, Program, & Project, Management Office (Shall we call this now P4MO). Too often, however, not knowing how to use this tool is like having a wrench used when a screw driver is needed, leading to the tool’s failure. So, let me address a few key observations based on my experience working with people that apply the tool incorrectly. I would like to come up with a list of 8 key findings. These are listed in no specific order as follows.

Possible Problems
Too many R’s
This is the person that does the work! If there are too many persons involved, then, the task is adequately defined leaving ambiguity in the task. As a result, many people are required to perform.

Now, agile team may think the work effort is shared in a self-organized team addressing central dependency of failure. This is quite understandable, but then, there should be a fewer R’s. Per design, an agile team should not be more than 7 in total including the scrum master and product owner. So, if you see 3+  R’s for a task, then, trouble is brewing!
Too many A’s
This is the person that is answerable to the management and resolving impediments for the team when there is confusion! Too many A’s is an indication of chaotic control. It is like everybody wants to be engineering the solution but nobody is leading.

This could also be an indication of lack of knowledge in the groups expected to be held accountable that holds the “R’s” accountable. Agile addresses this concisely by having the product owner ultimately accountable for prioritizing the user stories, decision making in the iteration backlogs, and in grooming the backlog.
No R’s
This is an opposite extreme of an earlier problem and is equally severe. There is no one to do the work! One may associate this with the “anybody could have done the job but nobody did the job” because no one was held to it.

This is a severe issue with the project management particularly. It is possible to have this issue when a task can’t be associated with anyone because the organization has not provided a structure to it. Then, this is something that the project manager has to identify in the risk register and follow through to get a closure.
No A’s
This is an opposite extreme of an earlier problem with much severe risk exposure. There is no accountability for any work done leaving to anything being acceptable leaving the customers feel the pain.

This issue presents itself in the internal team members having multitude of meetings to figure our solutions leading to lack of productivity. When this happens, there is a “Skill/task” alignment mismatch potentially.

In my humble opinion, this should not be associated people’s morale due to trust erosion or due to organizational challenges. If any such thing existed, then, the organization must step up to ensure that the accountability is properly addressed.

No customer (internal or external) should be waiting on decisions or success/failure requirements of a task as this is fundamentally against the lean principle.
Empty spaces
If this observation exists, then, the RACI is incomplete. If this really happens to be the case, then, the project manager or the person listed as “responsible” and definitely the person listed as held “accountable” should be raising their voice. If a comparable entry in the risk register is absent so that this can be resolved, this is like an accident waiting to happen.
Mixed letters
Occasionally, it is possible to have an accountable function along with responsible function. For instance, an internally facing project manager also accountable to talk with the client. However, such occurrences should be very minimal.

It is however not acceptable to see such occurrences in some areas for tasks like “development and QA” or “QA and deployment” because this would defeat the purpose of role-assignment matrix (RAM). If this exists because of resource constraints, there should be adequate process control. Combined with resource constraints and process gaps, this is a potential for “Quality failure by design” and is also, I believe, a means to “Escaped defects.”

I also think that by definition a “R” and “A” are both “C” and “I” to a large extent. But, listing “CA” or “IR” is an issue because then it raises the question of whether the person is first consulting and then accountable? RACI should avoid such ambiguities and should be a birthplace with mixed responsibilities.
Lots of C’s
If too many C’s exist, then, I believe 3 potential problems may exist. 

The first one is that there is a skill/task alignment with people listed as responsible/accountable leading to decision by committee. No ownership exists and people are simply trying to cover their trails. 

The second one is that the culture or project itself may be so risky that a number of stakeholders may want to weigh in and potentially slowing down decision making and unnecessary escalations (needless to reinforce here the number of communication channels that exponentially increase here). 

The third one is that the underlying processes and tools are neither understood or clear requiring more conscious checking of “Am I doing it right?”

It is critical for an organization to review the RACI in such cases and address these concerns with an iron hand.
Lots of I’s
This issue may not be as severe as Lots of C’s but may be attenuated in some departments. However, it must be acknowledged that “being informed” is to be addressed in the communication plan of a project. At times, the person listed as “I” may have to promote to “C” so that no project gets derailed at times of scope creep, technical debt management, quality issues, customer concerns, etc. It is critical to note that the project consciously address the “I”s balancing the unnecessary slowdown but mitigate any derailment to a project by misinforming a stakeholder.

As you can see, developing RACI correctly is both an art and science. It is an important tool that comes to the project’s aid and should be developed with the utmost care it deserves for it to later benefit everyone that is part of the RACI chart. Wouldn’t you agree? 

No comments:

Post a Comment