Innovation or decay?

Blame Management (Part 2)
Undocumented, but practised processes of project management

While in Part 1 we introduced ourselves to the significance of this falsely demonised topic in society and companies, it is time now to become more concrete.

This requires a common understanding of what it is all about.

Definition of terms

The English term “blame” has also been very common in the German-speaking world for some time, but there it is increasingly used in its progressive form of “blaming”, i.e. accusing someone of something. In my opinion, we should expand the definition in the corporate environment in such a way that it better fits 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 found quickly and recognisably for everything that goes terribly wrong and is appropriately called to account.

Scope and content

Under no circumstances should you think too narrowly here. Distracting attention from oneself and assigning blame to others is a must. BM deals with the following transgressions, to be sanctioned at project level:

  • Inaccuracy in forecasting
  • Overlooking “unknown unknowns”

BM in agile projects

Essentially, BM differs only slightly in agile projects. Nevertheless, there are a few particularities. Due to the iterative approach, this process can be executed more frequently. However, it is essential to pay attention to self-organized BM. The following principles should be observed:

Line and project managers should always be protected from any responsibility whatsoever for their own actions. According to the above definition, blame is always assigned at the lowest still plausible, but politically defenceless hierarchical level.

Planning BM

If, as stated in Part 1, BM has long been a common and successful practice, then what is the point of a detailed process description? As with all other project processes, the uniqueness of a project must be taken into account. Therefore, project-specific planning of BM is indispensable. Objectives and actions must be aligned with project specifics and documented. It is therefore necessary to determine how BM is to be approached, planned, implemented and its effectiveness monitored. The following four central process groups are to be executed:

  • Preparing and identifying
  • Performing analysis
  • Developing response strategies
  • Monitoring effectivenes

Preparing and identifying blame

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

Inputs Tools &
Techniques
Outputs
Business Case Expert
Judgement
Blame
Management
Plan
Contracts Data
collection
Blame register
Rumours Meetings  
Experience from
completed projects
Blame
storming
 

Determining blame potential

Identifying blame allocation potential is the sub-process of identifying potential and existing risks, problems, and events that may require the allocation of blame. In addition, this sub-process also includes the identification of potential scapegoat candidates.

The main benefit of this sub-process is the documentation of the existing individual risks, issues and events and the assessment of the total blame potential. It also aggregates information so that the project team can react appropriately to identified options. This sub-process is executed throughout the project.

Identifying Blame Candidates

While conventional risk management knows four response strategies, blame management is limited to one, the so-called transfer.

Proactive blame management does not wait for the first, accidental occurrence of a blameable event, but tries to induce it when necessary. For this purpose, suitable blame candidates must first be identified. The following must be respected:

  • Only candidates who can credibly be made responsible and have too little political influence to protect themselves are suitable!
  • Should too few internal candidates be identified, concentrate on subcontractors. If this is not possible either, consider factors such as providence, fate, customers, government or aliens.
  • In a second round it is important to identify those who are NOT candidates. Confusion can have dramatic consequences.

This usually includes:

  • Decision makers with regard to aspects relevant to your project
  • Single office occupants, owners of reserved parking spaces, etc.
  • Individuals with good relationships to the above mentioned

Outlook for the next chapter

In the next chapter I will deal with blame analysis, including blame prioritization, selecting the correct 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!

Text: RGE
English translation: BCO

Bildquellen

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

Leave a Reply

Your email address will not be published. Required fields are marked *