Does anyone have articles they can send about the dangers of introducing last minute requirements or scope in a software release? Common sense right? However, it's human nature to ignore common sense.
I have a bunch of business stakeholders who claim to have all this "IT/Software Engineering" experience in a previous life but yet repeatedly ask why they cannot add scope during or sometimes even after UAT.
Not uncommon issue and yes it happens. :)
I understand that the COST is fixed in that the customer is not willing to pay anything extra for the additional scope asked. Is that correct?
If it is the case, probably this is where the "Acceptance Criteria" of your project documents come into picture. Has UAT been signed off? If so, you have a better case in your hand to take the additional scope as an addendum project with additional time and cost. If you dont have a well-defined 'acceptance criteria', you need to convince why this is an extra effort.
The above is purely from business and cost point of view. From engineering point of view - yes it would, no doubt, take additional overhead because of the additional planning, testing and "regression testing", documentation and delivery cycles involved. Maybe there would be code refactoring also to be done depending on what the additional scope to be added. "Supporting your argument, additional scope in software projects is not just adding one more floor to a multi-storey building where you can just focus on the new floor being added." Maybe you explain this to your senior management or business users (whoever you need to) so that these kind of scope alternations are minimized from the next time at least. (Remember, they can only be minimized in a real-world and cannot be nullified as in an ideal-world)
Slightly deviating from your question, end of the day - a project has to be viewed from all different perspectives - Quality, Time and Cost and you cannot satisfy all of them together. So, if you are a project manager you need to have your say - may be asking for either additional time or additional resources depending on the case. It is better to take the blame and stand up now to be more clear on scope and time than being hit at the end of the project.
If you need to handle it better from the next time, see if any of these contracting models help you - http://www.derailleurconsulting.com/blog/three-contract-models-for-scrum-projects.
Having said that, I would also admit that there were a few cases where, as a project manager, I had to accept a limited additional scope(for no additional cost) where I prioritized "customer satisfaction and customer retention" than anything else. Once the customer established a long-term relationship with us, it was easier for us to convince the customer on the scoping issues and how it would cost extra efforts etc. End of the day, we cannot get away from the rules of the business and it is not only an Engineering problem that we are solving.