Our scope statement lists activities but no deliverables. What should change?
Activity-focused scopeDefine what the project must produce and how each output will be accepted. Activities remain useful for planning, but they do not by themselves describe a completed result.
What to do now
- Translate activities into tangible outputs
- Define acceptance evidence for each
- Identify missing enabling work
- Confirm the output-based scope with the sponsor
When to escalate
Escalate when
The team cannot explain what completion will look like.
Who decides
The scope owner and authorized sponsor
Example
Conduct training becomes a defined training package, completed sessions, and evidence of user readiness.
Mistake to avoid
Calling hold workshops a final project deliverable.
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
- The client wants every request treated as a defect. How do we distinguish changes?Defect-versus-change ambiguity
- How can we manage scope when users discover needs during delivery?Evolving requirements
- How can we tell whether stakeholder engagement is working?Activity-focused engagement measures
- The vendor's proposal is vague about deliverables. What should be clarified?Ambiguous supplier scope