Friday 25 March 2011

Big Bureaucracy Hides Responsibility

Do you need new -- lateral -- thinking for your own problems?
email nick leth at gmail dot com. Need solutions? No worries. Now.

I've just had a brief involvement with a rather large bureaucracy. A huge bureaucracy, in fact. And a private company.

I remember reading -- years ago, when I was a fresh and callow MBA student -- about the GM decision-making process. It was claimed that GM would take six months to reach a decision to do... nothing. A decision to actually do something would possibly take longer.

I know nothing of the decision-making process of today's bureaucracy-of-interest. But I did notice an interesting method of avoiding responsibility.

Avoiding responsibility

I was looking at processes and at project recommendations. These are documents which are either put into use, or used as the basis for further work.

These documents had lists of up to ten people who were listed -- as part of the document -- as being on the circulation list. Okay, fair enough, it's nice to know that all relevant people were consulted. It's also a great way to cover your backside: "Look, I circulated this to ten people so don't blame me if it's not right..."

But wait! There's more!

Each document also had a list of up to six people who had approved the document! Six approvers! Can you imagine what each of those people was thinking?

"It should be safe to sign off on this document. No need to read it. If it's a total stuff-up then I can always blame the other five..."

Six "approval" signatures, so no one person has to take the blame. It reminds me of the public service credo: "Better to reject nine out of ten proposals than to face the possibility that one may go wrong..."

Where am I going with all this?

If a report needs to be approved then it needs to be approved by only one person. That person takes responsibility for having checked with all other relevant parties.
That's the first message.

Missing the action

The next message is quite minor. It's for people who want to write good process documentation.
If there is a task to be done then there must be a person to do that task.
Okay, that seems ridiculous, when I read what I just wrote. Of course there must be someone to do each task! Otherwise, who does it...?!

I was looking at process charts. Diagrams which showed what must be done. Each process was broken into tasks. The charts were "swim lanes", with a column for each person or group involved in the process.

So far, so good.

There were two standard symbols in use. (There were more. Just two which are relevant to this problem.) Two symbols: One for "Takes responsibility", one for "Takes action".

There were rows -- tasks -- with a "Takes responsibility" symbol... but no-one who "Takes action"! So who will actually take action to do the task? No-one, apparently. Though someone has been designated as the person to be kicked for the task not being done...

As I wrote above, If there is a task to be done then there must be a person to do that task.

Quick reality check for people involved

For any task, there are people who will be involved. At the very least, there will be the person who does the task. But who else?

The following list is taken -- with no apology -- straight from standard project management textbooks. It applies to project tasks. It applies equally well to any process chart.

People for tasks

  • Does the work: For each task there must be at least one person or group who actually performs the task action. This is essential.
  • Manages progress: Has responsibility for the task being done. In a project, may be the project manager. May be the same person who "Does the work".
  • Confirms task completion: In a work process this may be the person doing the work, saying, "It's done." In a project this may be the Client signing off on a milestone having been attained. Occasionally, there is a valid reason for more than one person to confirm task completion... but that's a separate topic.
Those are the essential roles for any task. Then there are the optional roles: people (or groups) who may or may not be required -- but we certainly don't want to overlook them. If they are needed then they must be managed.
  • Tuition, training, mentoring: These people may only be needed if the person doing the work lacks experience. For a repetitive task they may be required only occasionally. Who can we call on to train the new people?
  • Must be consulted: Is there someone that we must ask -- talk to -- before we start the task? Perhaps someone who will provide input on the way that the task is to be performed this time? Identify them so they are not forgotten.
  • Must be informed: Is there someone who must be told when a task is about to be started? or finished? Perhaps there is a steering committee which needs to be informed of progress. Identify them -- before the task is started.
  • Available for advice: These people may not play an active part in the project or the process. But they have relevant knowledge. Identify them -- and get their agreement -- in case their advice is needed.
Now, if only I had six months to spare, I'd try to get the big bureaucracy to accept that list as a guideline for documenting their processes...

Independent thinking & independent analysis of your problems by
Agamedes Consulting. Support for your thought:
email nick leth at gmail dot com

No comments: