Another thing I am seeing more of that requires some comment is poor requirements definition and specs for technical work.

An obvious benefit of a development team working to correct and complete specs is the output can be measured against the spec to give the project a logical and objective conclusion.

The other side of this is a healthy spec & requirements sesssion incourages the stakeholders in the project to actually think through their requirements.  Lesson: Don't take this for granted.

I've just seen a couple of notable examples of this lately when questioning a minor point in the spec has had the client say "Ah!  I didn't think about that!" raising more fundamental questions about the project.

I'm working on a throey that you can never ask the average guy what they want, because by virtue of being in the middle of their own business domain they are blinded to actually knowning the right answer.  You can only learn what they need.

After blog mint [?]:  Just more on that "ah!" moment.  I'm not saying it's a failing on the stakeholder's part.  It's natural and healthy part of requirements definition.  Just don't forget that it can (and will) happen.