Having worked on a failed project is one of the few things that most programmers have in common, regardless of language used, industry or experience.

These projects can be great learning experiences, soul-crushing disasters (or both!), and can occur for a multitude of reasons:

  • upper management change of heart
  • under-skilled / under-resourced team
  • emergence of superior competitor during dev cycle
  • over/under management

Once you've worked on a couple of such projects, is it possible to recognise at an early stage exactly when a project is doomed to fail?

For me, a big sign is having a hard & fast external deadline combined with feature creep. I've seen projects which were well planned out and proceeding right on schedule go horribly off the rails once the late feature requests started to roll in and get added to the final "deliverable". The proposers of these requests earned the nickname of Columbo, due to rarely leaving the room without asking for "just one more thing".

What are the warning signs you look out for that set off the alarm bells of impending doom in your head?

  • Robert Glass wrote "Universal Elixir and Other Computing Projects Which Failed". Published in 1977, the book was a collection of columns he'd written earlier, each one looking at a project that failed, looking for the reasons behind the failure. The book makes an EXCELLENT list of warning signs. Jan 20, 2013 at 11:44
  • 1
    Two articles - Project pathology and (the over hyped) Chaos Report. Give Death March a good read if you are after a book.
    – user40980
    Jan 21, 2013 at 3:12

38 Answers 38


See this succinct article: When IT Projects Go Right.

An absence of any of the elements stated in the article should set alarm bells ringing:

So make sure your project has all of the following, if not then you should be concerned:

(to quote the above article:)

  1. "The first is that they are based on a clear vision of what is to be achieved."

  2. "The second characteristic concerns the support and commitment of the different parties involved across the business, especially senior management."

  3. "Third is an understanding of the problems to be tackled."

  4. "The final common characteristic is that sufficient resources and skills have been made available."

  • Great article! I like the "when things go right" approach.
    – user8865
    Dec 29, 2010 at 17:21

There are loads of symptoms (burn out, overtime, frustration, silence ...) but ultimately you know this is happening when release dates are starting to slip and you are no longer able to deliver the product as often as you are supposed to.

  • In agile practices we try to focus on incremental development rather than on deadlines. How does an agile organization define "as often as you are supposed to"?
    – dblock
    Dec 10, 2010 at 13:23
  • @dblock: One cornerstone of agile (Scrum and XP) is that you are supposed to be able to release at the end of each iteration. There is your "definition" for agile projects. Dec 10, 2010 at 14:08
  • I thought agile scheduling meant every x weeks, like every 1 or 2 weeks--the stuff that didn't get done in 2 weeks just remains in the backlog. Non-agile scheduling means "I think this feature will be perfectly done after 3400 man hours, so we ship on April 1" Dec 10, 2010 at 14:11

The last professional project I worked on failed. One of the reasons I think it failed is a combination of all the other answers(especially no written spec). But I think the primary cause is a lack of decision making.

I was a primary developer and I'd ask my manager how he wanted some feature to work. His answer being "we need to collect more information from potential customers". So I worked on a different area of the project. Eventually it got to where I was rewriting components to be more clean because every other area of the project relied on unmade decisions. Near the end I began to make decisions myself. I was layed off due to the project being trashed about a month after I started making decisions.

I'll summarize a few things to watch out for:

  1. No written specification
  2. No decisions being made, or if they were being made they were only phrased like "we'll do it this way and reimplement it later the correct way"
  3. Several missed deadlines
  4. Inexperienced or understaffed team (This project was the first time I used .Net, and yet I was a primary developer!)
  5. Having to work in areas already complete because other areas need decisions made before work can begin. (of course, I'm talking refactoring for weeks just to stay busy)
  6. The idea that some new tool will shave off months of development time

Well, the best way to answer this is with an example:

Bob starts a project by coming up with a genius idea. He begins by creating a plan for the software project that begins with specific steps that need to be completed. However, the steps do not lead to the end-result, but only go a portion of the way there.

In the end, the project fails because the plans were incomplete. It's not so much lack of planning as it is insufficient planning.


A project, and future projects are doomed when the company decides to write an in-house "framework" because all the available frameworks don't fit their need perfectly.


Projects that are kind of ready for production, but features keep being added.

Long development time without clear commitment for release.


When management has decided, and does not provide room for adjustment, in all of the following:

  • Deadline
  • Scope
  • Allocated resources

Among another signals, there is one important warning for me (maybe I'm wrong, and it is not common): double-digits in the minor version like "superproject version 3.16"

  • That depends on the rest of the story. If you have to move code through a change control committee, going from 3.0 to 4.0 means "challenge me on this release, it's a big change!", but 3.15 to 3.16 means "don't bother me, this change is small enough for you to ignore" And sometimes it's nice to be ignored by a change control committee. Dec 10, 2010 at 14:08
  • That depends on your versioning procedure. We've got a version 4.0.11 and it's not an issue, it's just a reflection of multiple minor changes and bug fixes over time. We wouldn't move to 4.1.x until there was a significant new feature in that code. Dec 10, 2010 at 14:10
  • @Jon but if you have 3.1, 3.1.1, 3.2, 3.3, ... 3.16 it probably means that you have spent more than a year and haven't produced nothing major
    – duros
    Dec 10, 2010 at 14:13
  • On that branch for that product for that client that's possible and not an issue. We have a lot of clients and many don't want major release more than every 12 - 18 months. Dec 10, 2010 at 14:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.