I read what-payment-structure-do-you-use-for-small-projects and I wonder how you guys are dealing with bug vs. feature. I once had a situation where a client wanted static reports. Then near the end of the project after most of the work on reports had been done he said he had always wanted dynamic reports. That change was not easy, because framework we choose did not support dynamic reports. It was a weird situation, because client had a programming team, so they should have known. Maybe it was just a lack of communication skills.
How do you guys deal with clients trying to make you add features, because they forgot, change their mind, or were misunderstood?
I mean big features, not small ones.
EDIT:
He stated that the budget is fixed and can't be changed and that this feature (like every) is critical and without it they wont accept the system. (just worst case scenario)
In my experience, having been on both sides of this issue, this is usually more about economics than it is about programming, process, or project management.
We, the client, often say "it may be a feature, but if we call it a bug, maybe we can get them to do it for free."
In the end we, the programmer, charge or don't charge based more on whether it will help or hurt our chances for future work. We, the client, dangle the carrot of future work as the incentive to get the programmers to do the extra work for free.
I don't believe any of that will change just because we have a better process for saying "this is a bug" or "this is a new feature."