you have a project that has vague/unclear requirements

Thats where you can use some requirement analysis, sometimes it might be as simple as that a few emails or a couple of phone calls can get requirements straight

you have a project that impossible deadlines and/or budget

Thats when you sit down and work out options… alternative ways to get things done, modify features, prioritise, talk to the client

you have a project that no one wants to be part of

Thats where the challenge lies, don’t always have to think like others

You already have The Number One :
“you have a project that has vague/unclear requirements.”. This is a sure fire killer. No questions about it.

Other top one’s:

1. The Project Manager is clueless – and thinks it is unnecessary to understand anything more than the client name, and the end date. Rest are details meant for developers.

2. Ignoring the importance of Proto Typing, Proof of Concept – both a requirement and technology validator kind of thing. This simple measure alone has saved large projects from disaster.

3. Overdoing or Underdoing important aspects of the project.

Eg: Builds.
- doing builds thrice a day is a recipe for disaster.
- doing builds once a month is also a recipe for disaster.

Eg: Document Management.
- not having a SINGLE easily accessible repository of important docs.
- having the important docs in everyone’s email boxes but no central repository. hahaha.

4. Weak Leadership – Project Manager, Architect, Technical Lead.
Like in anything else – a strong leadership can carry the Mediocre. NEVER the other way round.

5. Refusal to accept the 20/80 Rule.
There will invariably be people who are more adept than others. Recognizing who these people are – and giving them the lead. It is important to differentiate positively.

Well… there are more.. but enough for now :)