I've been working for and with agencies for +10 years, from junior developer to technical director, I'm just giving my opinion about my own experience.
"Most customers want to pay a set sum for a project"
Yes, it's the revenue model of an agency, and the reason why agile software development is incompatible with the agency model: the customer commits to a scope and the agency commits to a price. Not exactly the definition of agility.
The problem is that, once the project has started, both actors will try to maximize their own interests:
The agency will reuse existing work instead of developing a new solution, and will take advantage of the blurry boundaries of the scope to exclude as much work as possible from it.
The customer will take advantage of the blurry boundaries of the scope to include as much work as possible from it. Since you're the expert and the advisor, you should have understood better.
Reuse of work is fair. As a developer, building reusable components and building systems that leverage reusable components is part of the fun when working in an agency.
Fighting over contracts, words, and interpretation is toxic. When developers are left alone in this battle, it's even more toxic because they haven't committed either to a scope or to a price themselves (estimates are not a commitment).
To make customers and developers happy, to build a good reputation, retain employees, attract more candidates, etc, it's in the interest of the company to avoid creating a toxic work environment.
How?
First, before starting the project, by conducting a requirement discovery phase to identify some of the new wishes you talked about.
Often customers have limited abstraction skills and need to visualize something to reason about it. Most of them don't spend hours in front of a computer, thinking about OOP patterns and SOLID principles. That's when whiteboards, wireframing, and prototyping can help. Also, it's cheaper to move boxes on a whiteboard rather than to rewrite code.
Then, during the project, you need strong project management skills to manage scope creep (see Managing Scope Creep). You need a brave project manager that can tell the client something like:
"Of course we can develop this feature. Despite the comprehensive requirements discovery phase we've conducted, we never talked about it before so, I hope you understand this is a modification to the scope we agreed on and we need to evaluate the impact of such a request."
This way you can involve customers in the development process, refine requirements, and still control the scope of the project.
"somehow no one saying anything against that"
If there's an honest discovery phase before starting the project, people will feel more confident saying no to a customer. They'll have evidence to show, and they won't fear damaging a good business relationship or looking like they are acting in bad faith.
One of the big challenges of the agency model is how to charge for this discovery phase somebody that is not a customer yet. Kind of a chicken or the egg problem.
after reading alot about Scope Creep i have to admin that this is EXACTLY our problem. More it is the customer on the one side that it is fine, but on the opposite side they start to complain once the sums start to roll in
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've been working for and with agencies for +10 years, from junior developer to technical director, I'm just giving my opinion about my own experience.
"Most customers want to pay a set sum for a project"
Yes, it's the revenue model of an agency, and the reason why agile software development is incompatible with the agency model: the customer commits to a scope and the agency commits to a price. Not exactly the definition of agility.
The problem is that, once the project has started, both actors will try to maximize their own interests:
The agency will reuse existing work instead of developing a new solution, and will take advantage of the blurry boundaries of the scope to exclude as much work as possible from it.
The customer will take advantage of the blurry boundaries of the scope to include as much work as possible from it. Since you're the expert and the advisor, you should have understood better.
Reuse of work is fair. As a developer, building reusable components and building systems that leverage reusable components is part of the fun when working in an agency.
Fighting over contracts, words, and interpretation is toxic. When developers are left alone in this battle, it's even more toxic because they haven't committed either to a scope or to a price themselves (estimates are not a commitment).
To make customers and developers happy, to build a good reputation, retain employees, attract more candidates, etc, it's in the interest of the company to avoid creating a toxic work environment.
How?
First, before starting the project, by conducting a requirement discovery phase to identify some of the new wishes you talked about.
Often customers have limited abstraction skills and need to visualize something to reason about it. Most of them don't spend hours in front of a computer, thinking about OOP patterns and SOLID principles. That's when whiteboards, wireframing, and prototyping can help. Also, it's cheaper to move boxes on a whiteboard rather than to rewrite code.
Then, during the project, you need strong project management skills to manage scope creep (see Managing Scope Creep). You need a brave project manager that can tell the client something like:
This way you can involve customers in the development process, refine requirements, and still control the scope of the project.
"somehow no one saying anything against that"
If there's an honest discovery phase before starting the project, people will feel more confident saying no to a customer. They'll have evidence to show, and they won't fear damaging a good business relationship or looking like they are acting in bad faith.
One of the big challenges of the agency model is how to charge for this discovery phase somebody that is not a customer yet. Kind of a chicken or the egg problem.
I hope this helps.
after reading alot about Scope Creep i have to admin that this is EXACTLY our problem. More it is the customer on the one side that it is fine, but on the opposite side they start to complain once the sums start to roll in