I guess it's not common in small projects to develop a change management plan, so...
What do managers of small fixed-price projects do when a customer demands a change?
How is it resolved whether the change is compatible with original requirements or not, whether the customer should pay extra money for it, etc?
At the beginning of the project, do we estimate the amount of time of the development team that will be spent on discussing and analyzing possible demands for a change from a customer?
It does not matter the type of contract. All projects need to have a way to process changes because changes are a near certainty for every project in existence and will always be. The process does not have to be complex for smaller, less complex projects but there needs to be a way to understand the change, estimate cost and schedule impacts, estimate risks, and process the change.
Compatibility with original requirements is a non sequitar. It does not matter. If they are incompatible, then the change, if accepted, will change the requirements accordingly.
There should be no question as to whether the customer pays for a change, especially for a FFP contract, but really for all types of contracts. Customers must pay for changes on a project as it alters the original understanding, upon which the cost and schedule was based.
At the beginning of the contract, your estimate for the management of contract should include processing changes. You have no idea how many changes would be requested so there is risk to your FFP if you estimate too low. Experience with doing the work and with that customer should inform you the degree of effort you need to put into your FFP price; however, absent that, you simply have some risk here.
The answer to the first two questions can turn out to be simple or complex, but it is the same regardless of the size of project: negotiate. The evaluation as to whether something represents a change and then how much it costs often involves negotiation because not all eventualities can be be precisely defined in a contract. Even if it were possible to agree a complete specification (and that's an oxymoron) it's not usually in anyone's interest to do so in advance.
It is a good idea to state in your fixed-price contract what the terms are for "excluded costs". The contract should state the daily/hourly price for additional work and changes for example.
An even better idea is to avoid fixed-price terms for software development contracts. Fixed-price can work in some circumstances but more often than not it turns out badly for all parties. T&M and iterative delivery make more sense for most development work.
