1) Scope bloat can come from all sides. I've sat in meetings with eager-to-please devs who insisted on getting clients excited for gizmo-flavor-of-the-month x ("hey, how about we add a Facebook button to have customers share what they bought with their friends!") to the scope of a project just to make themselves look good to their bosses, only to lament about the enormity of how much they had (promised) to do at crunch time.
2) Too often, there is a lack of communication between clients, devs, and project managers. If the project manager is 1) unfamiliar with development (happens a lot, actually) and 2) is unable to correctly walk a client through every nook and cranny of their requirements, then it creates a situation where the client can have expectations in mind that are at odds with the requirements that devs are given.
A great example would be a 'simple' payment system as part of a larger e-commerce site. The client says they have store gift cards, credit cards, and PayPal. Perfect. The dev builds the payment system for the client, and, upon demo, the client sees that there's no option for tax-exempt purchases. "Well, 75% of our business comes from non-profits!" "Amazon lets you do it, it shouldn't be that hard!"
Then, the client notices that nowhere can you process refunds. "Refunds weren't in the original scope," the dev says. "Well, great, but now we can't use this product at all," says the client. Who is at fault? In the client's mind, they're so used to using websites with built in refund and tax-exempt options that it never crossed their mind to include it in their requirements walkthrough with the project manager. On the dev end, devs are very "to the letter" when it comes to requirements. They see credit card, PayPal, and gift card, and implement all three and call it a day.
In my mind, when the requirements bloat, it's a failure on the part of the project manager, whose job is to make sure that nothing gets lost in translation and to make perfectly clear the process for change management. It's a blessing when a client is tech-savvy enough to understand that you cannot miss a single detail.
You've left out one role: the developers including the project manager being familiar enough with the domain to ask "Would you like fries with that?" ^_^. In general the model of developers as being "very 'to the letter'" without such a feedback loop is to be avoided, one of many reasons the Waterfall model is very poor.
Your examples are good ones: it's not unreasonable to expect them to know about refunds, but non-profits are a less common example. Although B-to-B is often sales tax free, when you're buying for something to resell (that's where I'm familiar with it, from working for a VAR where I was often the one adding serious value).
2) Too often, there is a lack of communication between clients, devs, and project managers. If the project manager is 1) unfamiliar with development (happens a lot, actually) and 2) is unable to correctly walk a client through every nook and cranny of their requirements, then it creates a situation where the client can have expectations in mind that are at odds with the requirements that devs are given.
A great example would be a 'simple' payment system as part of a larger e-commerce site. The client says they have store gift cards, credit cards, and PayPal. Perfect. The dev builds the payment system for the client, and, upon demo, the client sees that there's no option for tax-exempt purchases. "Well, 75% of our business comes from non-profits!" "Amazon lets you do it, it shouldn't be that hard!"
Then, the client notices that nowhere can you process refunds. "Refunds weren't in the original scope," the dev says. "Well, great, but now we can't use this product at all," says the client. Who is at fault? In the client's mind, they're so used to using websites with built in refund and tax-exempt options that it never crossed their mind to include it in their requirements walkthrough with the project manager. On the dev end, devs are very "to the letter" when it comes to requirements. They see credit card, PayPal, and gift card, and implement all three and call it a day.
In my mind, when the requirements bloat, it's a failure on the part of the project manager, whose job is to make sure that nothing gets lost in translation and to make perfectly clear the process for change management. It's a blessing when a client is tech-savvy enough to understand that you cannot miss a single detail.