I am often amazed how many people and organisations have not kept up with time and still have not fully adopted an agile or adaptive approach to software development. They may claim to follow an iterative process but to a large extend they still work in silos and effectively maintain conflicts between various groups involved in the project.
One of the most notable of these conflicts is the one between the people in the business defining the requirements and the development team trying to satisfy these requirements. Too many technical people still believe they can expect a signed off set of predictable requirements they can work after. The biggest problem with a signed off set of requirements is that project quality is measured by conformance to the plan rather than how well the software meets the true (ever changing) business requirements.
In today's economy, the fundamental business forces are changing the value of software features rapidly. Hence, in most cases it's practically impossible to define a stable set of requirements. Furthermore, I think most people have noticed that it's very difficult for business people to really understand what they need from software. As the entire software development project depends strongly on the requirements, you cannot work after a predictable plan.
Rather than trying to apply (misuse) all sorts of processes to software development that all aim to predict outcomes, realise the unpredictable nature of solution development and learn to deal with it! Letting go of predictability doesn't mean you have to revert to uncontrollable chaos. Instead you need a process that can give you control over unpredictability. This is where the agile approach comes in.
Following the agile approach, one of the key aspects of dealing with the unpredictability of requirements is to have continuous and effective communication between the development team and the people in the business. In other words, stop working in silos.
On his website, Martin Fowler is keeping an article up to date on The New Methodology for software development. It is very well written and he does an excellent job in explaining why you cannot treat software development as a highly preditable engineering project.