If you follow this lesson throughout the project, there's essentially no purpose for a user acceptance test, as it's really just a demo or training session. If the users weren't willing to put the energy into specifying the tests that constitute acceptable behavior, they don't get to veto things at the end of the project. (Of course, this assumes consistency and long-term memory that may be beyond the reach of your organization's politics.)
If You Insist on Fixed Price, You've Got to Pay the Price
CFOs and waterfall enthusiasts just love fixed price projects. They're easy to manage; all you do is write the checks and check the boxes as deliverables cross the UAT finish line.
In software, particularly when upgrading existing CRM systems, there's a rat's nest of costly unknowns: The details of business process, the data quality in existing stores, the existing bugs in executable and integration code and even the functional acceptance criteria. Any vendor willing to submit a fixed-price bid without a hugely detailed requirements document is either a fool or thinks he can issue endless change orders to cover the "unknown unknowns."
There's no question that it's possible to create a sufficiently detailed requirements document to support a true fixed-price project. But are you willing to put in all that effort before accepting the project bids? Then the ultimate question stares you in the face: "How long will that requirements document stay accurate?" In the immortal words of Clint Eastwood's Dirty Harry, "Do you feel lucky?"
The price for fixed-price projects is either a lot of homework on your part or a discovery project that you conduct with the integrator of your choice. In big government software projects, the time spent documenting requirements and justifying budgets may exceed the time involved spent delivering the project.
You won't be surprised to hear me say that Agile avoids this problem by short-circuiting the "monolithic spec process." The single, monolithic project is redefined as a series of small projects, each with its own mini-discovery. Before discovery is even over, prototyping begins. Within weeks the functionality is delivered. The requirements document is never really written, because it's been embodied in the as-built project docs and system tests.
Sign up for CIO Asia eNewsletters.