People aren't very good about defining what they want, so if you follow a process that relies on them doing so you'll find yourself in trouble (which appears to be happening). Instead, people are good at indicating in a fuzzy manner what they think might want and very good at indicating what they don't want once they see something. So, you need to adopt processes that reflect this reality, and the best way to do so is to work in short iterations where working software is delivered. This puts you in a position where you can reduce the feedback cycle and home in on what people actually want fairly quickly. So, I'd argue that the real issue isn't that you need to firm up the requirements, but instead you need to get good at working collaboratively and iteratively with stakeholders in a flexible manner so that you implement systems that meet their evolving needs.

You'll still want to do some at the beginning of the project to agree on an overall vision and get going in the right direction. But you won't be able to effectively get to a detailed scope, and if you do you'll pretty much ensure that the project team develops a lot of .

In short, if you try to follow processes which don't reflect human behavior you're going to increase your overall project risk. Unfortunately many of the traditional theories around how software development should work go against common human behavior, which I suspect is one of the reasons why we see a .

- Scott