In Chapter 1, we analyzed challenged projects and discovered a variety of root causes, with requirements management being near the top of the list. In Chapter 16, we defined the Vision document as a seminal document in a complicated software lifecycle; this document directly addresses the requirements challenge and is the one document you can read, at any time, to see what the product, application, or system is and is not going to do. In total, the Vision document represents the essence of the product and must be defended as if the success of the project depended on it, for it does .
At some point, the question rightly becomes, "But who develops and maintains this all-important document? Who manages customer expectations? Who negotiates with the development team, the customer, the marketing department, the project manager, and the company executives who have shown such keen interest in this project now that the deadline approaches? Who adjudicates the inevitable conflicts that arise over scope and budget?"
In every successful project we've been involved in ”from adventure ride vehicles that put butterflies in the stomach of every guest to life-supporting ventilators that sustain tens of thousands of lives without a single software failure ”there was a champion . We can look back at these projects and point to one individual (or, in the case of larger projects, a small team of a few folks) who played a "bigger-than-life" role. These champions kept the visions of the products (or systems or applications) in the front of their minds as if doing so were the single most important thing in their lives. They ate, slept, and dreamed about the project vision.