PM Articles > Kent McDonald > Titles and Accountabilities

Titles and Accountabilities

by Kent McDonald

I have been having several conversations recently around the subjects of accountability vs. responsibility and titles vs. roles, specifically around who does what on a project and what they are really supposed to be doing. There were a lot of undercurrents in these conversations, but there are a few that are worth exploring as relevant to your effectiveness leading a project team. Keep these ideas in mind the next time you work with your team to determine who is doing what on your project.

You Keep Using That Word …

At the risk of sounding like Inigo Montoya, accountability may not mean what you think it means. Accountability and responsibility mean two different things in the famous RACI chart, but it's not clear what Accountability adds other than a handy vowel. In fact, there is no clear agreement on the definition of accountability, or the distinction between accountability and responsibility, and several people seem to use them interchangeably. This does no one any good, especially since the distinction between accountable and responsible is quite important when talking about leading people through influence rather than through authority.

Defining a word without using a derivative of that word can be very difficult, especially with such a nebulous concept. One good definition comes from Heather Stagl: "Accountability is a promise to yourself and others to deliver specific, defined results, with consequences." I also like to think of it as "the buck stops here," which means that only one person can be accountable for any given thing. If the results are inadequate, there are consequences for the one person who is accountable. In my current context, those consequences are an impact on the accountable person's performance review.

Responsibility, on the other hand, falls to the person who actually performs the activity to produce the result. You can think of it this way: someone is accountable for getting the work done, but they may delegate the responsibility for completing that work to someone else, or they may possess both the accountability and responsibility themselves.

The Accountability Onion

While accountability for a given result cannot be shared, that result may be broken down into component results, with different people accountable for each. So if the Business Owner is accountable for the results of the project, accountability for the individual project activities that lead to those results may be distributed to the appropriate members of the project team. For example, your project manager is accountable for delivering the agreed upon project scope on time and within budget, a business analyst may be accountable for the requirements, and your tech lead may be accountable for the technical solution.

I refer to this as the accountability onion, because if accountability were not layered in this manner, the CEO would inevitably be accountable for not only the results of the organization, but also all aspects that drive those results. Others would certainly be responsible, but without accountability and its attendant consequences, the commitment to generate the desired results might not exist. This speaks to an unpleasant but altogether real aspect of human nature—unless people feel accountable for something, they will not necessarily put the necessary effort or attention into it.

Push Accountability as Close to the Work as Possible

If you extend the thought above to one logical conclusion, you want to lay accountability for the work as close as possible to the people actually doing the work. This could mean that the same role is both accountable and responsible for an activity. In this situation, the person filling that role will most likely pay much closer attention to what they are doing, if only because they personalize the consequences of not meeting expectations.

This can be a very difficult concept to grasp, especially in a low trust environment. Some individuals may feel that they are being held accountable for results that they do not have the power or authority to produce. On the other hand, leaders who are typically held accountable for the work their direct reports do may be reluctant to give up this accountability, for fear their direct reports will not produce the desired results without their intervention. This may also be a concern held by the direct leader's leaders.

Experience has taught me that when people are held accountable for the actions of their staff, instead of the staff themselves being accountable, a series of reviews and approvals becomes commonplace. This adds non-value-added work into processes, whether it's an ongoing business process or a project in a matrix organization.

On a sports team, the coach(es) work very hard to put a game plan together and train their players on the basic skills and the plays that apply those skills. But come game time, the players themselves are responsible for running those plays and are accountable for the results by virtue of wins and losses, as well as potentially losing playing time if they continue to perform in a manner detrimental to the team. Sure, the coach is also held accountable over an extended period of time; if the team does not perform up to expectations, the coach could lose their job. This is an example of the accountability onion. The coach is accountable for the long-term success of the program, while the players are accountable for their individual contributions to that overall performance.

Pushing accountability requires a change in behavior from the people doing the work as well as their leaders. The people doing the work should feel ownership over their tasks, and should be more focused on their work. If people do not react this way, they are probably in the wrong job and should be moved to something where they can act on their accountability, or removed from the organization altogether. Meanwhile, the leaders need to change their mindset from that of approver and overseer to that of mentor and coach.

A Title Filling a Role

Lack of clarity surrounding roles and titles can cause confusion about responsibility and accountability for project work. In many conversations about roles and responsibilities, I find people get hung up on who does what, especially when people's job titles match the roles identified in an approach to a project. Project Manager, Business Analyst, Developer, Technical Lead, and Architect can be both titles and project roles (in this case, on IT projects). Organizations should establish some guidelines about which roles should be accountable and responsible for specific activities on a project. That creates some semblance of consistency in a project world where variability reigns.

Confusion creeps in when a project team tries to identify who is doing what on a specific project. At this point, the skill sets of the individuals assigned to the project is much more important than titles. For example, a team member may be a titled Business Analyst, and have skill sets that are useful for activities that are the responsibility of the tester role. If that person is the most appropriate for those activities, you can do one of two things:

  • Make the conscious decision that the person with the title "Business Analyst" will fill the role of "tester" on this project.
  • Make the conscious decision that for this project, some or all of the activities that are the responsibility of the tester role will become the responsibility of the Business Analyst role, which is being filled with someone who also has the Business Analyst title.

Having consistent and clearly-defined roles and responsibilities helps an organization know where to focus their hiring and performance evaluation efforts for a given job title, but flexibility in filling those roles on a specific project will best meet the needs of each project in the most effective and efficient manner possible. If your organization is convinced that someone with a specific title cannot fill multiple roles on a project, you will find your project staffed with a large number of specialists. This drives up the number of people required to complete a project, leading to an excessive number of communication channels as well as projects that take much longer and are much more expensive than they need to be.

Roles and Responsibilities may change throughout the project

This all assumes an explicit discussion among team members at the beginning of a project to determine who is filling which roles. But that single discussion is insufficient. As the project progresses, conditions and staffing change. It's a good practice to reevaluate roles and responsibilities multiple times throughout the project. Whether this is when someone leaves or joins the team, or at milestones such as the end of an iteration or the end of a phase, depends on the nature of the project. The idea is to proactively discuss the need to revise role and responsibility expectations before confusion results. You don't want multiple people working on the same thing, or activities missed because one team member assumed another team member was covering it.

I would like to think that if I keep these things in mind there will never be confusion over who is supposed to be doing what on my projects, but that would be naïve. Something will always happen that leads to confusion surrounding accountabilities and responsibilities; there may be differences of opinion about who owns what, or things may start moving too fast for us to keep ahead of them. Either way, I can take some solace in the fact that by following this advice I will keep those occurrences to a minimum, and they will have a smaller impact on the overall project.

Related Links
RACI has it's place, but you can take responsibility and accountability to a whole new level with a Responsibility Allocation Matrix. Of course, it helps if you have the right team to start with. If you need to drill home the concept of accountability at home, nothing beats the Laundry Lottery.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

Great article and I love the Inigo Montoya reference :)

If accountability remains with executive/manager, while responsibility is with the skilled practitioners, then the correct dynamic that exec/mgr makes resources, trng, etc, available is set up. Since "auditing / reviewing in" quality doesn't work, you're also right about non-value-added work being added from excessive reviews. The 10/05 HBR article on DICE criteria shows monthly reviews are optimal. Problem is understanding what knowledge, skills & experiences are needed on a project and how best to put a team together to cover the KS&Es so that responsibility is covered and exec/mgr accountability therefore can be retained with apropos risk. Execs/Mgrs have to be collaborative with techs to get it right.

What is totally missing in all of this is authority. Without the authority to make decisions or supply resources makings someone accountable is not only unproductive but makes the situation a no win for everyone. Before assigning accountability management must assign authority.

Authority can be delegated, but not responsibility. The leader of an organization is responsible for all outcomes, good or bad, effected by that organization. While authority to act may be delegated downwards, those who exercise this authority are accountable to the leader for their actions.

Well everyone who is employed by the organisation getting a salary is accountable, one way or another. The ONION dynamic theory is right.

Excellent post Kent! I have been concerned with all aspects of job titles for many years. I have watched another aspect creep into organizations - it is called "job title inflation."
A friend of mine did a post on this at and says "Depending on your company’s culture, job titles may be just a string of words that are basically irrelevant to the real world..."


The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.