Undocumented but everyday processes of project management: Blame Management

Whereas in Part 1 we dedicated an introductory section to the significance of this falsely so demonised topic in society and companies, we need to address its practical application. To do so, it is imperative to establish a uniform understanding of its essence.

Definition

The English term "blame" has also been very common in the German-speaking world for some time, although there it is increasingly used in its progressive form "blaming", i.e. recrimination. In the corporate environment, I think we should expand the definition so that it fits better with actual practices:

"Assigning responsibility for negative events or circumstances to the lowest still plausible but politically most defenceless hierarchical level."

Purpose

Blame management (BM) ensures that a politically acceptable scapegoat is swiftly and recognisably found for anything that goes horribly wrong and is held appropriately accountable.

Scope and content

Under no circumstances should one think too narrowly here. Diverting attention from oneself and blaming others is an essential part of this. BM deals with the following misconduct, which must be sanctioned at the project level:

• Inaccuracy in predicting the future
• Overlooking "unknown unknowns

BM in agile projects

In essence, BM in agile projects differs little. Nevertheless, there are a few peculiarities. The iterative approach permits a more frequent application of the process. However, it is essential to pay attention to self-organised BM. The following principles should be observed:

• Line and project managers should always be protected from any responsibility for their own actions.
• Blame - according to the above definition - is always assigned at the lowest hierarchical level, which is still plausible but politically most defenceless.

Planning BM

If, as claimed in Part 1, BM has long been common and successful practice, what is the need for a detailed process description? As with all other project processes, the uniqueness of a project should be taken into account. Project-specific planning of BM is therefore required. Objectives and actions must be aligned with the specifics of the project and documented accordingly. It is therefore necessary to determine how BM should be tackled, planned, executed and its effectiveness monitored. The following four central process groups are to be performed:

1. prepare and identify

2. perform analysis

3. develop response strategies

4. monitor effectiveness

Prepare and identify blame

The main benefit of this process is to ensure that the extent, nature and presence of blame management is appropriate to the importance of the project.

Identifying blame potential

Identifying blame potential is the sub-process involving identifying potential and existing risks, problems and events that may require blame to be assigned. In addition, this sub-process also includes the identification of potential scapegoats.

The main benefit of this sub-process is the documentation of existing individual risks, problems and events and the assessment of the overall potential for blame. It also brings together information so that the project team can respond appropriately to identified options. This sub-process is carried out throughout the project.

Identifying blame candidates

While classical risk management has four response strategies, blame management is limited to one, called transfer.

Proactive blame management does not wait for the first, random occurrence of an blameable event, but tries to bring it about when necessary. To do this, suitable scapegoats must first be identified. In doing so, the following must be taken into account:

• Only candidates who can credibly be held responsible and who have too little political influence to protect themselves are suitable!
• If too few internal candidates can be found, concentrate on sub-contractors.
• If that is not possible either, try factors such as providence, fate, clients, the government or extra-terrestrials.

In a second round, identify those who  CANNOT be considered candidates. Mistaken identities can have dramatic consequences.

These usually include:

• Decision-makers regarding - aspects relevant to the project
• One person office occupiers, owners of reserved parking spaces, etc.
• Individuals with good relations to the above

Outlook for the next chapter

In the next chapter I will deal with blame analysis, including blame prioritisation, the selection of the right blame events and blame monitoring. Until then, you will have the opportunity to apply the planning and identification processes described above.

Your Harlequin from Lake Zurich wishes you every success!

Picture sources

- pixelio. de © Gerhardtrn: Dr. Klaus-Uwe Gerhardt / pixelio.de