Scope Creep: How to Define Scope and Stop Creep in 5 Steps
"Can we just add one more thing?" That is how scope creep starts. In this video I take one project from a made-up online shop and show you how to define scope (the in list, the out list and a context diagram) and how to stop scope creep with 5 simple change control steps, based on the BABOK Guide. You get a worked example with two worked change requests, the change log, and the 5 mistakes to avoid.
Step by step
Scope creep is change nobody decided
- Change on a project is normal. Scope creep is change that slips in without a decision: a quick yes in the hallway, one more field on a form, an extra nobody priced. The BABOK Guide treats scope as a boundary. So the fix is to draw the boundary clearly and guard it with a simple change process.
Explain like I'm 5: the pizza order
- Think of a pizza order: 1 large pizza, $20, delivered in 30 minutes. Then you add olives, a second pizza and dessert, but still expect $20 and 30 minutes. A good pizza shop says: that's $8 more and 15 more minutes, still want it? That is change control. It shows the cost, and you decide.
Where scope lives in BABOK
- Scope shows up in 3 places in the BABOK Guide. Define Change Strategy produces the solution scope. Scope modelling is the technique for drawing the boundary. Assess Requirements Changes is where you check the impact before anyone says yes. Who decides is agreed earlier, in Plan Business Analysis Governance.
Solution scope vs project scope
- Solution scope is what the product will do. Project scope is the work needed to deliver it. For the gift card project, the solution scope is buy, email and spend a gift card at checkout. The project scope is building the pages, connecting the payment provider, and training customer service and finance.
The vague request
- The sales manager says: let's sell gift cards before the holiday sale. That is a wish, not a scope. Digital or plastic? Emailed or posted? Refundable? Each open question becomes an argument close to launch. So draw the box in 3 moves: the in list, the out list and the context diagram.
Move 1: the in list
- The in list: short lines that start with a verb. Buy a digital gift card for $25, $50 or $100. Email it with a personal message. Spend it at checkout, all at once or bit by bit. Check the balance. Customer service can look up a card and resend it. A line with no verb, like gift card stuff, is not scope yet.
Move 2: the out list
- The out list says what you will not do: plastic cards by mail, other currencies, bulk company orders, swapping a card back for cash. Some items go on a later list, meaning not in this release, not never. Because it is written down, nobody can say later they thought it was included.
Move 3: the context diagram
- The context diagram: put the gift card solution in a circle. Around it, draw the shopper, the receiver, the payment provider, finance and customer service, with an arrow for each flow, such as the payment, the gift card email and the balance report. If a request needs a new outside box, it is new scope.
Assumptions, constraints and sign off
- Write down assumptions (the payment provider already supports gift cards) and constraints (live before the holiday sale, 6 weeks away). Get the sales manager and finance to agree to the in list, out list and diagram in writing. That agreed version is the baseline. Anything new after it is a change.
Change control: set the rules first
- Set the change rules before the first request arrives: how a change is asked for, who analyses it, who decides and how people are told. For the gift cards it fits in one paragraph. Anyone can ask, the business analyst checks the impact, and the sales manager decides, checking with finance on anything about money.
Step 1: catch it in writing
- Step 1, catch it in writing. The sales manager asks in the hallway whether gift cards can earn loyalty points. Don't say yes or no. Say you'll write it up, then log a change request: who asked, what they want and why. Here the why is that shoppers who earn points come back more often.
Step 2: check it against the scope
- Step 2, check it against the scope. Loyalty points are not on the in list or the out list. On the context diagram they would need a new outside box, the loyalty system, and a new arrow. So this is new scope, not a detail. A detail only needs clarifying. New scope needs a decision.
Step 3: assess the impact
- Step 3, assess the impact on 5 points from the BABOK Guide. Benefit: more repeat shoppers. Cost: about 3 weeks of work. Impact: checkout, the loyalty system and finance reports. Schedule: it would miss the holiday sale. Urgency: low, nobody loses money if it waits. Put all 5 on one page.
Step 4: the right person decides
- Step 4, the right person decides, and usually that is not the business analyst. The BA makes the trade-off clear, and the decision maker named in the governance rules chooses: approve (the date or budget moves), deny (record why) or defer (a later release). The sales manager defers loyalty points.
Step 5: update and tell everyone
- Step 5, update and tell everyone. Update the in, out and later lists. Add a row to the change log with the request, impact, decision, who decided and the date. Then tell the team, finance and customer service. For a small change, the 5 steps take about 10 minutes.
Worked example: two change requests
- Two requests in one week. Loyalty points: new scope, 3 weeks of work, misses the holiday sale, low urgency, so deferred to release 2. A choice of 3 email designs: a detail inside the existing email line, half a day of work, no date change, so approved. Same process, 2 different answers.
The updated scope and change log
- After that week, the in list says: email it to the receiver with a personal message and a choice of 3 designs. The out list is unchanged. The later list adds: earn loyalty points, in release 2. The change log has 2 rows. When someone asks why cards don't earn points, you point to the logged decision.
Where it goes: the tools
- Keep scope where the team already looks: a Confluence scope page with the in, out and later lists and the change log, change requests as their own issue type in Jira with a status, owner and decision, and the context diagram in draw.io or Visio, linked from the scope page. The habit matters more than the tool.
5 common mistakes
- 5 common mistakes: the hallway yes, having no out list, saying no to everything, deciding alone instead of letting the budget owner decide, and gold plating, where the team adds extras nobody asked for. Gold plating goes through the same 5 steps.
Recap
- Recap: scope creep is change nobody decided. Draw the box with the in, out and later lists and a context diagram, and get it agreed. Then every change gets 5 steps: catch it in writing, check it against scope, assess benefit, cost, impact, schedule and urgency, let the right person decide, and tell everyone.
Common mistakes
- Saying yes in the hallway. A quick favour skips the impact check, and the cost shows up later as a missed date. Say you'll write it up, and log it as a change request.
- Writing only an in list. Without an out list, anything not mentioned stays a maybe that someone will later call included. Write down what is out, and put good ideas for later on a later list.
- Treating change control as a way to say no. The point is to make the cost visible, not to block change. A small detail like the 3 email designs should be approved quickly.
- The business analyst deciding alone. The BA shows the benefit, cost, impact, schedule and urgency. The person who owns the budget, named in the governance rules, makes the call.
When a business analyst uses this
In a requirements workshop, a stakeholder asks for a new report. The business analyst logs it as a change request, checks it against the signed-off in and out lists and the context diagram, writes a one-page impact note, and takes it to the sponsor to approve, deny or defer. The decision then goes into the change log.
Questions people ask
What is scope creep in project management?
It is when new features or work get added to a project without anyone formally deciding them. Each addition looks small, but together they push out the deadline and budget.
How can scope creep be avoided?
Agree a written baseline with an in list, an out list and a context diagram. Then send every new request through change control: log it, check it against scope, assess the impact and let the named decision maker choose.
Is scope creep always bad?
The change itself is not the problem. Good changes should get in. What makes it scope creep is that nobody weighed the cost or made a decision. Once a change is assessed and approved, it is managed change, not creep.
