Who Does What? Role Responsibility Charting in Improvement Efforts

Download PDF

BPTrends, December 2012

Authors: Alan Ramias, Cherie Wilkins


Role/Responsibility Charting in Improvement Efforts

One of the most versatile items in the performance improvement specialist’s toolkit is the role- responsibility matrix (or RRM). We have been using this handy, easy-to-apply tool for decades in all kinds of project efforts, including:

  • Process improvement projects
  • Job/role redesign projects
  • Organization redesign projects
  • Project management

Over the years we’ve come up with a number of refinements to the standard tool and its usage, which we describe in this article.

The Basic Model

The standard format for an RRM is shown in Figure 1 (Note: Figures can be seen via downloading the PDF, linked above). It consists of a chart with steps or tasks listed on the vertical axis and the responsible parties along the horizontal axis. Typically the tasks are derived from another model such as a cross-functional process map, or “swimlane” chart.

The cells within the chart may be simply filled out with X’s, as shown in Figure 1, indicating who performs or is accountable for each task. But we have found it helpful to go further, and in each cell, we describe in greater detail exactly what is being accomplished. Figure 2 shows an example of an RRM employed this way. The RRM in this example links a business process to the jobs and performers who participate in the process. The RRM is based on a cross-functional process map but describes in more detail what is happening at each step in the process. This RRM was created by simply turning the cross-functional map on its side, so that the process steps run along the vertical axis and the participants run across the columns at the top. Note that we have allocated one column to the “System”, thus recognizing that some of the process steps may be enabled or performed by some software system.

Why create an RRM? Well, as you can see in Figure 2, we have teased out more information about each step in the process than what appeared on the process map. It turns out that both steps 1 and 2 are fairly complex and that may be important to know. For example, we might be analyzing an as-is process, and this detailed information could be helpful in better understanding the steps, and in figuring out why some steps are performed poorly. If we are creating a to-be process, this RRM might be valuable in identifying the steps that will take more time, effort or skill.

In either case, the RRM supplements the process map but doesn’t replace it. Whether we go back to the process map and add these newly discovered sub steps is a decision that has to be made, but one key value of the RRM is that it enriches the details about how a process works (or will work in the future) but without adding so many steps and sub-processes to the process map that the main flow is hard to identify. PARIS Coding To further enrich the RRM, we often using a coding system of our own invention, called PARIS. (Figure 3 shows our RRM with PARIS codes.) PARIS is similar to RACI, which is very commonly used by people who create RRM’s. We prefer PARIS because in our view it provides a more thorough understanding of the process steps. Here is a comparison of the two codes:

(Note: Please download the PDF linked at the top of this page to view figures and tables in this article)

One of the key differences between RACI and PARIS is the “Accountable” designation. Our belief is that accountability belongs to both the performer and the approver and thus is satisfactorily addressed in PARIS. The other main difference is “Informed” but we have seldom seen this designation used.

Regardless which coding system you use, the purpose is to further elucidate what is going on in the process. Very often, unless we complete an RRM, details like inputs or support are either ignored or simply not recognized as necessary parts of the process, but successful performance may very well depend on them. For example, if the RRM in Figure 3 is for a process being redesigned, we might not recognize that the driver is providing his location via the company’s GPS tracking system and thus we fail to identify that system requirement.

Coding Challenges

Sometimes complexities can arise in correctly coding an RRM:

  1. Multiple performers: Normally only one function should be identified as the performer (P), which establishes clear accountability. Sometimes, however, more than one function shares a responsibility and each considers itself in charge and/or accountable.  In such a case, try to get one of the functions to treat its role as support (S) and code it accordingly. lf that is not acceptable, use a P for each function participating in the task.
  2. Review and Approve: Sometimes it will be argued that giving approval (A) must include reviewing (R), so such a task should be coded as R/A. Fine, this is a point not worth arguing about.
  3. Review, Approve and Input: Sometimes it is also argued that giving an approval is also an input, so now you have R/A/I. That seems like hairsplitting, though, and the better option would be to simply code the activity for its primary intention, which is an approval (A).
  4. Consult: The designation of R is meant to include activities commonly thought of as providing expert advice, but some people used to RACI may insist on the word “consult” instead of “review”. Fine, go ahead and substitute a C for any R where the activity is to provide advice during the performance rather than review after the performance has been executed.
  5. Review and Input: Usually when an individual or function reviews a product, they provide feedback or advice. For example, the Legal Department may review a proposal and offer a legal opinion on the soundness of the proposal. Like point #3 above, some would interpret this as both a review (reading and evaluating the proposal) and then providing an input (the legal opinion itself). Fine, go ahead and code the activity as R/l, but again it seems like hairsplitting.

Application of the RRM Tool for Job/Organization Design

In the examples we described above, the RRM is being used in support of process analysis and improvement. But it can also be employed as a device for job, department or organization analysis and design, although some changes are required. A process-based RRM like Figures 2 and 3 does not necessarily represent all the work performed by the involved functional areas of Order Entry, Dispatch and Driver Pool.

But the basic RRM format is easily modified so that the vertical axis contains all the tasks that a department does, and thus all the work performed by its employees. We could also create a higher-level RRM that lists all of an organizations major work processes on the vertical axis and all of its departments across the top. We could even do this across several organizations, each containing multiple departments.

Not only does an RRM tease out details about how work is performed, it can help to identify a number of common organizational problems such as:

  • Ambiguity about who is responsible for work
  • Redundancies in responsibilities
  • Lack of clear ownership or accountability for tasks
  • Lack of clarity for collaboration or support of performers
  • “White space” between parties in a process, especially where work is supposed to get handed off
  • Lack of understanding about what it actually takes to get a task or process accomplished


One of the tools that should be in the utility belt of every improvement practitioner is the Role- Responsibility Matrix, or RRM. This simple chart is useful for both analysis and design work, and can be applied at virtually any level, from a single process to multiple ones, from a single department to many, from one organization to several. in each of these applications, the value of the tool is what it visually captures and reveals to make the work of improvement more thorough and effective.