While everything should be done to avoid project failure, it does occur. When it does, management and the team must look into why a project failed, to avoid repeating mistakes in the future. Failure must be more than simply accepted or allowed. It also needs to be closely analyzed.
Software projects fail. Not all of them, fortunately, but the statistics are hardly reassuring. According to one recent study, for example, seventy percent of organizations surveyed had suffered at least one project failure in the prior twelve months! In another, only 40 percent of projects met schedule, budget and quality goals. And the annual cost of these failures is in the trillions!
The list of possible reasons for project failure could fill a book. One major reason, according to Brent Flint, is simple: The projects are harder. In addition to budget and resource constraints and technology challenges, projects face shifting business demands, demanding stakeholders, and the list goes on and on.
But, that’s not all. Michael Krigsman sees management as being at fault for failing to anticipate serious problems and too often considering failure as “business as usual.” Managers, in his view, “possess too little experience, hire the wrong people, ignore warning signs and, crucially, fail to involve affected employees in a way that eases the path to success.” Senior executives, according to Krigsman, also bear some of the blame for allowing the conditions for failure to exist in the first place, particularly as they relate to mismatched expectations, conflicts of interest among key constituents, and organizational structures that increase the odds of failure.
A Fast Company article offers a different take on the blame issue, emphasizing the role of the fundamental attribution error, a cognitive bias that comes into play in project failure. That is, when projects fail, it’s easier to target a person as the reason. But, if the underlying system isn’t designed for success, it won’t matter who’s running the project. The article describes systems thinking as a way to move beyond the blame game and find out what really happened. This entails examining such variables as competing work priorities, problems with resource planning, and the absence of a well-designed communications and training plan.
As this article points out:
Figuring out where a project went wrong hinges on your understanding of the underlying dynamics; the beauty of systems thinking is that it allows you to examine beyond surface causes and dive straight to the root of the problems. Intuition alone won’t deliver you to those conclusions. By systematically outlining the various potential feedback loops of your working system, this approach yields invaluable counter intuition that can salvage your current project, or guarantee that your next one will be a success.
Is there any hope for future projects? Stay tuned for next year’s report.
