over specifying functionality
Something I've seen many a times when developing or managing a project is that a big danger is over specifying functionality.
Developing a spec is something that takes a lot of time, and it removes a lot of the flexibility needed for delivering a successful project.
Don't get me wrong, a spec is definitely needed, but it must be flexible. It's almost impossible to cater for everything in a spec, so if you rely only on the spec, problems will occur, and your whole project plan will be no good.
You need a spec for communication with the client, but I've never seen a project where a spec was fully sufficient in alleviating scope creep. So instead of trying to prevent any scope creep from occurring and alienating your client, you should try to use alternative methods to accommodate the scope creep.
A nice way of saving time on mammoth specifications which is open for interpretation problems, you should spend some of the time to set up a list of testing procedures which will prove that the functionality is hitting the target. And you need to be flexible in this. It's necessary to provide an over all specification and testing procedures before hand. It's also very important to have a solid design and architecture plan. But you need to be flexible and cater for some extra time during the project for specifications that needs to be done just before developing an item.
You always know about more factors just before developing a piece of functionality than at the conceptualization phase, so the chance is that the specification that you provide for the functionality will be more spot on. You will also then be able to provide a better test-plan for that piece of code.
There are a lot of ways for developing and managing project. So I'm not saying that this post applies to everyone. I feel you shouldn't try to stick to one methodology, but try and take some from the several methodologies and use what works best for you and the project you're dealing with.