How do I prevent a project from quietly expanding beyond its agreed scope?
Quick answer
Compare each new request with the agreed outcome, deliverables, and constraints. If it changes what you’ll produce, who it’s for, or the effort or timing required, describe the difference and its likely impact. Then ask the appropriate decision-maker to choose whether to add it, swap it for existing work, adjust the deadline or resources, or leave it out. Keep the request and decision in writing.
The question, the details, the next step.
How can I tell whether a new request is actually scope expansion? I don’t want to push back on a small clarification.
Start with the agreement, even if it was a short email or meeting note. Identify the intended outcome, the specific deliverables, and any limits such as audience, deadline, number of review rounds, or available time. A clarification helps complete that agreed work; a scope change alters it or adds work.
For example, assuming a project is to prepare a three-page internal guide, correcting a typo is probably part of finishing it. Adding a second version for customers may be a change because it introduces a new audience and deliverable. The key is not whether the request sounds small. It’s whether meeting it affects the agreed result, effort, timing, or other work.
What if I’m unsure about the impact? I can’t always estimate the extra hours immediately.
You don’t need to pretend to know. Separate what you know from what needs checking. Name the requested addition, explain what it might affect, and offer a brief assessment before committing to a revised plan.
For instance: “The request is to add a customer-facing version. That may require different wording and another review. I can check the effort and timing, then send options by [date]. Until we decide, I’ll continue with the agreed internal guide.” If a quick estimate is possible, give a range or a clear assumption; if not, say what information you need. Avoid presenting an unverified estimate as a promise.
How do I raise it without sounding like I’m refusing to help?
Acknowledge the goal behind the request, then make the trade-off visible. Keep the tone neutral: the point is to help the decision-maker choose, not to label the request as unreasonable.
You could write:
“Thanks for flagging that the customer team also needs a version. The current plan covers the internal guide. Adding a customer version would expand the audience and deliverables, and may affect the review time. Would you prefer that I add it and move the deadline, replace one of the planned items, or keep this round focused on the internal guide? I can confirm the impact before we lock in a change.”
This shows willingness to solve the problem while making clear that extra work needs a decision.
What should go into the request for a decision, and how do I keep the record useful?
Keep it brief enough to scan, but specific enough that the decision can be acted on. Include the original commitment, the new request, the difference, the likely effect, and the person or group who can choose. Offer practical options where possible. Don’t assume that a suggestion from a colleague changes the plan if someone else owns that decision.
Copyable template:
“Hi [name], the agreed plan is [outcome and deliverables] by [date]. The new request is [addition or change]. This would [change audience, deliverable, effort, timing, or another commitment]. I [can/can’t yet] confirm the impact; [assumption or information needed]. Which option should I proceed with?
- Add the request and adjust [deadline/resources].
- Swap it for [existing item].
- Keep the current scope and record this for a later phase.
Please confirm by [decision date, if relevant]. Until then, I’ll proceed with [agreed work].”
After the decision, update the plan or send a short written recap: what changed, what stayed, who approved it, and any revised date. If no decision arrives, continue with agreed work only where that is practical, and flag any time-sensitive risk rather than silently treating the addition as approved.
A practical checklist
Find the agreed outcome, deliverables, audience, deadline, and constraints.
Compare the new request with that agreement; note what specifically changes.
Check likely effects on effort, timing, reviews, or other planned work; label unknowns.
Ask the appropriate decision-maker to add, swap, defer, or decline the change.
Record the decision and update the plan, including revised commitments.
A few more useful answers
Should I stop all work while I wait for a decision?
Not necessarily. Continue agreed work if doing so is practical, and say what you’ll proceed with while the change is undecided. Flag any deadline or dependency that makes waiting consequential.
What if the request comes from someone who isn’t the project decision-maker?
Acknowledge the request and ask who can confirm changes to the plan. You can share the likely trade-off with that person rather than committing on their behalf.
What if the decision-maker says to add the work but nothing else can change?
State the resulting constraint plainly, such as reduced time for another deliverable or an unconfirmed deadline. Ask which commitment takes priority, and document the answer rather than quietly accepting conflicting expectations.