An interesting statistic in a recent survey is that:

"A third of businesses in this country said that keeping project requirements as constant as possible, without allowing too many changes, was key to cutting costs."

I absolutely agree with this statement, however it is quite difficult to achieve.  How many of us 100% understand what we want from a delivery months before go live.  How many of us in the technical world can produce a design that absolutely reflects the business requirements 100%?  How many people within the business can sign off a technical requirements in the certain knowledge that it delivers 100% to their requirement.

I can tell you the answer to these questions, none of us.  Certainty is not a word that is often used in the development lifecycle, especially around translation between business requirements and technical specification. 

So is there a way that project requirements can be kept as constant as possible?  I think there are approaches that can help mitigate against change, or others that allow for change, but none that can eliminate it altogether.

Technology can help but needs to be more business friendly.  It is widely accepted that the more that the business can do in a project, the more successful that project will be, so the easier a technology is to use and understand, the more likely it is that they will use it proactively. 

Agile can help in that it is an approach that allows for change, however adopting Agile can be difficult and does require a step change in thought processes.

Ultimately the answer rests with communication.  IT and business need to find ways of communicating requirements and potential solutions in a manner that breeds mutual understanding. 

My personal view is that effective prototyping is the key.  It is standard to produce "mock ups" in many design functions in many industries, so perhaps we in the data world should take a leaf out of their book and find ways to share technical ideas in a much more "tactile" fashion.