not be done in the presence of developers or programmers. Keep the demonstration running smoothly by providing an outline to the attendees. Be sure to notify the developers or programmers when this demonstration is taking place so a testing area is available. Finally, never blame a developer or programmer in front of a group when a feature or function does not work or look as expected. Comments like "I guess Harry forgot to fix this" do nothing but harm. Always offer to take issues to appropriate persons and report back on the progress. Don't be tempted to sacrifice integrity for short-term payoff.
Communication before Delivery
Quality Assurance should clear the path so that developers and programmers can openly discuss snags in the project and offer alternatives. It is important to realize the best window of opportunity is after the request has been made and before the delivery is complete. Delivering without a feature or function or with a questionable alternative is a symptom of poor planning and communication.
A final note: Holding to the requested features is not about inhibiting innovation. Users are best equipped to tell you what they need. It will be a test of understanding their needs, and of communication skills, to implement real innovations.