The Importance of Defining Roles and Responsibilities

This blog post is the second in a series where I’m digging deeper into each of the four points I shared in an article titled “Beware of hearing what you want to hear.” I hope you’ll find some ideas that will be useful in your projects and relationships.

Four ideas that I’ve found to be important as we help clients execute on their digital transformation projects are:

  1. Clarify expectations, speak them back, rinse and repeat
  2. Define the roles that are needed to do the work, and then agree on who is doing them
  3. Have the hard conversations quickly and openly
  4. Don’t give up too soon, stay the course

In my last post, I dug into idea #1 Clarify expectations, speak them back, rinse and repeat.

This time we’ll be focusing on idea #2:

Idea #2: Define the roles that are needed to do the work, and then agree on who is doing them

Beware of Hearing What You Want to Hear Ideas 4

Imagine that you are part of a motivated team working to do something important.

Everyone is excited.

The right people are on the team.

The energy is high.

However, as the team gets started it becomes obvious that something isn’t right.

There isn’t much of a plan in place.

It seems like nobody is in charge.

Even though there’s lots of work to be done, it isn’t clear who is doing what.

The natural leaders on the team start speaking up, trying to provide some structure and organization.

There’s disagreement and confusion.

Time is wasted.

Not much work gets done.

Team members who were once excited become frustrated.

Failure seems likely.

Have you ever experienced something like this? I certainly have. Unfortunately, a few times I’ve been the leader responsible for creating the mess. But Agile teaches us that there’s value in failing and that the lessons learned in those moments will help us on the journey of personal and organizational improvement. Below are a few insights I’ve gained from this exact process:

How to Define Roles in a Team 

I believe that most people want to do good work.

Beware of Hearing What You Want to Hear Ideas (1)

However, to do good work people need to have a clear vision of what the expectation are. Each member of the team needs to understand the roles on the team, where they fit in, and what they are responsible to accomplish.

Note that there are two important parts:

  1. What roles are needed for success?
  2. What role is each person filling?

Over the years I’ve found that visual aids can help this conversation. I recently created a few slides to share with clients as we’re discussing a new project.

What Roles are Needed for Success?

One slide helps us explore the question of “What roles are needed for this project to succeed?” Over the years we’ve identified some leadership tasks that need doing on every development project:

  • Defining success (Product Owner)
  • Managing expectations (Veracity Delivery Director)
  • Nurturing our working relationship with the client (Veracity Client Partner)
  • Guiding the project to success (Project Manager)
  • Leading and guiding the engineers (Engineering Manager)
  • Leading agile ceremonies and activities (Agile Coach or ScrumMaster)

The slide below visually depicts these leadership roles and helps us align on who will be filling these roles.

Flow chart showing the steps and categories of the project's success.

This usually creates a good discussion around the nature of the work, specific expertise, how the project will run, and even some of the complexities of the project.

What Role is Each Person Filling?

Next, we explore the question of “What roles do you want to fill yourself vs. what would you like Veracity to help with?” As we discuss, we create a picture of what the roles will be and who will be responsible to fill them.

Perhaps the client wants to provide most of the leadership. This slide depicts the Client handling the Product Owner, Engineering Manager, Project Manager, and ScrumMaster roles, while Veracity is handling the Relationship and Expectations management. The client will also be providing some Developers and an Architect to work with the Veracity team.

Flow chart showing the roles of an organization and who manages what.

Or perhaps the client wants a full-service solution with Veracity providing the project leadership. This slide depicts the client handling the Product Owner role, with Veracity handling the Engineering Manager, Project Manager, and ScrumMaster roles, as well as Expectations and Relationship Management.

Who manages who?

Define the roles_3

We’ll often edit slides like this in real-time with the client, using the Active Listening skills we’ve learned so we can catch the nuances in their expectations. The goal is trying to make sure everything is represented, and we’re aligned on who is filling each role.

One thing to note, the client almost always needs to fill the Product Owner role. The Product Owner provides the vision for the project and the definition of success. It is very difficult for an outsider to come in and define the vision, goals, and what success will look like. However, if a client is in an early stage of ideation we have a visioning workshop to help brainstorm ideas and clarify and align on the vision for a project.

What is RACI?

Depending on the nature of the work your team is doing, you may also find the concept of a RACI chart helpful to lay out the roles and who is doing what. There are a few different versions of the RACI concept, but the basic idea is based on an acronym:

R = Responsible: Who is responsible for doing the work?

A = Accountable: Who is accountable for making sure the work is done successfully?

C = Consulted: Who will be consulted to provide guidance and input as the work is done?

I = Informed: Who will be kept informed of progress and status as the work is done?

I’ve grown to appreciate RACI charts, but I’ve also found a few drawbacks in using them.

Drawbacks of RACI

One of our team members hadn’t heard of the RACI concept before. As we talked about our team’s RACI chart they kept thinking we were talking about “racy” charts. We all had a good laugh once they realized the RACI chart was much more boring and less “racy” than they expected. So make sure you start off introducing RACI visually to clear up any “racy” confusion.

Additionally, there tends to be a lot of confusion between the different parts. This is especially true of the differences with Responsible vs. Accountable. It is important to talk through this with the team and make sure each person knows if they are Responsible, Accountable, Consulted, or Informed.

I’ve sometimes seen RACI charts used in dysfunctional teams as a weapon to play a blame game.

“It’s not my fault things didn’t get done right. I’m just Consulted in this role. I’m not Responsible to get things done right.”

Though that is probably technically correct, an attitude like that indicates bigger problems with team dynamics. A high-performing team will be clear on roles but will usually have more of a “win together, lose together” mindset. Team members will cross roles to help those who are struggling and help the team succeed.

Conclusion

If you’d like to learn more about RACI charts just do a quick web search. There are hundreds of articles and opinions out there, including variations like RASCI, RASI, PARIS, CAIRO, and on and on (also see RACI on Wikipedia and racichart.org).

Once you’ve define the roles you need for success, and you find alignment with the team so that each person knows their role, that is when the team can start.

When the team starts working, you’ll probably have some challenges pop up.

That leads us to Idea #3 which I’ll cover next time:

Idea #3 – Have the hard conversations quickly and openly

Depending on your personality, you may find this to be the most difficult of the four ideas. We’ll talk about this more in my next post, and hopefully, I can offer some thoughts that will make these hard conversations a bit easier.

Skip to content