The client wants every request treated as a defect. How do we distinguish changes?
Defect-versus-change ambiguityCompare actual behavior with the agreed requirement and acceptance criteria. A genuine failure to meet them is different from a newly requested behavior, although ambiguous requirements may require joint resolution.
What to do now
- Reproduce the reported issue
- Compare it with agreed criteria
- Classify failure, ambiguity, or new request
- Agree the appropriate correction or change route
When to escalate
Escalate when
The classification has material contractual or payment consequences.
Who decides
The scope owner and authorized sponsor
Example
A report with incorrect agreed totals is a defect, while adding a new export format is evaluated separately.
Mistake to avoid
Labeling every inconvenient report a change request.
Prevent a repeat
Review ambiguous requirements and unresolved acceptance conditions before the affected work begins.
Suggested ApprovedFlow setup
- Projects
- Tasks
- Documents
- Approvals
Keep the agreed scope and acceptance evidence with the project; record any proposed change and its decision separately. See the platform
Related cases
- Our scope statement lists activities but no deliverables. What should change?Activity-focused scope
- The client says an excluded item was always included. How should we respond?Scope interpretation dispute
- How do we distinguish an issue from a change request?Resolution-versus-baseline decision
- How do we distinguish a clarification from a scope change?Requirement interpretation boundary