The decision
A new request is information, not automatically an instruction to build. Scope control begins by distinguishing a defect against an agreed requirement, a newly discovered requirement and a preference. Each has a different implication for acceptance, cost and sequencing.
A worked example
In an illustrative appointment product, the agreed scope allows a customer to cancel. Asking for cancellation reminders is new behaviour; fixing a cancellation that deletes another customer's booking is a defect. Supporting a mandatory approval rule overlooked during discovery needs an explicit decision about the original assumptions.
Give each request a decision-ready shape
A change record does not need a complex management system. A useful entry has a stable identifier, the requester, the reason, the affected workflow, the current promise and the proposed difference. Attach a concrete before-and-after example. For the appointment product, distinguish notifying a customer of their own cancellation from notifying staff of every cancellation across a location. Those sound similar in a meeting but have different recipients, permission checks and noise costs. Ask the request owner to approve the interpretation before estimating it. A precise small change is easier to discuss than an ambiguous large one.
Assess impact beyond the edited screen
Trace effects through data, access, notifications, reporting, migration and operating instructions. A new cancellation reason may require a field, but it also raises questions about existing bookings, who can read sensitive reasons and whether reports group older records as unknown. Consider work already accepted: does the change invalidate an earlier test or require rework? Present the decision as options with consequences, including doing nothing for now. This gives the business owner a genuine choice and prevents the development team from silently deciding which original commitment to sacrifice.
Keep acceptance aligned with the latest agreement
After approval, update the affected scope, acceptance examples and estimate together. Record rejected or deferred requests so they do not return as apparently forgotten commitments. At demonstration time, compare behaviour with the current approved version, while keeping previous decisions available for explanation. If an urgent defect requires immediate correction, document the incident and follow with a review of the underlying rule rather than hiding a feature expansion inside the fix. A scope process succeeds when both sides can explain what changed and why, even after several people have joined or left the project.
Alternatives worth weighing
For each change, write the reason, affected users, simplest acceptable version, dependencies and acceptance example. The owner can exchange it for another item, increase the budget or postpone it. Keeping the date, price and scope unchanged is a claim that needs evidence, not a default promise.
Where the plan breaks
Avoid verbal approvals scattered across chats. Keep a small change register linked to the current scope and decision maker. Do not make urgent operational defects wait behind cosmetic requests, but do not label every stakeholder preference an emergency either.
Before you commission the work
Who can approve a change? What stops being delivered if this is added? Which existing acceptance examples must change? A custom software partner should answer those questions before work starts, so the team can adapt without erasing the original objective.