Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

closed as too broad by MichaelT, GlenH7, Kilian Foth, Bart van Ingen Schenau, amon Aug 15 '14 at 12:14

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

    
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. – John R. Strohm Jan 20 '13 at 11:44
    
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

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
share|improve this answer

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.

share|improve this answer
    
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. – Martin Wickman 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" – MatthewMartin 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.

share|improve this answer

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.

share|improve this answer

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

Long development time without clear commitment for release.

share|improve this answer

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

  • Deadline
  • Scope
  • Allocated resources
share|improve this answer

Statistically a software project starting is a fair sign that it'll fail, as an overwhelming majority of them do...

share|improve this answer
1  
I think that's a start-up statistic, not necessarily a general software project statistic. – Erik Reppen Jan 20 '13 at 16:45
1  
Here's one reference randomly Googled which seems to suggest it's not limited to start-ups. Also see Mr. McConnel's excellent Rapid Development for further gems on the topic. – Nitsan Wakart Jan 21 '13 at 14:25

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"

share|improve this answer
    
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. – MatthewMartin 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. – Jon Hopkins 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. – Jon Hopkins Dec 10 '10 at 14:17

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