Authority and Response-ability

“Both for practical reasons and for mathematically verifiable moral reasons, authority and responsibility must be equal - else a balancing takes place as surely as current flows between points of unequal potential. To permit irresponsible authority is to sow disaster; to hold a man responsible for anything he does not control is to behave with blind idiocy.” Robert Heinlein, Starship Troopers.

So what should a project manager do when authority and responsibility are not balanced?  Are they faced with disaster or idiocy?  How can they effectively deal with this situation – which often happens?

Authority and Responsibility

Authority and responsibility are terms that are often used interchangeably.  But they shouldn’t be.  They are very different.  Wise project managers understand this and watch for a situation where authority and responsibility are divided.  When they see it, they know they have uncovered a project risk.  Let’s explore the definition of each.

Authority deals with control.  It is the other side of the accountability coin.  If you have authority over something, you control it.  If you are accountable for something you must answer for what happened to it.  Authority cannot be shared.  Oh sure, you may say that you are sharing authority with someone else, but when push comes to shove, and disaster is happening; who do people turn to for the decisions?  That is the person with authority.

So what about responsibility?  Rather than control, this deals with causation.  Is this person “able” to elicit a “response?”  Do they have “response – ability?”  Can they initiate a process; start an investigation; or cause an interaction to occur?  Then they are responsible for the chain of events that happens.

But once a chain of events is started, the responsible person may not be able to make decisions and control what is happening.  They may not have the authority needed to manage the results of the response.  And by the same token, an individual may have the authority to manage the results of the response but lack the ability to initiate the response or prevent its initiation. In that situation, authority and responsibility are divided and you are just a step away from disaster or idiocy.

A Practical Example

Let’s put this on a practical project level.  In a new product development project, one of the core team members is told that they have the authority and responsibility to test the new product to be sure it is ready to release to customers.  The company wants the test finished as soon as possible so that they can begin to sell the new product.  As this individual is about to start the testing, they realize that the product given to them to test is a preliminary prototype and does not represent the final design.  In addition, the test requirements were established by the quality department and do not reflect the input from the voice of the customer. 

We will start with the case where our core team member has both authority and responsibility.  They are responsible for initiating the test sequence and the authority to determine that the product is ready for release to the customer.  In this situation they may determine that some of the testing would not be able to demonstrate that the new product is ready for release.  They initiate the tests that they believe are appropriate and that are relevant to the configuration of the prototype.  At the same time they demand a proper configuration of the product be provided and the final test requirements revised to align with customer needs.  They don’t complete the tests until those are available. 

If this individual had responsibility but no authority, they would start the test with the prototype and current test requirements.  They are responsible for testing, so they test as soon as possible.  They initiate a chain of events (tests) that yield test results.  They are not accountable for whether the product is ready for release to the customer.  They do not have authority in that area.  Doing that type of testing is idiocy.

If this individual had authority but no responsibility, they would demand a production-configuration product and a rewrite of the test requirements.  They would continue to send things back to the other departments until it is perfect (and it never is).  Nothing would be initiated.  They have authority to declare the product acceptable, but they are not responsible for ensuring the testing is done as soon as possible.  This will lead to a project disaster.

The Project Manager and Risk

Here is the problem for project managers; when they see a mismatch between authority and responsibility they can expect confusion, delays, and rework at that point.  The disaster of irresponsible authority can occur leading to delays, overruns, and massive rework.  The idiocy of holding a man responsible for something he can’t control leads to frustration, anger, and ultimately to unacceptable  and wasted effort.

It is for this reason that I believe that the RACI methodology is a very poor approach to use with a Responsibility and Accountability Matrix (RAM).  RACI separates the responsibility and accountability (i.e. authority) and often spreads it across multiple individuals.  RACI, which stands for Responsible, Accountable, Consult, and Inform, assigns these roles to individuals for each project deliverable or activity.  While the methodology allows one individual to hold multiple roles, it often leads to a separation of responsibility and authority.  

I prefer to use the acronym CRSI, Customer, Responsible, Support, and Inform.   Every deliverable or activity must have both a Customer and a Responsible person.  With this approach the person who is responsible should also have the authority needed to complete the deliverable or activity.   The Support and Inform roles are only used as needed.  This has the added value of emphasizing customer awareness and customer-centric activity on the project.

Don’t fall into the trap of separating responsibility and authority on your projects.  Avoid both idiocy and disaster.