Who Is Accountable?

Why is this so difficult to get? Accountability is normally not fully understood and I’ve found in many cases this continues to be the situation for not having adequate accountabilities for project objectives and outcomes. There tends to be a misunderstanding between the terms accountability and responsibility.

This is the third blog by Mat-Thys in the series “Managing Projects: The Forgotten Art Of Influencing People To Get Results”

There tends to be a misunderstanding between the terms accountability and responsibility.

Definition

The general rule in project management is that someone has to do the job and someone is accountable for that job. It could be the same person or two different people. So, responsibility is all about who is supposed to perform the task or job, whereas accountability is the one person that would assume final and prime responsibility for that task. The “buck stops” with the person who has accountability and a project team should do everything in their power to ensure that all the project accountabilities are vested with the “internal company team.”

I once worked with a team responsible (note I am not saying accountable) for the successful execution of 85 projects, which were all running over budget and time. When we got involved to help them “rescue” this situation accountability was the first thing we noticed that needed to be corrected. Nobody on the internal company team was accountable for any of the 85 projects. The staff were basically coordinators and communicators on behalf of the vendors. They kept each vendor accountable for their respective projects or sub-projects, which created a nightmare and which was totally wrong.

Ultimate Accountability

Today project staff are trained in the RACI model and that is good, but again the deficiency comes with the interpretation of what accountability means. According to the definition offered by ITIL, accountability means someone who has the authority to reject or approve an activity or task and that is what I have a problem with. Who is ultimately accountable for the successful completion of that activity or task?

The RACI Model

Responsible – Person working on the activity
Accountable – Person with decision authority
Consulted – Stakeholder who should be included in the decision or work activity
Informed – Person who needs to know of the decision of action

The closest the RACI model gets to answering the question is to look at the responsible person. Again, according to the ITIL definition, the responsible person is the one who is responsible for actually doing it and not the one that is accountable for it. I think that is the gap and I am not trying to lay blame anywhere, but what I am trying to demonstrate here is that there is some confusion about the requirement in or around accountability. That is what I’ve found in the project world out there.

Let Common Sense Prevail

I want to make a suggestion that we need to let common sense prevail and use the RACI model in a way that would stop all possible reasons for having a project fail. I suggest the following: Call it what you want or do what your organization is used to but make sure to cover the Roles and Responsibilities by using keywords in a RACI matrix by being more specific. It worked handsomely for me over the years by ensuring the following:

  • Indicate who is the approver. You cannot use an “A” for that, so use the key word “approve.”
  • Use the “A” for accountability, but educate your staff that this means accountable for the ultimate success or failure – no exceptions!
  • Use the “R” for responsible and meaning who is to perform the task or do the job – you can have more than one responsible person. Even better, why don’t you use keywords to more specifically describe the actual task such as; make a recommendation, do research, conduct interviews, and other similar short descriptions?
  • Use the rest as you are used to, but if something is important enough to be noted please go ahead and use your common sense and use your own short descriptions. This will aid clarification rather than cause confusion.

“It’s not that they can’t see the solution. They can’t see the problem.” – G.K. Chesterton

When we explained these definitions to the team with the 85 projects, they implemented a new RACI and within six months they “plugged the leaks” in the system. All the new projects were running much more effectively and some even started to track within their budget and time constraints.

Learn More About KEPNERandFOURIE®

This blog and this entire series of blogs were first published by Thinking Dimensions Global.

Mat-Thys Fourie
"I believe that Management would like to see their staff as skilled problem solvers, solving and restoring service issues/incidents 'first time every time', reducing company Mean Time to Restore and Mean Time To Repair cycles. This is done by providing staff with repeatable tools/templates and worked situational questions to stay on the path through organizational difficulties and barriers towards restoration and successful recovery." Dr. Matthys Fourie is a Professional Problem Solver as accredited by the Institute of Professional Problem Solvers (IPPS). He is an author of several books on Root Cause Analysis, Project Management, Problem Solving and is the co-author of the KEPNERandFOURIE® Thinking methodologies. He has over 31 years of Problem Solving and Decision Making experience helping organizations across the world solve some of their most vexing and seemingly unsolvable problems. He has worked across a wide spectrum of industries from Automotive, Financial, Manufacturing, Medical Devices, Pharmaceutical, Nuclear, Insurance, Airline, Technology, and Telecommunications. He has work in companies such as Macquarie Group, SASOL, Unisys, SITA, Barclays, RBS, NCS, Singapore Stock Exchange, BMW, VW, Cadbury Schweppes, Westpac, National Australia Bank, Department of Education NSW Australia, Kimberly-Clark, Hollister, Stihl Inc. and the U.S. Navy.