Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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
show 2 more comments

40 Answers

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
show 3 more comments

when you receive a memo that tells you to keep your desk tidy...your project is doomed

share|improve this answer
2  
@Zan: not 'tidy up your desk today' but 'keep your desk tidy from now on' –  Steven A. Lowe Dec 10 '10 at 18:46
show 1 more comment

I've been in three death marches in the last five years. Here are a few things that contributed to my gut feel of impending doom.

  • The company decides to have junior developers design and develop new features, and assigns more expensive senior developers to fix their bugs.
  • The company outsources critical software components to third-world companies that don't have the required domain expertise.
  • The crunch-time cycles come so close together that peoples' health is breaking down.
  • The pills your team lead takes to drug himself to sleep every night quit working.
  • The client sends change orders faster than you can analyze them.
  • You're supposed to deliver several years' work in a few weeks, but management refuses to do a feature freeze.
  • Your hardware suppliers are clearly having trouble delivering a workable product on schedule, and the decision-makers in your company won't consider any alternatives.
  • The prototype devices developers need so they have a ghost of a chance of meeting the probably-unrealistic schedule are taken away and given to top execs to make them feel good.
  • Week one: "Oh, crap, the code is buggy. Everybody quit doing new features and fix bugs." Week two: "Oh, crap, we're not going to meet the feature schedule. Everybody quit fixing bugs and write new features." Repeat indefinitely.
  • The development is done in one country, and QA is all done in another country half-way around the world, so a round-trip communication about a bug always requires 24 hours, and at least one of the people involved is discussing complicated technical problems in a language they're not proficient in.
share|improve this answer
show 1 more comment

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
add comment

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."

share|improve this answer
show 1 more comment

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
add comment

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

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

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
add comment

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

share|improve this answer
show 2 more comments

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
show 4 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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