If you’ve spent more than a few weeks in IT, you’ve probably noticed that things don’t always go as planned. Few projects come out as initially conceived — delivered on time and within budget, with goals met and functionality complete. Some statistics suggest that close to three quarters of projects fail to meet critical benchmarks set at their outset.
Given this persistence of failure, I find it curious that projects that fall short seem to trigger strong reactions. Some of them are constructive, such as finding workarounds or regrouping and trying the project again. But many reactions are closer to suicidal, as managers go on a full-scale witch hunt to find and punish the guilty.
The hunt for the guilty is sadly common, so much so that even when no one is seeking to point fingers, many team members will carry a heavy burden of shame and scorn, entirely self-imposed. They’ve been conditioned to expect blame to be pinned on someone, so even when they find themselves working for someone who doesn’t do things that way, they can’t stop themselves from internally pointing a finger at themselves. Not only is this not necessary; it’s not really a valuable response. There are managers who think that the fear of being blamed for a failure is a great motivator, but the truth is that efforts to lay blame for a project failure have deleterious effects for both individuals and the organization as a whole.
Behind this self-flagellation are some assumptions about failures that merit examination. Here are a few:
Failures result from mistakes. Not necessarily. Things can go wrong without there being some breakdown of technology, people, process or management. Just because a project didn’t work out doesn’t mean that somewhere behind it is someone or something that is bad and wrong.
All mistakes are avoidable. Many are, but not all. A belief that bad outcomes are always avoidable assumes foresight that may or may not be possible. Even with intelligence and maturity, individuals and groups will make mistakes. With good risk management, many mistakes can be anticipated and mitigated, but not all of them can be avoided.
All mistakes are shameful. This is the most damaging assumption about failures, that if mistakes were made, then someone must be held responsible and blamed. The thinking behind this assumption is that mistakes don’t just happen; someone actively makes them, willfully or incompetently, and it is critical to identify the guilty party.
Mistakes must be punished. With this one, we move beyond identifying the guilty party to making sure that he pays the price and accepts the consequences of his mistake. The punishment may be financial, social or psychic. At work behind this assumption is the idea that if no one is punished, then everyone will feel free to make mistakes, either of commission or omission, and not just projects but the entire order of society will be at risk.
In reality, blame is rarely a functional response to failure. Once a failure has occurred, an organization should focus on reaping any possible return on the investment. Usually the best payback is to learn from the mistake, which helps ensure that it does not happen again. There may be some bits of the project process or product that can be salvaged, but the most valuable return can come from modifications to the culture of the group, not from the technical salvage.
Unfortunately, the hunt for the guilty creates a poor environment for learning. Fear tends to push out learning as defensiveness takes the place of open-mindedness, and self-preservation overwhelms conversation.
So, when faced with your next failure, monitor yourself and those around you for evidence of internalized blame. To really learn from mistakes, people must feel safe, which requires more than just being safe.
Paul Glen is a consultant who helps technical organizations improve productivity through leadership, and the author of the award-winning book Leading Geeks (Jossey-Bass, 2003). You can contact him at info@paulglen.com.
