EM: People Management

How do you handle scope creep mid-project?

By Interview Clozo · Published 27 October 2026 · Last verified 26 October 2026 · 12 min read

How do you handle scope creep mid-project? You make the extra work visible, price it in time, cost or other scope, and let the person who owns the priorities decide. Scope creep is the uncontrolled expansion of scope without adjustments to time, cost, and resources, so the fix is the missing adjustment, not a flat no. The follow-up is which of three levers you offer first, and why absorbing the work is the wrong one.

In this article

Before you start
Why interviewers ask this
Scope creep mid-project from first principles
The Staff-level answer
The rubric
Three variants of this question
Common mistakes
Follow-up questions
Sources

Before you start

This page is one question from the engineering manager interview guide, which also covers the wider people management round.

Why interviewers ask this

Scope creep decides whether a manager's dates can be trusted, so interviewers use the question to see how you protect a plan without becoming a blocker. Candidates report it in engineering manager loops, where it sits between planning and people skills.

A weak answer says no, or says the team will absorb it. A strong answer separates a decided change from undecided creep, prices the request and names who decides. A Staff-level answer adds the follow-through: record the decision, update the plan, and ask why the request arrived informally. The interviewer is listening for whether you protect the team and the stakeholder in the same sentence.

Scope creep mid-project from first principles

Scope creep: Scope creep is the uncontrolled expansion of a project's scope without matching adjustments to time, cost or resources. The definition comes from the Project Management Institute lexicon as quoted by Orlando (2013). Added work that is evaluated and resourced is a scope change, not creep.
Scope baseline: A scope baseline is the approved scope statement, work breakdown structure and its dictionary, normally changed only through change control and used as the point of comparison. Creep is visible only against it: with no agreed baseline, nobody can say whether a request is new.
Change request: A change request is a written proposal to alter the agreed scope, schedule or cost, stating the work, the estimate, the options and who must approve. It turns an informal ask into a decision someone can accept, decline or trade.

In plain words

You hire a builder to fit a kitchen for an agreed price and date. Halfway through you say, "While you are here, add a window." One window seems small. A builder who says yes and changes nothing will run late or lose money. A builder who says no loses your goodwill. A good builder says yes, and tells you the cost and the extra days.

The analogy breaks in one place. A software project has no fixed blueprint. The team and the owner learn what is needed as they build, so change is normal.

In one precise sentence: handling scope creep means turning every unplanned request into a priced decision made by the person who owns the priorities.

Step 1: Tell a legitimate change from scope creep

A scope change is a change someone evaluated, approved and resourced; scope creep is a change nobody formally decided. That wording follows a vendor blog (Projeric, 2026), a secondary source, and fits the definition above.

Change itself is normal. The Agile principle is to welcome changing requirements, even late in development, so the question is never whether change is allowed, only whether anyone decided it.

Creep often starts outside the team. The same blog names a vague scope, missed requirements, informal access to the team and weak change control as common gaps. Orlando (2013) adds early signs: "When Timing starts to slip, the growth of the program should be suspected," and a budget that "starts to overrun for no identified reason" is a second flag.

Ask one question first: who decided this, against which baseline? You now know whether you have a change to price or creep to stop.

Step 2: Price the request and offer three trade-offs

Price every request in time, cost or other scope before anyone agrees to it. The reason is that the triple constraint is the rule that scope, time and cost are linked, so changing scope inevitably affects time or cost.

Take an illustrative project of 12 weeks and 6 engineers: 72 engineer-weeks of capacity, 60 planned and 12 held as buffer.¹ A request sized at 3 engineer-weeks gives three options.¹

Cut: drop 3 engineer-weeks of lower-priority work and keep the date.
Move: keep all the work, keep the buffer intact and shift the date by 0.5 week, if the work splits evenly across the six engineers.¹
Spend: use 3 of the 12 buffer weeks, a quarter of the buffer, and accept more risk later.¹

Adding people is a fourth option, but new people often need onboarding time before they add output, so it rarely rescues a near-term date. Orlando (2013) advises: "You want to say “Yes and…” there may be additional cost or time if we adjust the scope."

Step 3: Let the owner of priorities decide

The owner of priorities picks the option, not the engineering manager and not whoever asked loudest. The manager's job is to put the options and their costs in front of that person.

In Scrum, the Product Owner is one person, not a committee, and those wanting to change the Product Backlog can do so by trying to convince the Product Owner (Schwaber and Sutherland, 2020). The Sprint Goal is the one objective a sprint commits to. Inside a sprint, scope may be renegotiated with the Product Owner, as long as the Sprint Goal is not endangered.

In a plan-driven project the same role belongs to the sponsor or a change control board, a named group that approves changes. Change control is the formal routine of logging a request, assessing its impact and deciding. If nobody owns the decision, that gap is the real problem to raise.

Step 4: Record the decision and re-baseline

Record the decision, update the baseline and tell everyone who depended on the old plan. This keeps the next comparison honest, because the baseline normally changes only through change control.

Skipping this step is how plans drift: the date stays fixed on paper while the work behind it grows. The decision is logged and the baseline updated, so the plan on paper matches the work the team is actually doing. Without that entry, the next request is compared with a plan that no longer exists, and nobody can say what was agreed or who agreed it.

Tell dependants in plain words: what changed, what moved, who agreed. You now have the whole loop, from first request to updated plan.

Four steps turn an undecided request into a priced, owned and recorded decision.CC BY 4.0 — source: How do you handle scope creep mid-project?

Step-by-step description

Ask who decided this change.
Price it in time, cost or scope.
The owner picks the option.
Log it and update the baseline.

Scope creep is a change nobody formally decided.
Each request is priced in time, cost or scope.
The owner of priorities picks the option.
The decision is logged and the baseline updated.

What eight small requests do to a plan

Small requests do damage by adding up. In the same illustrative plan, 4 requests of 3 engineer-weeks use up the 12 engineer-week buffer.¹ The fifth request is the first to move the date, by 0.5 week, and 8 requests slip it by 2 weeks.¹ Eight requests add 24 engineer-weeks, 40% on top of the 60 planned.¹

None of the requests looked large on its own, which is why the signs of Step 1 matter. It is also why saying yes four times for free is a decision, not a favour, and why the fifth yes must come with a new date. A manager who has this arithmetic can show a stakeholder the buffer in one line.

Four small requests exhaust the buffer, and each later request moves the date by half a week.
Quantity	Value (illustrative, computed)
Capacity, 6 engineers for 12 weeks	72 engineer-weeks
Planned work	60 engineer-weeks
Buffer	12 engineer-weeks
One request	3 engineer-weeks
Move-the-date option	0.5 week
Spend-buffer option	25% of the buffer, 9 engineer-weeks left
Requests that exhaust the buffer	4
Date slip after 8 requests	2 weeks

Small requests are free until the buffer is gone, then every one moves the date.CC BY 4.0 — source: How do you handle scope creep mid-project?

Text description of the diagram

4 requests of 3 engineer-weeks use up the 12 engineer-week buffer.
The fifth request is the first to move the date, by 0.5 week, and 8 requests slip it by 2 weeks.

Knowing it is half the job. Saying it is the other half.

Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.