Just remember that every time you point your finger at someone there are three fingers pointing right back at you. The blame game can be seen in most organizations that struggle with projects. The blame game is something that we play as children and some master in as adults. In order for projects to be successful this game needs to be obliterated, truth of the matter is, the blame game may always exist. Let’s face it, if a project starts falling behind and/or gets into a crisis situation, members of the team will start looking for someone to blame. At some point in time the crisis will become visible to the powers that be and they will want answers. I am sure that at some point in time many of us have seen this happen.
I would like to look at the blame game from a couple of angles. The first example is the blame game in an environment without a good Project Management Methodology in place. More than likely project scope is mismanaged, documentation is poor or non existent, no change control procedures and on and on. Keep in mind these are just a couple of examples, there could be countless other examples to use for reference.
Here is something likely to occur, I told him (her) what I wanted and what I got is not what I asked for. Without a scope document to refer to you will end up in a finger pointing game and team members disgruntled with each other. You may have to take someones word for it or just take the extra time, money and effort to fix it. This activity prevents other projects from beginning and has a negative impact on the corporate financials. Think about this for a minute, do these parties want to work on future projects together after this experience? What does this do to the moral of the team? What impact does moral have on the success of your business?
Let’s look at another example in an environment where a good Project Management Methodology exists.
Biz Unit Manager: I told him (her) what I wanted and what I got is not what I wanted.
PMO Manager: Well let’s take a look at the scope documentation and use cases. What specifically is it that you wanted that you did not get?
Biz Unit Manager: I wanted the data to get entered into the XYZ database so it could be analyzed by the diamond reports application and not impact production during business hours.
PMO Manager: OK, where is that stated in the project scope?
Biz Unit Manager: Well, it’s not.
PMO Manager: Are there any use cases to reference?
Biz Unit Manager: No, there’s not, but I asked Joe Devmaster for it.
PMO Manager: Did you provide the information in a change control request?
Biz Unit Manager: No, I didn’t have time.
PMO Manager: Well, Looks like Joe didn’t have time to remember it either. Let’s get the change request made and properly approved so Joe can work on this. Do you realize that this extra work may cost $5,000 and will impact the start date of your next project?
… Thus begins another conversation.
Do you see the difference in these examples? Can you think of examples in your own environment of the blame game? If the protocol of the PM Methodology was followed in the second example some items could have been addressed and managed earlier in the process and the project could have run a lot smoother. One question I have is, what does your company do with staff members that thrive on the blame game and continuously wreak havoc on corporate projects?
There are several levels of how the blame game is played in various organizations. If a good PM Methodology is in place and effectively utilized, many projects will run smoother. Without effectively utilizing a PM Methodology projects will be managed in chaos and relationships and moral will deteriorate. The cost to this is turnover and loss of expertise. Can you afford that in any economic time? It may be something to think about.
