Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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

Possible Duplicate:
What are the warning signs of impending doom to watch out for on a project?

What signs have you seen that can indicate a project to turn bad or sour early-on?

Why were these signs bad? How can one avoid/correct them?

Feel free to accompany your answer with articles that talk about such deficiencies.

share|improve this question

marked as duplicate by David Thornley, Aaronaught, JohnFx, Walter, Mark Trapp Jul 20 '11 at 18:32

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Read "The Universal Elixir, and Other Computing Projects Which Failed", by Robert Glass. It contains a huge selection of stories of projects that failed, and why. – John R. Strohm Oct 2 '10 at 14:19
No, it's not a duplicate... That question is not constructive. My question is about experience and also asks for avoidance, I don't see those things in the question you linked... Perhaps the title here must be changed? – Tom Wijsman Oct 3 '10 at 16:08
Usually my presence on the dev team is a pretty good indicator of trouble ;-) – Throwback1986 Jul 19 '11 at 20:20
The project owner is the marketing group – Matt Jul 20 '11 at 1:59

10 Answers 10

up vote 13 down vote accepted

There are sooooooooo many factors, it's impossible to answer it properly.

Read Death March, it's a book on the subject.

However, I've observed two causes that tend to appear in most failures (they are both linked):

Internal company politics

The large the company is, the most affected you will be. Most people working in large enterprise are encouraged to move up the career ladder. Project success may not be the way to do that. In fact, if there is two project managers that are likely to take a higher rank, one will be tempted to make everything necessary to make the project of the other fail. In smaller enterprise, you have shareholders conflicts. You take decisions based on personnal interests instead of project interest. And so on.. this is infinite!

Bad management

Since developers don't like the idea to become managers, most of the people that drive a project simply doesn't understand developing a software is different. On the other hand, some developers with poor social skills want to be a manager and fail too. Become managing people is not writing code...

They try to manage it like what they did in their previous experience (not software related or how they usually write code for the others) and then fail... Most of them don't learn from their mistake, so they try offshore instead, but that's worse! Then they usually repeat once before giving up to another fresh manager that think he will succeed... applying the same management methods ;)

I've found some solution in those problems in Agile. But nothing can replace an highly skilled team. With the dream team, you can most of the time go trought most of the problems explained above. A lot of chance can be also involved...

share|improve this answer
Yes, there would be a bunch of them... That's why I ask about experience of them, the best experiences would then be voted up and can be used to learn from. Indeed, a book could help too and I'll keep it in mind, but I would love to see the experience of the community... Thank you for your two causes anyhow! :-) – Tom Wijsman Oct 2 '10 at 11:31
I will elaborate later if you want. I promise. Now I have to leave. – user2567 Oct 2 '10 at 11:42
As promised.... – user2567 Oct 2 '10 at 13:27

Pierre already said that there are many signs indicating future problems with a project. From my personal experience a few are:

  • No spec or a faulty/incomplete spec for which no one claims responsibility. This means many - if not most - features will end up in the product undocumented and no real thought will be given to their design. You will also most likely get emails out of the blue along the lines of "hey, can you just add [stuff] to your code? it should look like [half-assed mockup]. that should be easy for you. thanks!"

  • No schedule at all or an irregularly updated schedule, e.g. only once per month. Seriously. Either that or management decides - without asking you - that your component/screen/project/whatever is done and tested in 4 weeks. Or you're presented a list of 10 features you've never seen before and asked to come up with a good guess on when you could finish them on the spot.

  • No thought given to testing or to make the project compatible with automated tests. How do you expect to finish a project successfully when nobody has the slightest clue on who should do testing when and how? Perhaps management thinks that testing equals three consultants clicking around in the GUI for a couple of weeks. Even worse when the prohibition of automated tests means lots of repetitive unnecessary work for both devs and testers.

  • No good tool support and lots of bad practices. Your boss tells you to do bugtracking with Excel and Outlook. Your boss tells you to not do automated tests. Your boss tells you that daily builds "just won't happen at this company!" Your boss tells you to not "waste your time with documentation." Several programmers are sharing the same (non-volume) license key for the IDE/a certain important tool.

share|improve this answer

Estimates are done by management and are based upon getting the job/contract.

share|improve this answer
An Agile development methodology would be able to work with this - fixed budget/timeframe, so just do as much as can be done. – JBRWilkinson Oct 4 '10 at 22:28
That is my point. When as much as can be done is not an option, it has to all be done based upon a timeline decided by someone with no real insight into how long it will take. – Craig Oct 4 '10 at 23:29
As a corollary to this: Management asks technical team for estimates, then tries to negotiate with them to reduce the estimates. – JohnFx Jul 19 '11 at 23:45

The user begins implementing "Scope Creep" within the first day of Design.

Nothing worse than the user coming to you the day you start designing and asking if you can include somehting that wasn't in the original layout.

share|improve this answer
yes there is, coming to you the day before the deliverable and asking for something that wasn't in the original design – Jarrod Roberson Jul 20 '11 at 18:23
I believe you are correct. I would rather have time to include what they will inevitably expect to have included than find out day of or day before that they expect it and have to jump through some major hoops to include it! Good thought. – Michael Eakins Jul 21 '11 at 12:02
scope creep is inevitable and should be planned for as part of the process, water fall doesn't work, never has. SCRUM and other agile methodologies build this in-decision and lack of clarity into the process, making it a strength instead of a weakness. – Jarrod Roberson Jul 21 '11 at 17:55

Bad relationships = doom:

  • Team members don't communicate with each other.
  • Management doesn't have open communication with team.
  • Management communicates conflicting priorities and will not resolve them.
  • Business/client doesn't have open communication with team.
  • Team members don't get along.
share|improve this answer
+1: Great stuff. It sounds like you've lived through this. I know that I have, and before I did, I had no idea that management could be so ignorant of these principles. – Jim G. Jul 20 '11 at 2:01
  1. When the deliverable date is set before the project is even started!
  2. When the deliverable is specified in a multi-hundred page document with no input from technical staff and the deliverable date is before the project is even started.
  3. When there are any delivery milestones more than 2 weeks out and the dates are set before the project is even started.
  4. When effort estimates are not set by the people actually implementing the software and the deliverable date is set before the project is even started.
  5. Success and Failure criteria is based on deliverable dates and not customer satisfaction.
  6. There is a pattern here ...
share|improve this answer

Just some that I've experienced:

  • Time allocated in the plan for testing in reality is just slack for when the coding runs late. Everybody knows that there won't really be any proper testing.
  • Technology decisions are guided by overly influential vendors.
  • Technology decisions are based on what the technical people want to learn, meaning immature technology is used rather than the safe, boring option.
  • People are allocated to the project to meet some headcount target rather than because they provide necessary skills. This leads to the double whammy of non/negative-contributing team members and skills shortages.
  • The unrealistic deadline depends on everything going more smoothly than any software project in history.
share|improve this answer

Steve McConnell's "Software Project Survival Guide" has an excellent list of success factors in chapter 1. You go through the list allocating points based on how true each statement is & the number at the end tells you how doomed the project is. The remaining chapters (plus its' predecessor "Rapid Development") tell you how to fix it.

share|improve this answer

IT Project Failures and Software Project Failure may have some answers as well as sources just in case someone wants something to back up a claim about failures.

Coding Horror:The Long, Dismal History of Software Project Failure is a blog post from Jeff Atwood on the subject as another resource.

share|improve this answer
  • Vague requirements that lead to scope creep. User says they want something, but it's not definite. Then they later change their mind.
  • Beyond aggressive schedule. Management wants to win the project so they place a low bid without taking into consideration their existing assets (engineers). If they say it will take 3 months to do something that usually takes 6 you're looking for trouble.
  • Big hiring spree of low level engineers. Management thinks they can save money by having a bunch of Jr Devs led by very few Senior Engineers. Thinking if they UML their solution perfectly then any code-monkey can code it out.
  • Bad interviewing practices when going through said hiring spree. You wind up with sub-par people that can't meet the schedule that was never going to be met anyway.
  • Mandatory over-time early out of the gate.

These are things I've seen in the past.

share|improve this answer

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