Leading a change management strategy while introducing the project office with a change control board about 10 years, I emphasized the importance of RACI as a useful tool, not only to differentiate roles and responsibilities, but also sow the seeds of risk management and succession planning. Although it has been popular in the project management community as a role assignment matrix, it is needless to mention that all business units need the unambiguous definition of roles and responsibilities, whether they are designing and delivering a product, or supporting a business function like information technology services. So significant is this benefit of RACI that I have not only used it in the PMO I formed and led but also in the expert panel that I participated in extending agile principles to sales and marketing.
However, I see some misunderstanding of this technique, and subsequently, its significance downplayed because of incorrectly applying it. For instance, I saw a facilitator introducing the RACI technique for agile product management but confused the “A” in the RACI to be an “Aid” rather than “Accountable.”
In a different instance, I was reviewing the RACI matrix for a process map on a sales-to-execution role where the same owner was both responsible and accountable, and some areas where there was no person was identified as accountable. So, let us redefine RACI and the patterns to recognize incorrect use.
Need for RACI
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 reasons for requiring a RACI become 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 managing risks to the top, ensures alignment to strategic initiatives, and empowers strategic and operational governance to lay the foundations of operational excellence by proactively monitoring and avoiding the schedule slippage, scope creep, cost overrun, and escaped defects.
Definition of RACI
|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. The focus of “R” owners is producing the “outputs.”|
|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, program manager, portfolio manager, executive sponsor, functional manager, and external consultants are all examples. This person should also use the risk register effectively by mapping the risk owner to the RACI. The focus of “A” owners is ensuring the “outcome” and alignment to “benefits.”|
|Consulted||The individual required to offer input and contribute to the activity.||This person offers 2-way communication and is the expert. This person should hold both the “Responsible” and “Accountable” person in check and use the risk management strategies. He/she may be able to roll up their sleeves to actually do what these above roles should do. Can take on the roles of Director, Proposition Manager, Business Analyst, Project Manager, Program Manager, etc.|
|Informed||The individual that needs to be informed of the decision and its impact.||These are the people that PMBOK calls stakeholders that can be positively or negatively impacted by the project’s outcome. These stakeholders must be adequately engaged, 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 the project’s or product’s goals.|
Patterns to Avoid
Based on my experience, I have come up with eight patterns that need to be appropriately addressed to ensure that RACI delivers the unambiguous roles and responsibilities. These are listed in no specific order as follows.
|1||Too many R’s||· This is the person that does the work! If there are too many persons involved, then the task is inadequately defined on who is responsible for completing the work.
· Too many R’s mean too many meetings where these members are attending, increasing the cost of meetings and reducing the amount of time available to perform the work.
· The self-organized agile team may think the work effort is shared addressing central dependency of failure. Although this is understandable, 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+ R’s for a task, then trouble is brewing!
|2||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.
· Too many A’s mean one “A” owner will think the other “A” owner will get the job done and vice versa, leaving the task not getting done.
· When succession planning is incorporated, using a suffix like A1 and A2 against the role will address who is the primary owner, and who is the secondary owner.
· This could also be an indication of lack of knowledge in the groups expected to be held accountable for delegating the “R’s” to be 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 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 middle management. 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 middle management leader has to identify in the risk register and follow through to get closure.
|4||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 introducing the escaped defects. This increases the cost of non-conformance with internal and external failure impacting the performing organization, clients, and end users.
· No customer (internal or external) should be waiting for decisions or success/failure requirements of a task, as this is fundamentally against the lean principle.
· This issue presents itself in the internal team members having a multitude of meetings to figure our solutions leading to lack of productivity. When this happens, there is potentially a “Skill/task” alignment mismatch.
· This issue is also an indication of trust erosion due to organizational changes, inadequate skill-competency, and operational excellence focus. If any such thing existed, then the organization must step up to ensure that the accountability is adequately addressed.
|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 definitely the person listed as held “accountable” should be raising their voice because the “voice of the customer” is not adequately represented.
· In project launches, program maintenance, or product rollout, there is inadequate attention to detail on the transition of work to operations and sustaining it as not all the impacted stakeholders are consulted.
· 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 the responsible role. For instance, an internally facing project manager may also be 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 the 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 the seeds for “Escaped defects.”
· I also think that by definition an “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 three potential problems may exist.
· It is critical for an organization to review the RACI in such cases and address these concerns with an iron hand.
· 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 merely 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 slow down decision making and introduce unnecessary escalations (it’s needless to reinforce here the number of communication channels that exponentially increase). This challenge has to be addressed if the projects do require a valid reason for too many C’s by proper stakeholder engagement strategies.
· 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?” Introducing quality audits, operational process excellence, and training can alleviate these challenges.
|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 addresses the “I”s balancing the unnecessary slowdown but mitigate any derailment to a project by misinforming a stakeholder.|
As you can see, correctly developing RACI is both an art and science. It is a valuable tool that comes to support the organizational initiatives for delivering a client project or developing a product for the organization. It should be designed with utmost care by every business unit so that the business unit continues to operate maintaining just enough capacity and processes to sustain.
Tell me your thoughts in the comments and let’s open a dialog. I would be excited to hear other opinions on this topic.
|Consider joining our LinkedIn Group to continue this conversation as well - CLICK HERE|
|We hope you will consider joining our Facebook Community as well. Click on the image to your left to visit and join, or you can CLICK HERE|
Reading this article qualifies you to submit a request for PDU’s from PMI.
This Article qualifies as follows:
PDU AMOUNT: .25 PDU’s
For more information on registering your PDU’s with PMI – CLICK HERE
At Project Management for Today, we encourage conversation; agree with us or disagree with us, it’s all still knowledge, and we are here to share knowledge. Take a moment to add to the conversation by leaving a comment. It’s an opportunity to engage in the conversation!
If you believe in what we are doing, take a minute to share our articles on your social networks such as LinkedIn and other sites. Use the buttons on the left side of the page.
This article features content from a “Contributing Author” to the Project Management for Today Community. This content is published on this site with the author’s explicit permission. As with all articles on this site, this article is protected by copyright. If you are interested in becoming a Contributing Author to this site, you can learn more by reading the information HERE
Dr. Sriram Rajagopalan has more than 20 years of professional experience with exposure to multiple industries. He currently works as the Vice President of Training and Organizational Excellence at Aptus Health. Previously, he worked in the same capacity establishing the Proposition Delivery and Program Management Office. He also established a Project Office in West Notifications Group. He has delivered numerous projects for clients such as eFunds, Northwest Airlines, CVS Pharmacy, Prime Therapeutics, US Airways, Blue Cross Blue Shield, and several pharmaceutical firms, such as GSK, Novartis, AstraZeneca, Astellas, Depomed, and Boehringer-Ingelheim.
Sriram received the international prestigious Eric Jenett award on the Best of the Best Project Management Excellence award in Oct 2017 and was also a finalist for the Kerzner award for process excellence in 2012. He frequently blogs at agilesriram.blogspot.com, has published peer-reviewed scholarly international journals, articles at Scrum Alliance and PM Network on topics related to project management, agile transformation, and about the TONES© and PARAG© framework to middle management transformation through self-initiated postdoctoral work. He is also an active speaker speaking about these topics in professional conferences.
Sriram also holds several professional certifications (PgMP, PMP, PMI-CP, PMI-RMP, PMI-SP, CSM, CSPO, CSD, CSP, IT Project+, ACC, SCM, SCPO, SCD, SAMC, SCT, CSOXP and Six Sigma Green Belt). With extensive experience in strategic project and program delivery, he promotes the scholar practitioner approach teaching as Assistant Teaching Professor at Northeastern University and University of Riverside. He is also an active volunteer at PMI Mass Bay having served in the capacities of Director of Speaker’s Bureau, Vice President of Marketing and Communication, and as a past-board member. He also volunteers at Agile Alliance conferences and is a mentor at NAAAP.
Sriram also engages actively in training project management and agile concepts including certification preparation through his own business, Agile Training Champions (www.agiletrainingchampions.com) and also in spreading project management as a discipline to younger children in schools and colleges through his initiative on Projecting Leaders of Tomorrow (PLOT) initiative (https://www.youtube.com/watch?v=eyS_iXEH4OY)/
He graduated with a Bachelor’s degree in Electronics and Communication Engineering from the University of Madras, India, Master’s degree in Computer Engineering from Wayne State University, Michigan, MBA degree in Management from Concordia University, Wisconsin, and a doctorate degree in Organization and Management from Capella University, Minnesota.
Are you looking for more information on this topic?
PMforTODAY is committed to sharing knowledge with our readers.
Here are additional links to articles on this topic, both on our site and others.