Scope Change Process (CQ)¶
Owner: Vi | Updated: 2026-02-05
Purpose¶
When requirements change mid-work, don't silently absorb the change. This SOP defines how to handle scope changes so deadlines stay realistic and expectations stay aligned.
Default stance: Meet the deadline first, then consider changes.
We are NOT lenient about scope changes. Every accepted change erodes deadline discipline. The team's first job is to deliver what was committed, on time. Only after confirming we cannot meet the deadline should we discuss adjusting it.
The Problem This Solves¶
| Symptom | Root Cause |
|---|---|
| Features take 5 months instead of 1 | Scope creep absorbed silently |
| Devs always "almost done" | Moving goalposts |
| Deadlines constantly missed | Original estimate was for different scope |
| Team demoralized | Feeling of never finishing |
The fix: Make scope changes visible. Adjust deadlines explicitly.
What Counts as a Scope Change¶
| Scope Change | NOT a Scope Change |
|---|---|
| New feature added mid-work | Bug fix in current feature |
| "Can we also add X?" | Clarification of existing requirement |
| Stakeholder changes direction | Minor UI tweak within spec |
| New integration requirement | Refactoring for code quality |
| "Actually, I meant Y not X" | Edge case handling we missed |
Rule of thumb: If it adds more than 4 hours of work, it's a scope change.
The Scope Change Process¶
Step 1: Recognize It¶
Dev or Vi notices: - New requirement added - Direction changed - "One more thing" requested - Original understanding was wrong
Signal phrases: - "Can we also..." - "Actually, I meant..." - "One more thing..." - "While you're at it..." - "Oh, and we need..."
Step 2: Pause and Document¶
Don't just absorb it. Stop and document:
## Scope Change Request
**Task:** [Original task name]
**Requested by:** [Who]
**Date:** [When]
## Original Scope
[What was originally agreed]
## Requested Change
[What's being added/changed]
## Impact
- Additional effort: [hours/days]
- New deadline needed: [date]
- Dependencies affected: [list]
## Options
1. Accept change, move deadline to [date]
2. Accept change, reduce scope elsewhere
3. Reject change, keep original scope
4. Split into separate task for later
Step 3: Communicate Impact¶
Don't say: "OK, I'll add that" Say: "That's a scope change. Here's the impact..."
Example response:
Adding email templates is a scope change.
Original deadline: Friday
With this change: Next Wednesday
Options:
1. Move deadline to Wednesday (recommended)
2. Ship without templates Friday, add templates next week
3. Skip templates entirely
Which do you prefer?
Step 4: Get Decision¶
Who decides: - Small change (< 1 day): Vi can decide - Medium change (1-3 days): Vi + requester - Large change (> 3 days): Vi + Ryan
Document the decision in the task comments.
Default stance: Meet the deadline first.
Don't be lenient about scope changes. If we accept every change, deadlines become meaningless. The first priority is always: can we meet the original deadline with the original scope? Only after exhausting that option should we consider adjusting.
Step 5: Update Everything¶
Once decision is made: - [ ] Update task description with new scope - [ ] Update deadline - [ ] Update any dependent tasks - [ ] Notify affected people - [ ] Continue work
Scope Change at Each Phase¶
| Phase | How to Handle |
|---|---|
| Alpha | More flexible - experimentation expected. But major pivots = restart Alpha |
| Beta | Scope changes should be rare. Big changes = back to Alpha |
| Final | Scope is LOCKED. New features = new Alpha cycle. Only polish current scope |
Key rule: Final is for completing agreed scope, not adding features.
When to Push Back¶
Push back on scope changes when:
| Situation | Response |
|---|---|
| Change comes from unclear thinking | "Let's clarify the goal first" |
| Change is actually a new feature | "That's a separate feature, let's track it" |
| Change would cause major rework | "That requires restarting from Alpha" |
| Change has no clear benefit | "What problem does this solve?" |
| Multiple changes in one sprint | "We're scope creeping. Let's prioritize" |
It's OK to say: "We can do that, but not in this release."
Mid-Phase vs Phase Transition Changes¶
Mid-Phase Change¶
Scope changes within a phase: - Document impact - Adjust deadline - Continue in same phase
Phase Transition Change¶
Major direction change: - If in Beta and direction changes significantly → Back to Alpha - If in Final and new feature requested → New Alpha cycle
Example: - "Let's add a button" (mid-phase) → adjust deadline - "Actually, let's pivot to a different approach" (phase transition) → back to Alpha
Documentation Template¶
Add to task comments when scope changes:
---
**SCOPE CHANGE - [Date]**
**Requested by:** [Name]
**Original scope:** [Brief summary]
**Change:** [What's being added/changed]
**Impact:** [+X days]
**New deadline:** [Date]
**Decision:** [What was decided]
**Approved by:** [Who approved]
---
Red Flags¶
| Red Flag | What It Means |
|---|---|
| Multiple scope changes per task | Requirements weren't clear upfront |
| Same person always requesting changes | They need to be involved earlier |
| Changes always accepted without pushback | Team is too accommodating |
| Deadlines never move despite changes | Setting team up for failure |
| "Just one more thing" repeatedly | Death by a thousand cuts |
Integration with Other SOPs¶
| SOP | Connection |
|---|---|
| Task Creation Standards | Clear scope prevents changes |
| Alpha-Beta-Final | Phase determines change tolerance |
| Decision Request | Use for significant changes |
| Missed Deadline | Undocumented scope changes cause this |
FAQ¶
Q: What if Erik changes scope? A: Same process. Document the change, communicate impact, adjust deadline. Erik's requests aren't exempt from physics.
Q: What if the scope change is an improvement? A: Still document it. Good changes still take time.
Q: What if the original scope was wrong? A: That's a clarification, not a scope change. But if it adds significant work, treat it like a scope change.
Q: Can I just absorb small changes? A: If truly small (< 1 hour) and doesn't affect deadline, yes. But if you're absorbing changes regularly, something is wrong.
Q: What if client insists on change without deadline move? A: Escalate to Ryan. Trade-offs are: scope, deadline, or quality. Can't have all three.
Summary¶
| Principle | Why |
|---|---|
| Make changes visible | Hidden scope creep kills projects |
| Adjust deadlines explicitly | Original estimate was for original scope |
| Document everything | Creates paper trail, prevents disputes |
| Push back when appropriate | Protect the team from scope creep |
| Final scope is locked | New features = new Alpha |
Scope changes are normal. Silent scope creep is not.