Establish what is changing
Describe the request in terms of behavior and the reason it matters now. Is it correcting a misunderstanding, responding to a new constraint, or adding a separate outcome? Those situations should not automatically be treated the same way.
Connect the request to the agreed objective. A change may be essential to making the chosen workflow function, even if it was not described clearly at the beginning. Another request may be valuable but independent of that workflow.
Show the tradeoff
Ask the team to identify affected screens, data, integrations, and tests. Include work that may already need to be revised. An apparently small interface change can alter who is allowed to act or what must be recorded.
Present practical options: replace a planned item, defer the addition, change the delivery boundary, or revise the schedule. Explain uncertainty instead of offering a precise estimate before the impact is understood.
Record the decision once
Agree who can accept the tradeoff and update the working plan. Keep a short record of the change, its reason, and the resulting scope. The team should not have to reconstruct that agreement from scattered messages.
Revisit acceptance criteria and communications affected by the decision. If a feature is deferred, make sure people preparing training or launch material know that it is no longer included.
A useful change process is quick enough to use and clear enough to prevent surprise. It should help the team adapt while preserving a shared understanding of what the current release is meant to achieve.
A practical example.
During a request-tool project, a stakeholder asks for contractor access. That sounds like another user type, but it may change account provisioning, visibility rules, notifications, and support responsibilities. Write down those consequences before describing the change as small or large.
Compare at least two paths: keep the first release internal and send contractors existing instructions, or move another feature out to make room for a controlled external workflow. The decision record should name what changes, what remains scheduled, and who accepts the tradeoff. Once agreed, update the acceptance examples and release plan together. Leaving the old plan untouched creates a misleading promise even when everyone remembers the conversation differently.
Put it into practice.
- Describe the new outcome and the reason it is needed now.
- Check effects on permissions, integrations, operations, and acceptance criteria.
- Update the delivery commitment and communicate the displaced work explicitly.