The obvious answer is 'missing key milestones', but that depends on a structured project plan with clear milestones (e.g. waterfall model).
What are some of the not-so-obvious or subtle signs that the project is going awry? What's the best-case or worst-case impact on the project?
Please give one item in your answer so we can gather them together here and people can vote accordingly. You can post more than one answer if you have several to share. Real-world examples would be helpful.
Decreasing communication between team members. People silently disagreeing with opinions of other team members, but for whatever reason don't speak their mind and subtly start to communicate only what is needed, not engaging in discussions any more and only doing work-to-rule.
This leads to situations where bad solutions can more easily start becoming part of the project, which again leads to an overhead in debugging/fixing/...
Excessive overtime. While some companies plan for overtime, and include it as a process requirement (one blatant example was EA as documented by EA_Spouse and subsequent lawsuits). Generally, crunch mode and overtime are strong indicators of poor planning and resource mismanagement. While some overtime could rescue a project marginally behind, long term overtime is the sign of a death march and can be the result of several things, most of which are mismanagement.
I strongly recommend reading the book Death March. It is a reasonably light read, but gives examples of the 4 types of death marches. Sometimes you don't mind, and indeed would willingly "sign up" for a "glorious failure" while others are going to be miserable. The term "sign up" came from The Soul of a New Machine, which was a hardware death march.
Much of our problems with time and effort estimation are due to poor skills at estimation. This is further compounded by the attitude of many management track personnel that "everything is negotiable."
Too many changing requirements, or a lack of change management. Some changes should be expected over the life of a project, but too many can be a real problem. There also needs to be some analysis around how each change is going to impact the scope, schedule, or cost of the project.
People are scared. One of my direct reports was running a software project that was on time, under budget, and in scope. My Director and VP felt everything was great. But users and customers were scared of the impending changes that were coming as a result of the new software implementation.
Cause of the failure: poor communication to stakeholders -- not understanding and diffusing fears, not managing expectations, not explaining regulations, etc.
Impact: we had some loud detractors trying to sabotage the project.
Mitigation: engaged the detractors and made them a part of the team. We communicated with them, gave them ownership in the solutions, and turned them into cheerleaders.
Progress that never changes. I'm sure we've all heard about the joke that projects quickly reach 90% complete where they stay at that status for the other 90% of the time. Any time that folks keep giving the same progress numbers should be a red flag. Either they've hit some barrier or the progress numbers were pulled out of their fanny perpendicular.
Failure to understand the objective.
An objective is composed of three understandings
Similar to the three legs of fire: air, fuel, heat. If you don't know these, you don't have an objective, and you're just rubbing sticks together, doing a lot of work, oblivious to the fact you're under water.
Tasks done in a rush. You can hit all the initial deadlines, but when you start looking back and you see that many things, that are supposed to be the base of what comes next, are not very well done I think it's time to raise an alarm and miss a deadline on purpose (i.e.: in software: code that smells).
Too Many Meetings - You know your project is not going well when the time spent in meetings exceeds the time actually spent doing something on the project. You should be even more concerned if those meetings are not yielding decisions or, worse yet, adding to scope instead of focusing.
Lack of a clear, shared, well-understood objective - if you go around everyone in the team (i.e. not the managers) and ask them what they think the next milestone is, and what it's supposed to achieve / represent, and they don't all say the same thing, then you're in trouble. Projects often unravel towards the end - processes fall down, communication ceases, and people start working blindly through a list of never-ending tasks, with no clear idea of when they're complete.
Scope Creep with no-one stopping it.
No status report for weeks.
(kind of the opposite of the reportmania mentioned earlier)
When this happens, everyone forgets about the project and the missing bits, risks, etc.
Excellent question - there are so many signs that I tend to keep in mind that it's not so much what is happening, but what has changed.
Many project suffer from little or no decision making for instance and that is a reflection of the organizational culture. The decisions eventually get made and the project carries on. If, however, you are working in a culture that has a good history of decision making and suddenly you can't get a decision on something you need, you might start looking at why the environment has changed.
Earned Value Analysis metrics are the only objective indicator of project progress, according to the PMBOK.
I think one of the clearest signs is what I call reportmania. More and more controls and reports are being established according to some motto 'the more we have written down the better we can manage the problem'. This is totally wrong in my opinion. It leads to some felt security which it is not.
Another warning sign down the ladder is many people leaving the project and/or getting fired. By then it is often too late because you can't compensate for the brain drain.
Ignoring the elephant in the room
Or: Major issues that do not get addressed (or better: they are addressed but get ignored), while the project keeps on going, eventually trying to deliver without resolving the issue.
Making promises the project can't deliver.
Talk with all possible stakeholders to make sure their input is given and understood, and agree to any reasonable request. Secretly realize that the project can never deliver all these requirements, as many are contradictive or co-dependent.
Don't talk to the stakeholders about this, hope that they will forget about it, and let the project carry-on regardless.
When the project is in danger, enough work and money will have been spend so you will have to deliver anything at all, upper management can only decide to push through, ignoring all stakeholders.
When upper management decides to cancel the project (not likely) you can always blame the stakeholders and their impossible requests.