There is a delightful book titled "Mistakes Were Made (but not by me)" that speaks to a phenomenon that seems to affect most of us when it comes to rationalizing why things go wrong. In the book the authors expand on a condition that social psychologists call cognitive dissonance to explain "Why We Justify Foolish Beliefs, Bad Decisions, and Hurtful Acts" ... which, by the way, is the subtitle of the book. If you haven't encountered the term before, in a nutshell cognitive dissonance is the inner conflict we feel when we try to embrace two or more conflicting thoughts, ideas, or beliefs simultaneously. According to the experts, we attempt to resolve this inner conflict by justifying, denying, and/or blaming something or someone else.
I believe the games we play to eliminate cognitive dissonance have a lot to do with perpetuating the failure to identify root causes for why projects continue to overrun their schedules. But there is another phenomenon called attribution error that adds to the problem. Individuals are guilty of committing an attribution error when they overemphasize personal characteristics and underemphasize situational factors when explaining why other people make mistakes ... and just the opposite when they themselves make mistakes. As a result, most individuals tend to take more credit than they are due when things go right and to blame others more than the latter deserve when things go wrong.I have witnessed both of these phenomena in action many times throughout my career. They pose a special challenge to consultants, like myself, who are in the business of helping clients recognize the need for and implement change initiatives. Though I will be the first to admit that I am not immune from either condition, the point I wish to make here has nothing to do with my personal shortcomings and everything to do with breaking the cycle of blame that perpetuates overruns in project schedules ... overruns that currently average 84% in the case of software development projects. In other words, these projects, on average, are taking almost twice as long to complete than originally planned. With the rate of change of technology being what it is, there is little wonder why a large percentage of these are considered to be functionally obsolete by the time they are delivered.
Of course, anyone can play the "who to blame for late projects" game. But the blame game that pits managers against individual contributors is especially detrimental to the goal of identifying and eliminating the root causes of late projects. More often than not, it results in a stalemate (or truce, if you prefer) where little if anything happens to change the status quo. The finger pointing that goes on between managers and individual contributors can be seen (directly or indirectly) in the following lists of commonly stated reasons for late projects.
Who or What Is To Blame for Late Projects?
- Unrealistic schedules to begin with
- Lack of management support
- Changing requirements
- Resource robbing (taking key players off the project)
- Outside interference
Managers say ...
- Lack of user involvement
- Poor time management by the project team members
- Developer gold-platting (i.e., design over-kill)
- Lack of executive support
There is often a modicum of truth in each of these. Nevertheless, at best only minor improvement in reducing schedule overruns will be accomplished as long as the finger pointing is allowed to persist. I submit that breaking the cycle of finger pointing that perpetuates this condition is a key responsibility of a genuine and effective project leader.
No comments:
Post a Comment