The system must separate the request, impact assessment and change authorization while retaining the scope version used by the delivery team.
Index
A customer may request an activity during delivery, but that request alone does not make it part of approved scope.
The rule that changes the scope
The system must separate the request, impact assessment and change authorization while retaining the scope version used by the delivery team.
A task manager collects requests; a custom module links changes to contracts and communicates the authorized scope to operations.
The change flow should start with the request as received, including its source. A customer can ask whether something is possible without requesting immediate execution. The interface must make that distinction clear to staff. Ask the supplier to show partial approval and a change replacing earlier work. Their effects differ: adding and removing work require their own communication and evidence to avoid duplicated or unauthorized execution by the delivery team.
Specify operational deliverables
- Associate the change with the original activity and customer-provided reason.
- Show effects on deliverables and resources before releasing the additional activity.
- Keep the earlier scope and revised acceptance available to both teams.
Test the exception before acceptance
In a hypothetical scenario, a request is declined after assessment; operations must retain the original work without treating the suggestion as an approved commitment.
Reference for assessing scope
NN/g: writing task scenarios for usability testing
Prepare your project with Quantum9
Bring a scope change and the sequence used to authorize or decline it.