A small addition may genuinely be small. It can also be a one-sentence request that changes the entire production sequence. I frame scope discussions around consequences rather than debating whether the request sounds large.
Understand the request first
When someone asks for an English version, do they mean the body copy alone or also images, form messages and separate page links? Offering a time or cost estimate before clarifying the requirement adds uncertainty.
I then compare it with the agreed assignment. Is this an unfinished part of an existing deliverable or a new output? Neither treating everything as extra nor absorbing every request into the original scope is a reliable approach.
Show the effect in three places
What changes in the deliverable, which steps in the schedule are affected and what existing priority may need to move? Any budget implications also need discussion. Boundaries become useful when they are accompanied by choices.
Imagine a new page being requested for the same week. Options might include postponing a less important page, extending the delivery date or adding capacity. The conditions attached to each choice should be visible.
Use the record to understand change
You did not ask for this originally can trap a discussion in the past. The previous decision record is more useful for explaining what has changed than proving someone wrong. A change can be reasonable while still requiring agreement on its effects.
That is why project memory belongs in everyday work. The current scope version and the person approving its latest change should be clear.
Boundaries can protect the relationship
Making an unrealistic promise and later missing it is often harder on a relationship than discussing constraints early. I treat scope as a shared description of the work, not a defensive wall.
A productive conversation may not eliminate the new request. It should leave everyone understanding which option was chosen, why and what happens next.