The Requirement Illusion

Once upon a time, in a previous life, I used to hire contractors and free lances to staff up the projects I was managing.
Obviously I needed to interview them first. I generally looked for generalists, not specialists; if a report designer needed to build a view server side, I always thought it was a waste of money and time to call for the database designer just for that. The roles on the project where almost always assigned according the customer organization, not the technology expertise.
The obvious consequence was that I was always recruiting fairly senior people, with many years of expereince under their belt; I wanted people who were able to interact with the customer and get their hands dirty at the same time.
One of the first questions I used to ask while interviewing was "What are the typical stages of a DW/BI project?". About half of them said "First, collect user requirements". Such an answer was invariably and swiftly followed by a "thank you for your time, we will let you know."

Expecting to be told what to do is generally a problematic approach to a project; in DW/BI it is quite close to an illusion. It is widely accepted that creating sound specifications in this world is extremely difficult because the users are unable to exactly define what they need so it is necessary to work in iterations, each time polishing the deliverables a bit more.
My point of view, however, is that even the deliverables produced by this process are an inefficient solution. The reasons are simple and twofold.

First, a deliverable that doesn't rise further questions is a bad one because it is not fostering the quest for insight. Apart from the legal statements, which have established rules and formats, you get a return form your solutions when knowledge helps improving and reshaping the business.
Second, you may deliver what you are asked for and yet not resolve the customer's issues. Our job is to resolve problems, not to deliver stuff. Maybe you are going to be contractually compliant but, as long as you are not fixing the issues, the customer will be unhappy. In the long run this is going to hurt as much as being explicitly in breach of the contract.

So, what is the the right answer to the original question? In my view something along these lines. First, get to know the people you are working with, understand what they do, what they are focusing on and learn about their concerns. Pay attention to assimilate the key elements of their language to be able to communicate effectively. Then investigate the reasons why they started the project in the first place, what they ideally would like to have, the position they would like to be in after being provided with some deliverables. On that knowledge, figure out a potential solution, prototype it and put it to the test with the users. Rinse and repeat till the customer is satisfied.