B is for… Blamestorming

This term will likely be familiar to anyone that’s been on an IT project, it describes the point of sudden realisation that there is a problem on the project and a scapegoat is required.

Really it shouldn’t work that way, people should undoubtedly be focussing on solving the problem and delivering the project, but these days it seems that there always has to be a post-mortem and a, consequently, a culprit found.

The meeting may take a number of different forms, or have a number of different titles, like “Process Improvement Workshop”, or “Post Implementation Review”, but in essence it will turn out to be a drains up blame-fest. You can usually gauge how much of a kicking is going to be dealt out by the seniority of the attendees. There may be even a series of blamestorming meetings to get the story straight before the upper management get told the story.

As you attend more of these meetings, you will witness people who have never moved quickly in their lives suddenly acquire the speed and adaptiveness of gazelles being pursued by a cheetah and reknowned trouble-makers will become strangely slippery, as if lubricated with some kind of advanced silicone compound.

Best go prepared to these kind of meetings, because the black spot will need to be finding a home, and you’d be advised to make sure it doesn’t unfairly land on your lapel. Of course, if you are a Good Guy and have followed the advice in this guide, you will already be well equipped and have nothing to fear.

At the meetings, watch out for the phrases, “This isn’t intended to be a witch-hunt”, and, “We’re not looking for a scape-goat here”.
It is, and they are.


  1. I like your style and your topics (I’ve just read 4 of your articles). Now about the blamestorming, who, from your experience, is usually the scapegoat? Is it one of the developers, team leader, the Project Manager, or someone else? I understand it varies by project, but throughout your experience you must’ve noticed a trend…

    I have just published an article about the post implementation review, it clearly defines the structure of the PIR team as well as who should have input on the PIR and who should read the resulting report.

    Take a look, and let me know what you think, sarcasm welcome!!!

  2. Thanks! Glad you’re enjoying it! Sarcasm, moi?

    The scapegoat can be any or all of those you mention or, as the post alludes to, is often be those who have not developed the agility (excuse the pun) to get out of the way of the blame.

    As for your article. Firstly, can I say full marks for self-marketing of your site ;-). A good, factual article on the PIR, however I think your attendees list, in my experience are the minimum that would be there, it’s often many more, and for big projects, something approaching a cast of thousands.

    One other thing I would add; although it may seem obvious, is that having a PIR and resultant report is pointless unless someone is going to take action on the recommendations.

Leave a comment

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