Ronald, consider also Chapter 14 on Contracts in Craig Larman's "Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum" - http://www.amazon.com/Practices-Sca...0046EDOYU/
It helps a lot to understand that Agile methods help you to focus on what matters most, learn rapidly what works well for your user community, and them improve and adapt. That way, you don't start from the assumption that one can "know" the most valuable scope up-front. You may then consider budgeting for a fixed capacity, and allow for extensions in a framework of mutual agreement.
If you still want to define "it" before you can really know what "it" is, you're going to have to waste some effort exploring some elements of scope that won't turn out to be as valuable as you might think. It all comes down to the balance between investment in trying to figure things out through thought-experiments and actually finding things out through increments of working software.
Unless people think differently about strategy deployment, only superficial improvements may be expected. See also the Scaled Agile Framework for more inspiration - http://scaledagileframework.com/