What are signs that a project might turn out bad? [duplicate]

Question

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.

Answer 1

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

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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

Answer 12

The project owner is the marketing group