Scope changes are normal. A user test reveals a missing step. A stakeholder asks for another audience. A technical dependency behaves differently than expected. The problem is not that the plan changed. The problem is continuing as if it did not.
Here is a practical way for clients and freelancers to handle the change without turning every new idea into a dispute.
Is this a correction or new scope?
A correction brings the work into line with what was already agreed. New scope changes the agreed outcome, deliverables or assumptions.
If a design was supposed to include a mobile state and it was omitted, adding it is likely a correction. If the original brief covered desktop only and the client now wants mobile, that is new scope. If software fails the written acceptance test, fixing it is a correction. If the client adds a new integration, that is new work.
Use the brief and acceptance criteria instead of memory. If they were vague, acknowledge the ambiguity rather than pretending one interpretation was obvious.
Should work stop while we decide?
Pause only the affected work. The freelancer should explain what is blocked and what can continue safely. The client should identify who can approve the change.
Continuing without a decision is risky. The freelancer may spend hours on an approach that is about to be replaced. The client may assume a casual message was included for free. A short pause is cheaper than invisible rework.
What should a change note include?
Keep it simple:
- what changed and why;
- which current deliverables are affected;
- added or removed work;
- price or hourly impact;
- new delivery date;
- updated acceptance criteria;
- who approved the change.
Small changes can live in the project thread. Larger ones deserve a new milestone or written amendment. Both sides should confirm before work resumes.
How do we price the change fairly?
Ask the freelancer for an estimate before starting. The estimate should include not only the visible addition but also affected testing, revisions and handover.
The client can accept it, reduce other scope, move the feature to a later phase or stop. If the change results from an incorrect assumption made by both sides, a shared compromise may preserve the relationship better than arguing over blame.
Clients can hire freelancers on Workli and structure work as recorded contracts, but the platform does not replace the agreement between the parties or handle their payments. Clear milestones and direct written decisions remain essential.
What if scope keeps changing?
Repeated change is a signal that discovery is incomplete or too many people can redirect the work. Stop adding isolated requests and revisit the objective.
You may need a paid discovery milestone, one product owner or shorter planning cycles. For uncertain work, agree on a time-boxed capacity rather than pretending the output can be fixed in advance. The contract should match the kind of uncertainty the project actually contains.
How do we protect the relationship?
Use neutral language. “This changes the agreed mobile deliverable and adds about two days” is more useful than “You keep moving the goalposts.” Record decisions promptly. Pay for accepted work before beginning a substantially different phase.
A scope change handled openly can improve the project. It shows that both parties can adapt without hiding cost or responsibility. The danger is not change itself; it is allowing the contract, budget and expectations to tell three different stories.
Comments0
It’s quiet in here. Fancy breaking the ice?