Team Operations
Scope Creep: Use Change Control to Protect the Plan
Handle scope creep with an original change-impact worksheet that shows added work, removed work, dependencies and explicit decision options.
What you will learn
- Separate a valuable change request from an unapproved scope expansion.
- Calculate a bounded change's effect on committed work.
- Record the decision and update the accepted plan.
Scope creep happens when work expands without an accepted change to the plan's boundaries. The answer is not to reject every new idea. Make the added work, displaced work and dependencies visible, then ask the right owner to choose what changes.
A request is not yet a commitment
Atlassian's scope-creep guide discusses unplanned changes in project scope. Treat a new request as information to evaluate, not an automatic addition to the old promise.
First state the current baseline: output, quality boundary, owner, accepted deadline and available resources. Without that baseline, the team cannot distinguish a correction to agreed work from genuinely new scope.
Ask whether the request is required to deliver the original outcome, addresses a discovered defect, or adds a new outcome. These may need different treatment. Do not silently call unfinished original work a “change request” to make the plan look better.
What is scope creep with an example?
In this fictional example, a team has accepted 30 hours of work and has 32 hours of remaining capacity before its planned review. A stakeholder requests a second report format.
| Impact field | Original assessment |
|---|---|
| Requested change | Add a second report format for a different internal audience |
| Reason | The stakeholder wants another team to use the output; that team has not confirmed its requirements |
| Added effort | 8 estimated creation hours plus 2 estimated review hours |
| Dependencies | Second team's accepted requirements and an available reviewer |
| Unchanged baseline | 30 committed hours; 32 available hours |
| Unresolved evidence | Whether the second format needs different data, not just a different layout |
Added effort is 8 + 2 = 10 hours. Taking it on without removing work produces a 40-hour plan against 32 available hours, an 8-hour gap. That is a planning estimate, not a promise that the work will take exactly ten hours.
Offer decisions with consequences
| Option | Planned work | Consequence to accept |
|---|---|---|
| Add the full change | 30 + 10 = 40 hours | Resolve an 8-hour capacity gap or reconsider the review date |
| Swap accepted scope | 30 − 8 + 10 = 32 hours | Specify and approve the 8 hours of work removed |
| Defer the new outcome | 30 hours remain | Review the second format separately after its requirements are confirmed |
“We will squeeze it in” is not a fourth option unless the team can explain which assumption changes. Overtime, reduced review or delayed existing work are consequences, not free capacity.
A smaller version may be worthwhile, but estimate and describe it separately. Do not call a partial output the full requested outcome.
Copyable AI prompt
Try this with Aurora AI in Finta, Codex, or Claude. Use only material you are authorized to share, and review the draft before using it.
Assess [one change request] against [accepted scope], [remaining commitments], [capacity], [dependencies] and [approval roles]. Return added/removed work, effort ranges, assumptions, affected outputs and accept/swap/narrow/defer options with reconciled arithmetic. Distinguish a defect in promised work from new scope. Mark unresolved requirements. Prepare a decision brief only; do not approve the change, alter commitments or promise a date.Close the loop after approval
Record the requested change, decision, approver, revised scope and affected owners. Update the accepted plan and the communication to anyone who depends on it. An approved change that never reaches the delivery team can still cause confusion.
Review estimates when new evidence arrives. If the second team's requirements reveal more work, reopen the decision rather than burying another expansion inside the first request. Keep the prior baseline so the team can explain what changed.
Use the project-management guide for the full brief and critical-path lesson when schedule dependencies need calculation. Explore Finta's Capacity Planner with authorized planning inputs. Keep the approval and actual commitments with the responsible people.