Failure Repeats Itself


We all know why projects fail, right? The people involved don't communicate well enough. No one's come up with a backup plan for when things go wrong. The goals are glorious, but the means to reach them—time, money—are meager.

The reasons for project failures might be so much I.T. motherhood and apple pie, but maybe we should review them anyway. CompTIA, the Computer Technology Industry Association, did a Web poll recently of 1,000 technology professionals about what causes projects to fail. The factors above made CompTIA's list, along with stuff like lack of buy-in (which 6.7% of respondents selected) and poor project requirements (cited by 9.8%).

So if we know all this already, I wonder, why do we keep failing? Seems like every person on the planet has to have these lessons personally taught to him before they sink in. And even then, the lessons learned must spontaneously combust after a short period, because we all know people who make the same mistakes again and again.

Maybe the key is to review failure factors again and again, when lists like CompTIA's come out. Eric Lundquist at sister publication eWeek has some good thoughts on the topic. And here's a good primer, from Coley Consulting, and another from Harvard Business Review.

Pass the apple pie.


2 Comments for "Failure Repeats Itself"

  • Yonah Wolf March 19, 2007 1:30 pm

    Interestingly enough, none of these reasons cracked the 10% barrier, which leads me to believe that either a) this poll has flaws or b) there is no one factor that truly determines the success or failure of a software project. Personally, I think that the real problem that software projects fail, can be attributed to our perception of software projects in general. We tend to approach software projects as a sealed box, with definitive specifications, definitive UI and architectures, and a specific start and end date. But reality (at least as dictated by my own experience) shows that software is infinite. No matter how many Gantt charts I create, there are always wrinkles in some element of the project that effect deliverables and measurement. Concepts like Agile Software and the like are tending to alter that course, simply because we know that nothing really ever gets finished.

  • theObserver March 13, 2007 7:48 pm

    Primary reasons are the incorrect profile of personnel for the project needs. Ambitious goals that the sponsor does not understand and does not have the will to support to completion. Lack of taking the appropriate amount of time on preliminary task and then paying all of the supposed time that was saved in untangling the mess that was created. A restricted understanding on assessing the quality of deliverables as it relates to the various phases of architecture and design, development and ultimately to deployment. Often a few critical basic processes can save a tremendous amount of time downstream and result in predictable capability to the client

Leave a Comment