RACI Errors: Impact on Project Integration Management

In developing a good project integration management, it is critical to understand the role of responsibility assignment matrix. The goal of project management primarily is to deliver results through other people. This involves a clear role and responsibility for every work package or function that will play a critical role in project delivery. One such responsibility assignment matrix is the RACI.

I have often seen RACI filled incorrectly and have blogged (Rajagopalan, 2014). However, I would like to discuss the following two issues further as they have a relationship on other aspects of project management knowledge areas.

1.  Mixed roles with "A" and "R": When a person or function is marked with both these roles, then this may introduce the risk of project schedule slip. If the individual responsible for doing the function fails to perform, then typically the accountable person will monitor the slip and ensure that the work is getting done. Alternatively, if the work is not completed satisfactorily, the accountable person shares the onus to check on the quality and the cost of poor delivery. However, if the "R" person also is the "A" person, then the latter will not put any pressure on the former because they are both the same. This impacts risk, time, cost, and quality. Similar challenges can be seen with "R" and "C" or "I" overlap.

2. Too may "A"s: If two people are accountable, then there are two types of problems. The first is the blindness game each "A" role plays thinking that the other role will keep an eye in ensuring the task is completed. When this task fails to be done, the blindness game becomes the blame game reasoning with the "I thought you would have done it." This introduces project delays that may impact time and introduces challenges with procurement. The second issue is the team gets conflicting directions from each "A" person leaving the team to get caught between power plays. The resulting team dynamics may lead to HR and stakeholder challenges.  Furthermore, these issues may impact other areas of project management.

There are several symptoms that a proper RACI may resolve for the project manager to proactively address. But unless a project manager has a good understanding of RACI, the symptoms deteriorate leading to major problems requiring surgical intervention from executive management.  The project manager can avoid these strategically by planning to succeed with end in mind. 

References

Rajagopalan, S. (2014). RACI: Errors and Implications in building the right one. https://agilesriram.blogspot.com/2014/07/raci-errors-and-implications-in.html

RACI: Errors and Implications in building the right one

Earlier in the blog, we had discussed an overview of RACI. It is a great tool in every project and is an important tool in the Portfolio, Product, Program, Project, and Process Management Office (I call this P5MO). Too often, however, not knowing how to use this tool is like having a wrench used when a screwdriver 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.

Number	Challenge	Possible Problems
1	Too many R’s	This is the person that does the work! If there are too many people  involved, then the task is adequately defined leaving ambiguity in the task. As a result, many people are required to perform. Now, agile teams 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 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+ Rs for a task, then, trouble is brewing!
2	Too many A’s	This is the person that is answerable to the management and resolves  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” members 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.
3	No R’s	This is the 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 for it. Then, this is something that the project manager must identify in the risk register and follow through to get a closure.
4	No A’s	This is the opposite extreme of an earlier problem with much severe risk exposure. There is no accountability for any work done, leaving 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 with 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.
5	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 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.
6	Mixed letters	Occasionally, it is possible to have an accountable function along with responsible function. For instance, an internally facing project manager is 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 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.
7	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 several 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 nor 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.
8	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” members 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? 

RACI: An important tool to manage project outcome and stakeholder expectations

A few years back in a 2-day workshop on organizational strategy to structure, I saw the facilitator came up with the RACI chart and fumble on the RACI explanation confusing “A” in RACI to “Aid.” In a different situation, the vice president of a client management group was referring to giving copyrights to his manager for coming up with the RACI model. Recently, when I saw the RACI matrix for a process map on a sales-to-execution role definition, I saw processes where the same owner was both responsible and accountable and some areas where there was no person was identified as accountable.  The more I am in management, the more I am feeling that key important stakeholders should become trained on fundamentals of project management, such as the tools associated with Project Management, so that they can position the projects for success and even inadvertently don’t derail the projects.

There are several reasons why a RACI chart is required. The most common ones include when the organization is large enough that simple project communication tools alone would not eliminate role ambiguities efficiently controlling costs to the organization. The subtle reason for requiring a RACI becomes essential when the organization is siloed where several members are working on similar tasks creating waste and not making the organization lean. From a project, program, product, & portfolio management perspective, this RACI tool surfaces to the top of managing risks to these strategic initiatives as middle management wonders if they have the authority to implement their job or projects experience schedule slippage, scope creep, cost overrun, and escaped defects.

So, how does this manage strategic initiative from project to portfolio management?  Now that we realize the importance of the tool, let us ground our thoughts here in relating this tool to stakeholder and risk management. Here are my thoughts!

Role	Description	Stakeholder
Responsible	The individual performing an activity.	This person does the work. It may be a developer, tester, data analyst, or network administrator in software development or a project manager in a project.  In the Power-Interest grid, the R members are mapped to the "Keep Informed" (Low Power, High interest) quadrant for the most part.
Accountable	The individual ultimately accountable.	This person is answerable to the management in managing the client and the project’s profitability. An account manager, product manager, project manager, executive sponsor, functional manager are all examples. This person should also use the risk register effectively by mapping the risk owner to the RACI. In the Power-Interest grid, the A members are mapped to the "Manage Closely" (High Power, High interest) quadrant for the most part.
Consulted	The individual required to offer input and contribute to the activity.	This person offers 2-way communication and is a domain expert. This person should hold both “Responsible” and “Accountable” person in check if only they consult. This person alternative risk management techniques like the root cause analysis, force field analysist, and SWIFT (Structured What If Thinking) promoting thoughts that may otherwise be missed impeding flow. May be able to roll up the sleeves to do what these above roles should do. Can take on the roles of Director, Proposition Manager, Business Architect, Project Manager, etc. In the Power-Interest grid, the C members are mapped to the "Keep Satisfied" (High Power, Low interest) quadrant for the most part. But they could also come from any other quadrant.
Informed	The individual that needs to be informed of the decision and its impact.	These are the people that PMBOK calls as stakeholders that can be positively or negatively impacted by the project’s outcome. These stakeholders must be managed so that unnecessary escalation and project derailment does not happen.  The “Informed” is not limited to organizational employees and business units but customers, vendors, partners, and end-users depending upon projects or product’s goals. In the Power-Interest grid, the C members are mapped to the "Monitor Marginally" (Low Power, Low interest) quadrant for the most part. But they could also come from any other quadrant.

Every tool in the Project Management Book of Knowledge is so critical that it has its place in managing the project’s outcome. Understanding its purpose and utilizing it appropriately is critical to any organization’s job. RACI is an important asset to any management to eliminate waste, increase efficiency, and enhance stability.

Now, how do you foresee its use in your organization, business unit, and product or project management? Share your thoughts!

References

Project Management Institute (2013). Project Management Book of Knowledge. Fifth Edition. New Town Square, PA: Project Management Institute.