“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.
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.