How to Handle Project Scope Changes Without Losing the Agreement
Use a practical scope change process to capture a request, compare its impact, record an authorized decision, and update the delivery plan while preserving the original agreement.
On this page
A customer asks for one more thing. The team wants to be helpful, so someone starts work before checking what the request changes. A week later, the date is unchanged, the workload is larger, and nobody can explain when the extra work became part of the agreement.
Scope changes are a normal part of project delivery. The difficulty is keeping the agreement understandable as the work evolves.
A practical process follows five steps: capture the request, compare its impact with the current plan, get a decision from someone with authority, update the plan, and tell the people who will execute it. Preserve the earlier agreement so the team can explain the difference.
Identify what the request changes
Start by locating the current scope and the evidence of its acceptance. Use the latest agreed version, including earlier changes that have already been approved. A proposal abandoned during negotiation is not a reliable baseline.
Follow a hypothetical service visit through customer booking, staffing, equipment, delivery, and follow up. See how named owners keep changes consistent across the work.
·7 min read
Operations Insights
Compare the request with that baseline. It may add work, replace something, change the review method, or resolve an ambiguity. A correction required to meet an existing acceptance criterion is different from a new deliverable.
For example, fixing a report that omits an agreed field may be ordinary completion work. Adding a new report for a different audience may change scope. The answer depends on the agreement; the size of the request alone does not settle it.
If the classification is unclear, record the uncertainty and ask the responsible owner to resolve it. Do not use “small change” as permission to bypass the discussion.
Capture the request before promising it
Translate the customer's message into a short statement of the requested outcome. Keep the original request available so the summary can be checked.
A useful request record identifies:
who asked and when;
what outcome they want;
which deliverable or milestone it affects;
why it matters to them;
any requested deadline;
what remains unclear.
Separate acknowledging the request from agreeing to deliver it. The project owner can say, “We have recorded the request and will confirm its effect on the plan by Wednesday.” That gives the customer a next step without making a premature commitment.
This also gives contributors a clear instruction. They can investigate or estimate the request while the decision is pending, within the agreed limits, rather than assuming that every message authorizes full delivery.
Compare the practical options
Assess the request against the remaining work, not only the effort required to build the new item. Review time, dependencies, specialist availability, and customer input can affect the result as much as implementation time.
Use a short comparison that answers four questions:
Scrollable article table
Dimension
Question to answer
Deliverables
What is added, removed, replaced, or changed?
Time
Which milestone or dependency moves, and on what assumptions?
Cost and capacity
What additional effort, external cost, or resource conflict is expected?
Acceptance
What evidence and customer review will establish completion?
Offer workable choices. The customer may prefer to replace a lower-priority item, extend the timeline, fund additional work, or defer the request to a later phase. An option should identify what stays and what changes.
Keep estimates qualified by their assumptions. “Four additional hours if the existing integration can be reused” is more useful than a precise number that hides the dependency. If the team needs a limited investigation first, specify its owner, boundary, and decision date.
Project economics can help the team assess the tradeoff, but expected margin and customer cash are separate signals. The article Why Profitable Projects Can Still Leave a Small Business Short on Cash explains why additional work and expected payment should not be treated as money already available.
Confirm who can decide
The person requesting a change may not have authority to approve its commercial or delivery effects. Establish that authority before changing the plan.
The project owner can explain the options. A commercial owner may need to approve a price adjustment. The customer may have one person who accepts deliverables and another who authorizes spending. Follow the authority and amendment process that applies to the project.
Record the actual decision, who made it, when, and what they accepted. “Approved” is incomplete if nobody knows which option was approved or whether the decision included the new date and acceptance criteria.
Use explicit outcomes: accepted, declined, deferred, or awaiting information. If acceptance is conditional, retain the condition. A response such as “yes, provided the launch date stays the same” requires a workable plan that satisfies that condition before execution can proceed.
An operational note does not automatically amend an agreement. When a change requires a formal amendment or another authorized process, complete that process and reference its result in the change record.
A hypothetical scope change example
Consider a small design team delivering an eight-page website with two review rounds. The current agreement covers marketing pages. During the first review, the customer asks for checkout copy for a separate store.
The project owner records the request and checks the agreed deliverables. Checkout copy is outside the current scope. The writer estimates six additional hours, assuming the customer supplies the product and shipping information. Those hours would overlap with the final review of the marketing pages.
The team presents three options:
Scrollable article table
Option
Delivery effect
Condition
Keep the existing plan
Eight marketing pages proceed on the agreed schedule
Checkout copy is deferred
Replace two lower-priority pages
Checkout copy enters the current phase
Customer approves the revised deliverable list and fee treatment
Add the checkout work
All original pages remain
Additional effort and a revised completion date are agreed
The authorized customer contact selects the third option through the applicable agreement process. The project owner records the decision, updates the deliverable list and review dates, and tells the writer which product information must arrive before work starts.
The original eight-page scope remains available. The change record explains why the current plan is different. This is a hypothetical example, not a report of customer performance or a standard estimate for website work.
Update the plan after the decision
An approved change is useful only when execution reflects it. Update the affected work items, dates, dependencies, resource expectations, and budget assumptions in the systems that own those facts.
Do not overwrite the only record of the earlier agreement. Keep the accepted baseline and append or reference the change. People should be able to reconstruct the sequence without searching through every message.
Check work already in progress. A contributor may need to pause an obsolete task, finish a prerequisite, or avoid duplicating work completed under the previous plan. Review any effect on other projects before assuming the same people are available.
Then communicate the decision to the people affected. Tell them the effective date, the changed work, the completion criteria, and where the decision lives. A customer approval sitting in an inbox does not update a contributor's understanding.
Copy this scope change record
Use a project note or a controlled document with a consistent format. Give each request a short reference so discussion can point to the same item.
Request reference and date:
Requester and requested outcome:
Current agreed scope reference:
Classification and reason: correction, clarification, addition, replacement, or other change.
Affected deliverables and acceptance criteria:
Options and impact: time, effort, costs, capacity, dependencies, and assumptions.
Decision and selected option:
Authorized decision maker and evidence location:
Conditions and unresolved questions:
Required agreement update and its status:
Plan owner and effective date:
People informed and next review:
Before the team executes a material change, check:
The request and current agreed scope are identifiable.
Options explain both additions and tradeoffs.
Estimates retain their assumptions.
The decision maker has the relevant authority.
The accepted option, conditions, and decision evidence are recorded.
Required agreement changes are completed.
Affected plans and work items reflect the decision.
Contributors and customer contacts understand the updated expectations.
Keep decisions close to delivery
Figena's project records support customer links, dates, and notes. Use those records to keep a concise change summary and references near the work. A controlled document can hold the fuller comparison and agreement evidence when the team needs more detail.
The checklist here describes a team process. A project note is not a dedicated change-order engine, a customer approval automatically attached to a contract, or proof that an agreement amendment has been executed.
Review pending and recently accepted changes alongside delivery exceptions. The 30 Minute Weekly Operating Review provides a useful cadence for checking owners, overdue decisions, and project impacts. Close a change record when the decision has been reflected in the plan and communicated, then retain its history with the project.
Separate decisions, actions, and open questions in meeting notes. Use a practical handoff template to confirm owners, define completion, manage dependencies, and review the result.
Decide which inquiries deserve the next sales step using evidence of need, fit, timing, and decision process. With a decision matrix, two hypothetical examples, and a reusable lead review.
