It took me some time into my project management career to realise, and logically accept the fact, that within the project management domain one has to have clear appreciation of the distinction between Accountability, and Responsibility.

The fundamental point this discussion is attempting to address is the question of “when and where does the buck stop?”. And more specifically, should any issues arise during the course of a project delivery, is it the project manager who is by default the one who needs to pay the ultimate price for the failure or is this issue a bit more complicated than that?

Let’s examine the following simple scenario:

You manage a large integration project involving 10 different technology groups. Clearly you can’t be intimately familiar and hands-on with each and every aspect of the integration process. Obviously, like many other project managers you heroically claim that everything that happens in your project is your responsibility, but is this really the case? Is there a point until which things might happen under your watch for which you could not and would not take the responsibility?

So what is the difference between Accountability and Responsibility?

A literature search highlights the fact that there doesn’t seem to be clear and unanimous definition for each of these terms. In fact, a cursory look at dictionary.com clearly demonstrates the confusion where the definition for Accountability is explained also in terms of Responsibility, and vice versa.

In Responsibility vs. Accountability, the authors suggest that “Responsibility may be bestowed, but accountability must be taken. In other words, responsibility can be given or received, even assumed, but that doesn’t automatically guarantee that personal accountability will be taken. Which means that it’s possible to bear responsibility for something or someone but still lack accountability“.

With that interpretation in mind it could be inferred that every person on the project team could be responsible (by assignment) but his or her accountability is dependent on their level of commitment and acceptance of such accountability.

I’m not happy with this definition as it makes things a bit loose.  Can a project manager get a ‘out of jail’ card based on the argument that his/her team did not exercise their right to accept their accountability? Doesn’t seem right to me so we need to dig a bit further.

A good summary document by Michael L Smith and James Erwin, titled “Role & Responsibility Charting (RACI)” provides the breakthrough I was looking for.

The authors make the following excellent observation:

Managers and supervisors are not accountable for everything in their organization. Responsibility charting ensures accountability is placed with the person who really can be accountable for specific work. Often this results in accountabilities for actions being moved down to the most appropriate level.

This is an important point. Accountability does not necessarily live at the very top but rather it is positioned at the most appropriate level, with the person who can be accountable for the work.

The authors provide further elaboration on the definitions of Responsible and Accountable, as follows:

The Accountable person is the individual who is ultimately answerable for the activity or decision. This includes “yes” or “no” authority and veto power. Only one Accountable person can be assigned to an action.

The Responsible person is the individual(s) who actually complete the task. The Responsible person is responsible for action/implementation. Responsibility can be shared. The degree of responsibility is determined by the  individual with the “Accountability”.

The above definitions provide a much greater level of clarity and are easy to understand within a project environment. But casting our mind back to the scenario provided earlier in this post, would we be now in a better position to ascertain whose fault it is, should the project fail to deliver?

Clear determination of the projects’ roles and responsibilities (by publishing a detailed RACI matrix) can go a long way towards eliminating any ambiguities and misunderstandings. An up-front determination of Accountabilities and Responsibilities is just the beginning, and this needs tobe followed by a clear communication and acceptance of these roles and responsibilities by the assignees.

Blame games and apportioning of faults can only thrive in an environment where it has never been clear who is responsible and who is accountable. If these are not properly communicated there’s a good chance it is you, the project manager, who will be asked to respond to the “please explain” note from the project sponsor.

Think about it!

Print Friendly

2 Comments

  1. Pingback: Cornelius Fichtner

  2. Pingback: Joan Anton Nieto

  3. Pingback: Janick

  4. Pingback: Training PRINCE2

  5. Good post. The definitions you provided are right on. The RACI tool is invaluable to sort out roles and responsibilities. It points out where you have R & A gaps. If you do not fill the gaps, it comes back on you as the PM. In addition, I find the project core team and steering team are formed from the R’s and A’s.

    Reply

    • Hi Steve, thanks for your comment.

      The RACI document mentioned in the body of the post is an excellent reference document for understanding the intent behind the RACI matrix. Certainly, as you correctly point out, if you don’t attend to the RACI in a serious manner it will come back and bite you.

      Cheers, Shim.

      p.s. I’ve added your blog to my Google Reader feeder list.

      Reply

  6. Pingback: African eDev Centre

  7. Pingback: MindEdge

  8. Pingback: Vladimir Havel

  9. Pingback: Who’s Responsibility Is It Anyway? | quantmleap

  10. Pingback: Cheri Essner, PMP

  11. Pingback: Nick Patterson

  12. Pingback: Responsibility vs. Accountability | Random babbles

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

%d bloggers like this: