The Problem with RACI

While the Project Management Body of Knowledge (PMBOK Guide®) may refer to it as a Responsibility Accountability Matrix, everyone I know calls it a RACI Matrix. It is supposed to clarify roles and responsibilities, yet it often creates more confusion that it clarifies.  So let’s look at this tool, the benefits and the pitfalls that create the problems.

Assigning responsibility for work is an age-old principle.  Even in early civilization, some people were designated to have certain responsibilities. The ancient kings had cupbearer, chariot drivers, shield-bearers, and ministers of all types.  These individuals had specific responsibilities and if they didn’t perform the punishment was often sharp and swift.  In more modern times, thanks to Fredrick Winslow Taylor and scientific management theory, everyone in business has a designated role or position and they are expected to become expert at the responsibilities associated with that role.

But projects are a little different.  They don’t always lend themselves to scientific management principles. Projects are temporary endeavours undertaken to create a unique result.  Individuals on the project team are temporarily assigned to work on project activities, and some of those activities may not be well defined.  Because of the unique nature of projects, a pattern may not already exist.  Roles, responsibilities, authority, and accountability need to be assigned to prevent duplication or work or missing work.  Which brings us to the RACI matrix.

RACI Matrix

The RACI matrix is the most common tool for assigning roles and responsibility to project team members.  The matrix is structured by placing the project tasks on one side of the matrix, normally the vertical axis; and the project team members on the other side of the matrix, normally the horizontal axis.  The role of each individual with respect to each task is then noted in the matrix as either R – Responsible, A – Accountable, C – Consulted, I –Informed, or left blank if the individual has no role.

The RACI matrix assigns a role to each individual, but it does not clarify what they are supposed to do.  And that is what leads to the confusion.  Who plans the task – the “Accountable” person or the “Responsible” person?  I have seen it explained both ways.  Does the “Consulted” person only participate when asked, or are they expected to engage and ensure their perspective is included?  Again I have heard it described both ways.  And then there is the question, “How can someone be accountable but not responsible, or responsible but not accountable?” 

Questions like these and others have led to a plethora of variations on the RACI matrix.  The fact that there are so many variations is an indication that there is a major flaw with the RACI approach.  If it was working well, people wouldn’t be trying so hard to improve it.   Let me list a few of the alternate approaches.

Alternate Responsibility Matrix Approaches

• ARCI – rearranging the letters because Accountable is more important than Responsible.
• RASI – Responsible, Accountable, Support, and Informed attempts to better define the original Consult role by now calling it Support.
• RACIQ – Responsible, Accountable, Consulted, Informed, Quality reviewer – this adds a role for review and approval.
• RACIO – Responsible, Accountable, Consulted, Informed, Omitted – this approach is meant to ensure that some individuals do not engage on a task and tamper with what is happening.
• RATSI – Responsibility, Authority, Task, Support, Informed – a slightly different segmentation of roles meant to clarify the differences as compared to the original RACI.
• RAPID – Recommend, Agree, Perform, Input, Decide – a variation that focuses on decision making authority rather than on the actual task activity.
• PACSI – Perform, Accountable, Control, Support and Informed – a variation that identifies some activities that must be done in addition to roles.
• DACI – Drivers, Approvers, Contributors, Informed – a variation that focuses on the type of activity that the person does rather than their role.
• CLAM – Contributes, Leads, Approves, Monitors – another variation that focuses on the type of activity rather than roles.

There are probably more, these are just the ones that I am aware of. 

The Problem

So what is the fundamental problem with RACI?  I believe it is that while defining roles, it does not clarify actions.  But clear actions are what a project needs.  As a retrospective tool to look back on a situation, RACI is effective.  It can determine who was responsible for success or failure?  Who was accountable for ensuring the task was completed?  Who was consulted along the way and how effective was their input?  And who was or was not informed and what impact did that have on the project?  Great questions when doing a post-mortem on a project; but not very helpful for proactive project management.

 When planning and executing a project, the project team members need to know who is doing what.  A matrix focused on actions associated with each task is much more beneficial to the team.  Who is planning the work?  Who will be helping on the task?  Who are the stakeholders that have to approve or sign off on the results of the task?  With these answers, the project leader and project team can manage their resources, coordinate the schedule, and ensure that risk mitigation plans are being executed in a proactive manner.  They don’t have to wait for success or failure and they try to understand what happened.

Recommendation: DACI or CLAM

For that reason, I recommend the use of either the DACI or CLAM approach.  These are activity-based matrices.  I have found that the level of confusion concerning who is doing what is significantly reduced when these are used in project planning and execution.  

VUCA Product Development

In most companies, developing new products is a critical component of strategy.  Many companies are finding this to be more and more difficult as their environment increases in VUCA.  The acronym VUCA stands for Volatility, Uncertainty, Complexity, and Ambiguity.  This acronym was created and gained recognition in the strategic planning circles of the US military during the past 15 years.  A body of knowledge is being developed around leadership in the VUCA world, with numerous articles and books published in the past few years.

Bob Johansen has proposed a leadership response to the VUCA environment which he titles VUCA Prime.  According to Johansen, volatility is countered by vision, uncertainty is countered by understanding, complexity is countered by clarity, and ambiguity is countered by agility. Let’s take a look at each of the elements of VUCA and VUCA Prime as they apply to product development.

Volatility

Volatile is defined as changeable – and often with an explosive or fleeting connotation.  Volatile situations are full of surprises.  Vision is the recommended leadership response.  Developing and articulating a clear vision will assist an organization through the volatility be reducing the disorientation that occurs when a volatile situation unfolds.  Even though there is rapid changes happening all around, the vision and direction stay constant; providing a basis for decision-making and action.

Product development involving innovative new technology, or a marketplace that is fast developing with new customers and competitors, can often be volatile.  The vision that is needed for the product development team is a clear product line strategy.  The strategy that has identified target markets and the characteristics of new products will guide the product development team through the technology, design, and business trade-offs that must be made when volatility strikes.  Without a clear product line strategy, the product development team often stalls as they start chasing options and waiting for decisions from stakeholders.

Uncertainty

Uncertain is defined as the state of being unpredictable and indeterminate.  There are numerous significant unknowns in the business situation.  The environment is novel to the point that past experience cannot be used as the measure for what should be done now.   However, in an uncertain environment, there are facts that could be discovered.   The recommended response to uncertainty is understanding.  This requires investigation, fact-finding, and analysis.  Rather than responding in a dogmatic manner using outdated principles, the response is to slow down and learn what is actually happening. 

Within the product development environment for innovative new products; there is normally uncertainty with respect to customer needs, product performance, and market response.  There are two approaches being used to create understanding within product development methodologies.  One approach is to do extensive upfront analysis using tools such as the Quality Function Deployment.  The other approach is to create a series of rapid prototypes of a minimally viable product to get “real-world” experience and feedback.  I have used both approaches and there are pros and cons for each.  The key takeaway for this discussion is that there is work that must be done to gain understanding.  And that work needs to be built into the development project plan.

Complexity

Complex is defined as intricate, often complicated, interconnected parts, processes, or organizations.  With complexity comes options and opportunities.  Some of these options and opportunities are very favourable and some are disastrous.  Navigating through the complexity requires numerous decisions.  The recommended response to complexity is clarity.  Clarity exposes the decision points and the options.  Clarity will also often provide a framework for understanding the implications of decisions.  Clarity exposes pathways through the complexity.

Product development of new innovative products will often involve complexity on several levels.  If the product is a system, there will be multiple components, possibly hardware and software, that must all work together.  And research shows that system integration and test is one of the most likely areas of a product development project to overrun both time and money.  In addition, there is often organizational complexity.  Marketing is developing requirements, engineering is creating designs, quality is establishing test and inspection methodologies, operations is setting up manufacturing and logistics processes and facilities, IT is bringing new databases online and possibly new systems for support.  All of these functions must work together and a change in one cascades through all the rest.  Establishing a stage-gate product development methodology with defined practices and decisions points will go a long way to creating clarity in product development.

Ambiguity

Ambiguous is defined as obscure, indistinct, and with numerous possible interpretations.  Unlike our definition for uncertain where facts are available but are not yet known; in an ambiguous environment there is normally no “right” or “wrong” answer.  Instead the answer is always, “it depends.”  The recommended response to ambiguity is agility.  This means that as the fluid situation continues to change, the decisions are revised and updated frequently.   Nothing is ever final; it is just the “current state,” with the expectation that change will soon be required.

In the global marketplace, industries are separating into those that are ambiguous and those that are rigid.  The highly regulated industries have a tendency to be very rigid and those that are not regulated are often ambiguous.  But regardless of the industry, the product development environment is ambiguous.  It follows that an ambiguous end market will create an ambiguous product development process.  As the target for product definition and performance is constantly changing, whatever product is developed will immediately need an upgrade or replacement product.   But even in rigid end markets, development is ambiguous.  The regulatory environment is often different in different countries or areas, and these regulations are frequently changing.  In addition, the regulatory agencies interpretations of regulations are often inconsistent.   Regardless of the industry, a rapid pulsing process is needed to determine the current state of the market and industry environment.  This must be coupled with a robust change management process for product development.   Finally, the product development metrics must be focused on business success or failure of the product, not on time and budget targets for the project.

If you are involved in product development today, you are probably experiencing VUCA.  You may reminisce about the “good old days” when things were calm and simple.  But don’t expect those days to return.  Instead embrace an approach to have vision, understanding, clarity and agility.

Learning Lessons from Lessons Learned

They go by many names including: Lessons Learned Sessions, After Action Reviews, Post-mortems, Post Project Evaluation, Learn and Grow, and Project Retrospective.  These sessions are the time when the project leader and project team look back over the project, or at least a portion of it, and attempt to learn from their experiences.  It is a practice that is called for in many project management methodologies, yet often neglected.  

When I ask people why they haven’t done one, I get many different reasons.  “Everyone is busy on other projects now.” ‘Why bother, we won’t change anything.” “Most of the team at the end of the project is different from the beginning team.  They didn’t participate in many of the decisions.”   In fact, often these are backwards looking, blame-focused sessions.  When that occurs, it is an indicator that the organization and project teams don’t understand how to use these sessions.

I would like to discuss five elements of effective reviews.  These are the purpose, the timing, the participants, the questions asked, and the follow-up.

Purpose

The purpose of these sessions is continuous improvement.  These are not meant to be final project reports or a history of what happened.  They are intended to improve the planning and execution of the current and future projects.  One of the implications of this purpose is that anything can be discussed.  There are no “sacred cows.”  Don’t avoid subjects because it many hurt someone’s feelings or it makes them uncomfortable.  The goal is to improve performance.  If we ignore some aspect of performance, it will not improve. 

Timing

A mistake often made when doing project reviews is that the review occurs long after the project is over and the review then considers the entire project.  A much better approach is to do a quick review after each phase or milestone with the project team so that they can immediately take action to improve the remainder of the project.  This type of review doesn’t need to be an all-day offsite meeting with formal facilitators and reports.  It can be a pizza lunch with post-it notes on a white board.

Let’s consider for a moment one of the best models of how to conduct one of these sessions, and that is the US Army’s After Action Review format.  First, note that it is not an “After War Review” with Monday morning quarterbacks looking back over years of history and trying to find the big lessons of the war.  It is a review that is immediately conducted following an action or event.  Everyone from the team is still there.  The events are fresh in everyone’s mind, and because it is focused on what the team just did; many of the recommendations are immediately actionable by the team.

Participants

This gets us to the participants in the review.  I recommend that it is the team, the whole team, and nothing but the team.  Well, you may want to have someone from the PMO or another project leader to help take notes and facilitate.  This is especially true if there were some leadership problems and the team might be uncomfortable discussing this in a meeting being run by the project leader.  There is no need for senior management in this meeting.  Their presence is likely to repress the conversation.  It is appropriate for the project leader to provide a summary of the results to senior management and the PMO.  But the discussion is likely to be much more open and honest if the meeting is just the team members.

Questions

The agenda for the meeting is very simple.  What is going right and what is going wrong.  The team may want to vent a little if there are problems or celebrate if things are going well.  Let them release a little emotion, but then focus them on these questions:

• What is going well that we want to continue?
• What is not going well that we need to change?
• What should we do differently as part of the change?
• What recommendations do you want to make to the organization to pass onto other teams?

Follow-up

Well, as you can see from the questions, we anticipate that we will want to make changes.  It is possible that the team may say that everything is going great and nothing should change.  When that is the case, the team should be making a recommendation to the organization so other teams can copy their result.  However, most of the time there will be some changes.  By conducting the review with the current project team, they can also decide what they will change – starting tomorrow.  I like to get very specific when I discuss the changes.  I go around the room and ask each person what they personally will be doing differently.  Doing this in the room among the team members will improve personal accountability among the team members.

Turning these reviews into forward looking change events instead of backward looking blame events will make them productive.  They really will drive continuous improvement.