Capture the reason behind the change

Start with what has changed in the problem, user need or operating context. A requested feature may respond to new evidence, clarify an ambiguous requirement or expand the original objective. These situations need different conversations.

Compare the request with the agreed scope and acceptance criteria. Avoid labelling a clarification as extra scope before understanding what the original commitment actually meant. Equally, make an expanded outcome explicit rather than absorbing it into an existing ticket.

Record who requested the change, the outcome it supports and any timing constraint. If the urgency depends on an external event, capture the source and the consequence of missing it.

Assess impact across the delivery system

Ask the relevant disciplines to examine the change together. Engineering effort is one input. Design, verification, content, data migration, support preparation and external dependencies may also be affected.

Look for work already completed that must be revisited. An apparently small interface change can alter a shared data contract or invalidate an agreed user journey. Document uncertainty as a question to investigate rather than hiding it inside a confident estimate.

Illustrative change request

A stakeholder requests an additional approval step before launch. The assessment considers the new screen, permission rules, notification behaviour, exception handling and support instructions. It also identifies whether the existing acceptance criteria still describe the intended journey.

Offer choices with explicit consequences

Present feasible options: include the change and revise the forecast, exchange it for another item, deliver a smaller version or schedule it after the initial release. Confirm that each option is technically and operationally viable.

Explain what remains fixed in each option and what moves. If timing and capacity are fixed, the scope discussion needs to acknowledge that boundary. Do not imply that an option is free simply because its impact has not yet been estimated.

  • Value: what outcome does the change enable?
  • Impact: which commitments and dependencies are affected?
  • Options: which approaches can the team support?
  • Decision: who has authority to accept the consequence?

Translate approval into a revised commitment

Once a choice is approved, update the scope, acceptance criteria, delivery sequence and stakeholder communication. Identify any completed work that now needs further verification. Assign owners to the actions created by the decision.

Keep the decision record beside the affected work. A message saying “approved” is difficult to interpret later without the option, its boundary and the assumptions under which it was accepted. The delivery brief checklist provides a useful structure for the revised scope.

Review patterns without treating change as failure

Repeated requests in the same area may indicate a discovery gap, an unresolved ownership issue or a changing business context. Examine the pattern before selecting a response. More approval steps will not necessarily resolve an unclear outcome.

Use the review to improve future briefs and decision timing. The objective is to make adaptation deliberate and its consequences understandable, while giving teams a reliable version of the commitment they are expected to deliver.