How do we distinguish a clarification from a scope change?
Requirement interpretation boundaryAsk whether the clarification changes the agreed outcome or the work reasonably required to deliver it. Ambiguous cases need documented agreement rather than a label chosen for convenience.
What to do now
- Locate the original requirement and assumptions
- Describe what the clarification changes
- Assess actual delivery consequences
- Agree classification and the appropriate action
When to escalate
Escalate when
The classification has material cost, schedule, or commercial effects.
Who decides
The authorized change decision maker
Example
Explaining an existing label differs from adding a new approval rule that was not previously agreed.
Mistake to avoid
Calling a new behavior a clarification to avoid approval.
Prevent a repeat
Compare delivered changes with authorized decisions and keep the current baseline distinguishable from earlier versions.
Suggested ApprovedFlow setup
- Documents
- Approvals
- Tasks
Keep the change request, impact assessment and recorded decision together; update affected tasks only after the appropriate authorization. See the platform
Related cases
- A regulatory requirement changes during the project. How should we react?External requirement change
- How do we manage changes in a fixed-price contract?Commercial change boundary
- How do we distinguish an issue from a change request?Resolution-versus-baseline decision
- The client wants every request treated as a defect. How do we distinguish changes?Defect-versus-change ambiguity