Managing a team often means overseeing multiple projects. Depending on how many employees you supervise, this can get complicated pretty quickly. It helps to have tracking tools to keep tabs on everything, but a lot of the "official" project management programs are cumbersome to use and could be a full-time job in and of themselves. Thankfully, you don't have to be a certified project manager to benefit from some of the helpful tools of project management. Even better: since you're using them for your team's internal purposes, you can adapt them in ways that would not be found in the PMBOK (Project Management Body of Knowledge) but are just right for you.
A commonly used tool, usually referred to as the RACI model, can be adapted to help you clarify roles and responsibilities on your team. This tool can be helpful in identifying who's doing what for each major process and project on your team, and who has final authority over each area. It can also help you see whether you've allocated work evenly and where you might have some key person dependencies that put your team at risk.
The RASCI Model for Teams
First, a few definitions to help explain our version of this tool, which we'll call the RASCI model.
Responsible: the person who is the primary “doer” of the process or project. Can be thought of as the project manager. For best results, each process or project should only have one R – if there are multiple project leads, consider splitting the project into its component parts, each with its own R.
Accountable: the person who has final approval of the process or project. Can be thought of as the client or approver. Each project or process should have only one A.
Supportive: others who will help the R carry out the process or project. Can be thought of as the project team. For some projects or processes, there will not be anyone in this category because R is doing all of the work. Cross-trained team members who could fill in for R could also fall into this category.
Consulted: people or teams who should provide input into the project. Can be though of as “SMEs” (subject matter experts). Communication with Cs is two-way. Each process or project can have multiple Cs, but only people who can provide substantive input should be Cs. All others should be in the I category to keep things manageable.
Informed: people or teams who are affected by the process or project and should be kept informed. Can be thought of as stakeholders. Communication with Is is one-way. Each projecet or process can (and probably should) have multiple Is, and it may make sense to list roles or teams rather than individuals. For example, “junior analysts” or “purchasing department.”
Note: The RASCI model can be used for each project individually, or it can be used to map all of a team’s processes and projects.
- Make a list of projects and processes that cross multiple teams or areas.
- Break each project or process down into logical parts or phases. For example, if a project involves a planning phase where one set of people are involved and then an implementation phase where different people are involved, it may make sense to treat that as two projects (“Planning for X” and “Implementation of X”) rather than just one.
- For each item, identify a specific person for the Accountable role and the Responsible role. In some cases, the same person could play both roles.
- For each item, identify additional people, teams, or roles that are involved. For the S, C, and I columns, multiple people can be listed, and they can be listed in groups rather than by name if that makes more sense. The Accountable person for the project or process may also be listed in one of these categories if applicable. (For example, if the Accountable person needs to provide expert input during the design phase in addition to approving the work, they are both the A and a C for that project.)
- Share the responsibility assignment matrix for each project with the people involved to ensure that everyone is clear on their roles. In particular, it’s important to make sure that people who think they should be in the C category but who really just need to be informed (I) know up front that they will not have input into the project. (Tip: if this is going to be controversial, define the criteria for being consulted before assigning names, so that it’s clear who is actually qualified to provide expert input.)
Once you've completed the process above for each project or process your team is responsible for, you'll end up with a chart that looks something like this:
You can use your chart as a handy reference, and it can also help in identify any team members who show up too many times in the "R" column. As your employees become more independent, you can look for opportunities to shift the "A" role to them, freeing you up for other projects. You can also check the "R" column to see how many times your own name shows up. If you're actively managing your team, you should be an "A" far more often than you're the "R."