Skip to main content

Why, Oh Why, Do Projects Fail?

Article

Why, Oh Why, Do Projects Fail?

Article by Naomi Karten | Comments: (2) | Wed, 07/18/2012 - 3:19pm
Summary:

Software projects fail. Not all of them, fortunately, but the statistics are hardly reassuring. According to one recent study, for example, 70 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!

 

Software projects fail. Not all of them, fortunately, but the statistics are hardly reassuring. According to one recent study, for example, 70 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.

About The Author: Naomi Karten

Naomi Karten is a highly experienced speaker and seminar leader who draws from her psychology and IT backgrounds to help organizations improve customer satisfaction, manage change, and strengthen teamwork. She has delivered seminars and keynotes to more than 100,000 people internationally. Naomi's newest books are Presentation Skills for Technical Professionals and Changing How You Manage and Communicate Change. Her other books and ebooks include Managing Expectations, Communication Gaps and How to Close Them, and How to Survive, Excel and Advance as an Introvert. Readers have described her newsletter, Perceptions & Realities, as lively, informative, and a breath of fresh air. She is a regular columnist for StickyMinds.com. When not working, Naomi's passion is skiing deep powder. Contact her at naomi@nkarten.com or via her Web site, www.nkarten.com.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

#1

Another reason projects fail

Project failure statistics are usually about projects that don't meet "schedule, budget and quality goals".

But how many of these projects were actually set up for failure with unrealistic schedules and budgets? How many of them started late?

I've managed testing on several projects that were "late" from day 1, and "over-budget" not long after they started. Whether the unrealistic schedules and budgets came from some manager's fantasy "stretch goals" or from senior management's refusal to believe how much software actually costs to develop, these projects never had a chance of meeting their targets.

Many of them succeeded, though, by producing software that met its stakeholders needs and helped them do their jobs.

Maybe that's a better basis on which to assess project success or failure. Did we develop something people actually wanted and used?

#2

Another reason projects fail

Fiona, good point! I too have seen projects in which the start was delayed to the point where it couldn't reasonably be expected to be completed "on time." Also, projects that were underfunded from the get-go, so of course the only way to complete them was to go over-budget..

Even more important is your point that many projects succeed anyway. There's less written about projects that succeed than projects that "fail," especially when many manage to succeed despite all the factors (and people) that conspire to hobble them. Maybe that's a good topic for your next post (or mine): that a better basis on which to assess project success is whether you developed something people actually want and use.

~Naomi