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 '13 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 '13 at 3:12

38 Answers 38


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.

Good, that's a relief!

I think not having daily, helpful management oversight is key to spotting creep. I believe that if you have the right information, if you get your devs to input the right information, then you can spot slippage quite quickly. What you do with it after that - well that's more politics and less dev...


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

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 '10 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 '10 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 '10 at 14:11

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 '10 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 '10 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 '10 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 '10 at 14:17

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