RACI Levels
Using accountability to better define roles and their responsibilities
Section 1
Responsibilities and Roles
In This Section
1. What Are Team Roles?
2. Why Do We Assign Roles?
3. What Are Responsibilities?
4. How Many Roles Should There Be?
What Are Team Roles?
In the chapter on GRPI we defined roles as:
A specific function carried out by a person within an organization or team.
A function is one of two things:
• A type of work
• A symbol
Most often roles are associated with work. But in some cases a role may primarily be symbolic. That is to say, an expression of intent, encouragement or aspiration.
In this book we are mainly concerned with roles doing tangible work.
A role collects a set of:
• Responsibilities
• Qualifications
• Expected contributions
Why Do We Assign Roles?
Roles are definitions for how people fit into their teams. Roles say what a person does, with whom, with what resources, for how long, and so on. This is a substantial amount of information. Collecting all that information and giving it a simple name creates a role.
In the GRPI chapter we said it is important to explicitly define roles. In the most basic sense that means saying what a person will do for the team. Practically, this information becomes too de- tailed for consistent day to day use without a simple descriptive name.
Teams may give members multiple distinct functions. In general this is a good approach. Tying each function to a clear descrip- tive name helps explain why the member is doing a particular thing. When a team make it clear why a person doing an action, or offering an opinion, it decreases resistance to change and ter- ritorial instincts.
What Are Responsibilities?
Responsibilities are one kind of individual work assignment. Virtually all work done within a team should be assigned explicitly or implicitly in a coordinated way. A responsibility is the broadest form of work assignment. Broad assignments are ones that require the assignee to contribute more information to the defini- tion and work with less oversight.
The chapter examining tasks and responsibilities goes into more detail on this.
How Many Roles Should There Be?
Again referring back to the GRPI chapter, there are advantages to:
• Assigning multiple roles to individuals
• Creating roles that do not exist outside the team
However, this suggests that there will be a relatively large number of roles.
A large number of roles could be distracting, or they could be easily absorbed. Which will occur depends in part on:
• If the roles are formal or informal
• How roles are used conversationally
• How flexible roles are understood to be
• How frequently and well the team communicates
Basically, fewer formal roles, fewer references to them in normal conversation, and reasonable flexibility tends to make roles feel like a help rather than a hinderance.
In addition, teams under certain circumstances may find fewer, more formal roles more manageable. Those circumstances in- clude teams that are:
• Balanced significantly across cultures
• Balanced significantly across organizational boundaries
• Having trouble maintaining constant, clear communications
Section 2
Levels of
Accountability
In This Section
1. What Kind Of Responsibility?
2. What Is Accountability?
3. Defining Accountabilities
4. Choosing a Configuration
5. Levels of Accountability
6. R, A, C and I
What Kind Of Responsibility?
In the context of team structures, a responsibility is the broad- est form of work assignment. That means that a responsibility is less specific then other forms of assignments, for example tasks. We will return to the comparison of responsibilities to tasks in a later chapter.
Because responsibilities are relatively broad teams may find it useful to spell out how they are to be performed. Responsibili- ties may be:
• Continuous
• Periodic
• Performed once
• Occasional
Being specific in this way simplifies things for the assignee and it may reduce opposition from other team members.
What Is Accountability?
Accountability is another way to be specific about a responsibil- ity. When we talk about accountability this way we are indicat- ing a person's liability for an outcome.
For example, a person who is responsible for making a picnic happen is generally not held accountable for the weather. How- ever, if the same person is held accountable for the success of the picnic, come what may, they are likely to consider having a tent available. They do this because they are now liable for weather-related problems.
The change in character of the assignment is typically accompanied by the threat of some kind of personal loss. Within a team such a loss would most often be at the level of losing a role, loss of face, or failing to get a good review.
Defining Accountabilities
Within a team there are several ways to position a member's accountability. They include:
• By implication or explicit assignment
• By formal or informal specification
For example, an employee review that takes teamwork into ac- count may be an implied accountability that is informally de- fined.
But if the same person has been told they will be reviewed based on their teamwork the accountability becomes explicit but remains informal, assuming no benchmarks have been set, and no reward or punishment set.
If the basis for the same team member's review is changed to specify that a daily call with a remote team member is a metric, the accountability for that call now becomes explicit and formal.
Choosing a Configuration
In most cases an explicit statement of accountability is more productive than an implied accountability. A more explicit assign- ment is more likely to be accepted and fulfilled. An implied accountability is more likely to be unfulfilled. And remember, it is difficult to apply accountability after the fact.
In contrast, an informally defined accountability may sometimes be more useful than a formal definition. This will be true in only some cases but is worth considering.
Informal accountability may be at once:
• More motivating
• Less demotivating
More motivating in part because it carries more of weight of what amounts to peer pressure. And in part because less specificity may encourage a cautious over-fulfillment in some people, and a competitive response in others.
Less demotivating because a formal definition of accountability usually carries a reward, punishment mix that may come to be seen as:
• Punitive
• An unfair chance for greater rewards
Moreover, there is evidence that explicit material rewards and punishments have an inconsistent power to motivate perform- ance.
Levels of Accountability
You may want to consider multiple levels of accountability. A level is the expected degree of involvement and liability. Levels are especially useful when multiple people share a responsibility.
The levels of accountability that are most often used are:
• Responsible
• Accountable
• Consulted
• Informed
We define these levels here. In the next section we look at how these levels, collectively RACI, are often used in organizing teams.
R,A, C and I
Responsible
The responsible level is most often used to indicate the person who will perform the main part of the work assigned.
Accountable
The accountable level carries the greatest weight of liability. It is sometimes used to indicate a person who is overseeing work that may be done only in part by themselves.
Consulted
The consulted level is generally used to indicate how information flows.
A person who has accountability at the level of consultation should think of it as a requirement for them to provide good in- formation and counsel. It is also a requirement that they receive any needed information and that their input is solicited.
Informed
The informed level, like consulted, indicates how information flows.
The typical implication is that the person who must receive information is an accessory to the work that created that informa- tion. They may not be required to contribute. Nevertheless, they have a degree of accountability due to their knowledge of the effort.
Likewise, were they to not be given the expected information an accountability would have been breached by the person who should have passed the information to them.
Section 3
Assignment
Matrixes
In This Section
1. Assignment Matrices
2. The Roles Matrix
3. Responsibilities Matrices
4. RACI Matrices and Variants
5. A Project Managers View
Assignment Matrices
There are a few ways to implement assignments. They include:
• Person to person instructions
• Lists
• Grids or matrices
This section is concerned with matrixes.
A matrix is a grid where the X and Y show team members and assignments. Boxes on the grid are marked to show who is re- sponsible for what.
The choice of how to communicate assignments has impact be- cause it shows or hides information. By showing or hiding infor- mation it has an effect on team structure and operational clarity, which affects performance.
People who advise teams or write standards often suggest using an assignment matrix. Matrices represent relatively egalitar- ian and transparent team operations. This fact is usually left un- stated.
In short, a matrix structure implies to team members that all:
• Are considered equals at least in the context of being as- signed responsibility
• Have a right to know how responsibility has been divided be- tween them
The Roles Matrix
A roles matrix has the team roles on one axis, and the team members on the other. The roles displayed may include infor- mal roles, but typically do not. Each intersection of a team member and role shows that the member has or has not been as- signed that role.
Multiple people may be assigned the same role. A roles matrix may include an indication of which person takes the lead within a role, if the team makes that distinction. Alternatively, and more commonly, that person has a different or additional leader- ship role, or the information is communicated informally.
A roles matrix helps cement the organization of the team mem- bers into roles. It should be the foundation of how a member finds individuals that may be able to contribute to their work. A roles matrix is key to realizing the benefits of roles-based organi- zation that we outlined earlier in this and previous chapters.
Responsibilities Matrices
A responsibility matrix has one of two basic forms. It has team responsibilities on one axis and on the other:
• Team roles
• Team members
A roles to responsibilities matrix has several benefits:
• It is higher level, so easier to create and understand
• It reinforces the roles-based organization of the team
• It is less brittle in that membership changes do not necessarily call for a revision and re-communication
An individual to responsibilities matrix also has advantages. They include:
• More explicit accountability is conveyed to the assignee
• All team members see clearly who is responsible when multiple individuals have the same role
Depending on circumstances, a team may use both types of matrix, or just one or the other.
RACI Matrixes and Variants
A RACI matrix is a responsibility matrix where the intersection of the grid convey the level of accountability of the assignment.
Teams most commonly use the RACI levels; however, other lev- els, additional levels or different definitions are not uncommon. Using the typical RACI levels will generally help team communications because of their greater familiarity.
A Project Managers View
Project managers with formal training have a slightly different and more specific view of responsibilities matrices. Their view follows a standard definition.
The Project Management Institute (PMI), a US-based organization promoting the project management profession, maintains the US national standard project management body of knowledge.
The PMI standard calls for projects to work from one or more Responsibility Assignment Matrix (RAM). The RAM maps tasks to individuals. PMI suggests using the RACI levels, but points out that other indications of accountability are possible.
Unlike a the other matrix forms this section describes, the PMI RAM generally maps individuals to tasks. This is an approach that has clear value in situations where detailed tasking is required. It also works well at higher levels where collections of tasks are used.
However, we would not suggest using the PMI matrix as a primary team organization tool. An individual to task matrix, at any level of detail, has drawbacks for organization. They include:
• Brittleness due to the assignment of individuals rather than roles
• Not reinforcing members' roles-based position within the team, thereby tending to weaken cohesion
• A less clear and explicit distinction between tasking and the assignment of areas of responsibility, thereby tending to weaken self-direction
• The challenges of laying out and understanding a larger grid or multiple grids due to the use of tasks and individuals, rather than the higher level responsibilities and roles We return to the question of how to assign work in the chapter comparing tasks with responsibilities.
Section 4
Implementation
In This Section
1. Some Suggestions
2. Standardize Where You Can
3. Equality Across Roles
4. Be Explicit and Informal
5. Using MetaTeam
Some Suggestions
This chapter discussed team roles and responsibilities in the context of accountability. It outlined the value of matrix struc- tures and explained the RACI accountability levels.
In this last section we offer a few quick suggestions.
Standardize Where You Can
Roles and responsibilities are particularly likely to be misunderstood because the same names are frequently used differently across teams and organizations.
For example, your teammates have probably all worked with a Project Manager role before. But all project managers are not created equal.
As PMI takes pains to make clear, a project manager in a purely hierarchical organization has very different authority and responsibilities from a project manager in matrix organization or a projectized organization. The difference may extend to whether a project manager can fire you or not. That's a signifi- cant difference!
You can't remove these differences completely, but standardize where you can. If your organization has 4 teams and 3 of them have a Software Developer role, it might be a good idea to do likewise, rather than creating a Software Engineer role that would be in essence the same thing under a different name.
Equality Across Roles
Treating similar types of roles equally makes them more useful and reenforces the value of every role. What this means is that all informal roles should be treated approximately the same regardless of if they are internal to the team or external. Like- wise, it is better to treat all formal roles similarly regardless of if they are defined at the team or organizational level.
Be Explicit and Informal
Assign responsibilities explicitly with as much specificity as possible, with one exception: treat the consequences of success and failure as informally as practical. The reasons to do this include:
• Overcommitting to a quid pro quo outcome involves usually unnecessary practical and emotional risks to both sides
• Motivation is not necessarily something that can be trans- acted; studies have found a weak correlation with hard re- wards
• It is likely that a formal reward or punishment will crowd out peer-to-peer reward or punishment; by contrast, leadership support of peer-to-peer feedback has a force-multiplier effect
Using MetaTeam
To use MetaTeam to create roles and responsibilities matrices start by doing the following:
• Log in
• Select your team from your My Teams page
• Click the Roles button in the top nav bar to begin creating team roles
• After creating a role click its name to open it. Notice that roles include not only responsibilities, but also links to goals. (MetaTeam calls goals “todo lists” by default). Also have a look at the Skills tab and the tabs for FTP planning and collaboration.
For more suggestions, tips and screenshots look in the MetaTeam blog. The RACI and Roles and Responsibilities la- bels are good places to start.
The responsibilities matrix view within MetaTeam.