How can we manage scope when users discover needs during delivery?
Evolving requirementsAllow learning without making every discovery an immediate commitment. Maintain an ordered backlog and a clear decision boundary for changes that affect agreed outcomes, budget, or dates.
What to do now
- Capture newly discovered needs
- Compare their value with remaining work
- Reorder within delegated authority
- Escalate changes beyond agreed constraints
When to escalate
Escalate when
Discovery changes the project's purpose or authorized commitment.
Who decides
The scope owner and authorized sponsor
Example
A pilot reveals a valuable search filter, so the owner trades it for a less useful planned feature.
Mistake to avoid
Treating adaptive delivery as permission for unlimited scope.
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
- A requirement changed after testing began. How do we handle it?Late requirement change
- Our requirements document is approved, but users still disagree. Why?Approval without shared understanding
- How do we combine a fixed budget with evolving scope?Constraint-based adaptive delivery
- A regulatory requirement changes during the project. How should we react?External requirement change