Request a change without losing the current scope

Describe the difference you need

A change request should say what the current experience or workflow does and what it should do instead. It may affect copy, design, a business rule, a connection, a report or operating support. The work and approval should match the consequence of that change.

1. Describe the current and desired behavior with a concise example.
2. Explain who benefits and the business reason.
3. Agree the acceptance checks and the person authorized to approve the scope.

• A content draft and an application release use different publication paths.
• New integration, migration or provider work is not implied by a small copy or design change.

Review the effect before approving

The delivery team should identify dependencies, access, data changes, testing and any effect on the agreed release. Keep the decision and revised acceptance with the work so later reviewers can understand what was approved.

• The affected users, systems and environments.
• The expected result and relevant failure cases.
• Any scheduling, training or handover effect.

After the change

Check the released or published result against the accepted example. If it differs, refer to the agreed behavior and provide evidence of the gap.

• The change or release reference.
• The acceptance example and actual result.
• The owner of any follow-up or remaining requirement.