The first problem with specs is that nobody writes them. Joel Spolsky says

       "Writing specs is like flossing: everyone agrees that it's a good thing, but nobody does it".
- Joel Spolsky, The Joel Test: 12 Steps to Better Code
We know developers like writing code more than specs, but the rule is developers don't code without a spec (including a release plan).

The second problem is that when people do write them, they try and spec the whole project, spending months detailing every Use Case, Business Rule and Process Flow Diagram. The client spends lots of money and sees no real progress, and the requirements change and the process begins again.

The most popular and most successful way to deliver projects is using a specific framework called Scrum. In Scrum you fix the timeframe and the cost so the only variance is in the features that are delivered in that time. You should keep your time to between 2 and 4 weeks and all your team members should be full time, thus fixing the costs.  

See Rules to better Scrum

At SSW we spec in two phases, the first to get an overview of the project, the second, to focus on the detail of first few releases only:

• Spec Review, or Initial Release Plan
• Detailed Release Plan - this phase is repeated through the project