Start with a scope everyone can refer to
A change request is easier to handle when the original agreement is easy to find. Before work begins, describe the intended deliverables, the main activities needed to produce them, the expected review stages, and any clear exclusions. A website project, for example, might include five page layouts and two rounds of feedback, while leaving new copywriting and additional pages outside the initial scope. The description does not need to predict every possible request. It needs to give both sides a shared starting point.
Keep this baseline in one place, such as a project brief or an agreed statement of work, and make sure the working team can access it. If the plan changes during delivery, update the record rather than relying on memories of a call. Scope clarity is not about refusing every new idea. It makes it possible to discuss an idea fairly: is this a clarification of work already agreed, a replacement for something planned, or additional work?
Capture the request before committing to it
Clients often raise changes in meetings or message threads while discussing other work. A quick “we can do that” may sound like approval to start, even if no one has considered the effort. A better first response is to acknowledge the idea and say you will check how it fits with the current plan. Then record the request in a shared list with a short description, who asked for it, when it was raised, and the decision still needed.
Ask what outcome the client wants before deciding how to deliver it. If a client asks for a new dashboard, they may need a different view of information already being collected rather than an entirely new reporting system. Clarifying the need can reveal a smaller option, or confirm that the larger change is worthwhile. Either way, write down what would be different from the agreed deliverable. This keeps the conversation focused on the work, not on whether the request is reasonable.
Explain the impact and offer choices
Assess each meaningful change against time, effort, cost, and other commitments. Include effects that are easy to overlook: a new feature may require revised designs, another review cycle, updated instructions, or a delay to dependent tasks. If the impact is uncertain, say so and identify what you need to check before giving a firm estimate. An early estimate is useful for discussion, but it should not be presented as more precise than the information allows.
Give the client workable choices where possible. You might add the request and adjust the schedule, replace a lower-priority item while keeping the deadline, or put the idea in a later phase. For example, adding two pages to a five-page website could mean extending production and review time; it could also mean swapping out two planned pages. Showing those trade-offs helps the client decide what matters most. Avoid treating an added request as a small favor if it meaningfully changes the work the team has planned.
Get a clear decision and update the plan
Before starting changed work, confirm the decision in writing through the approval process agreed for the project. State what is being added, removed, or revised; any change to the delivery schedule or price; and who has approved it. For a small request, a concise written confirmation may be enough for day-to-day coordination. Larger changes may call for an updated project document. The important point is that the people doing the work and the person authorizing it are working from the same decision.
Once approved, update the task list, milestones, and deliverable descriptions. Mark requests that were declined or deferred so they do not reappear later as assumed commitments. If a request is still being assessed, label it as pending rather than putting it into the active workload. This distinction protects the team's priorities and gives the client an accurate view of progress.
Make change control part of normal communication
A useful process should be light enough to use consistently. Review open requests during regular project check-ins, and send a short recap when decisions affect the plan. Keep a simple record of the request, its status, its agreed impact, and its owner. Small teams do not necessarily need special software; a shared document or project board can work if everyone knows where the current version lives.
Present this approach as a way to keep the client's priorities visible, not as a barrier to collaboration. Clients can change their minds as they learn more about a project, and teams can adapt without quietly absorbing every new task. When each request has a clear path from idea to decision to updated plan, both sides can discuss changes while retaining a reliable picture of the work they have agreed to do.
