Scoping a project: the questions that protect you later
ost project disasters trace back to the first two weeks. The scope was vague, the constraints were unclear, the success criteria were never written down — and a few months later the team is shipping something nobody asked for, or arguing about whether it's done. A small set of scoping questions, asked early and written down, prevents most of this.
Project scoping questions
- Kickoff scopingasks
- Eight questionsreveals
- Surface constraints
- Success criteriause
- Concrete measures
- Scoping memofor some
- Written contract
Table of Contents
- What you'll learn· 1 min
- The scoping question set· 1 min
- Success criteria that survive reality· 1 min
- What deserves a written contract· 1 min
Quick reference
Eight questions
Done, who-for, not-doing, deadline, budget, decider, risk, off-track signal.
Done
Specific and observable. Not "improve the experience."
Out of scope
Explicit list, written down, acknowledged. Prevents 80% of "why didn't you build X?" fights.
Success criteria
Specific, time-bound, achievable but stretching.
One decider
Name them. Sign-off in writing. No exceptions.
Off-track signal
Decide the early-warning sign before things go sideways.
Most project disasters trace back to the first two weeks. The scope was vague, the constraints were unclear, the success criteria were never written down — and a few months later the team is shipping something nobody asked for, or arguing about whether it's done. A small set of scoping questions, asked early and written down, prevents most of this.
What you'll learn
The scoping question set
Eight questions, asked at kickoff, surface 80% of the constraints that will matter later:
- What does done look like? A specific, observable description. Not "improve the experience" — "users can complete checkout in under 90 seconds with three or fewer fields."
- Who is this for? A named primary user, not "everyone."
- What are we explicitly not doing? A short list of out-of-scope items, named to prevent later drift.
- What's the deadline, and what's driving it? A real reason (a launch event, a contract date) or a soft target.
- What's the budget — money, time, people? All three. Each constrains the others.
- Who decides if scope changes? Name one person. Decision-by-committee is decision-by-stalemate.
- What's the riskiest assumption? The thing that, if wrong, breaks the project.
- How will we know we're off-track? The early-warning signal, decided before things go sideways.
Write the answers down. Send them around. The act of writing surfaces disagreements that "we're aligned" hides.
Success criteria that survive reality
Vague success criteria — "improve the user experience", "increase conversion" — are a guarantee of mid-project arguments about whether you've succeeded. Concrete success criteria sound like:
- "Checkout completion rate moves from 62% to 70% on mobile, sustained over four weeks."
- "95% of support tickets in the new flow resolve in under 24 hours, vs. 48 hours today."
- "The system handles 5x current peak load with p99 latency under 400ms."
Good criteria have three properties:
Specific. A number, a threshold, an observable outcome. Time-bound. Measured over a defined window, not a single point-in-time check. Achievable but stretching. The whole team agrees the bar is real and roughly within reach if everything goes well.
If you can't write criteria like this, the project isn't ready to start. Push back on the kickoff and demand more clarity. The 30 minutes spent here saves a quarter of pain later.
What deserves a written contract
- List out-of-scope itemsExplicitly listed as out-of-scope in the kickoff memo.
- Write down the deadline driverSay what specifically drives it, or say it's a soft target.
- Name the single deciderIn writing, with their acknowledgement.
Not every scope decision needs a heavyweight document. The scoping memo — a one-pager with the eight questions answered — is the right artefact for most projects. But three categories of decision genuinely benefit from being written down with sign-off:
Out-of-scope items. When someone asks four months in "why didn't you build X?", having X explicitly listed as out-of-scope in the kickoff memo is the difference between "we agreed not to" and a fight.
The deadline driver. If the deadline is real (a contract, a regulator, a launch), write down what specifically drives it. If it's a soft target ("end of Q3"), say so. The team treats real deadlines and soft targets very differently, and they should know which they're working against.
The single decider. Name the person who decides on scope changes, in writing, with their acknowledgement. The temptation to leave this fuzzy is strong; the cost of leaving it fuzzy is enormous when scope creep starts.
Keep the rest in lightweight project notes. The scoping memo doesn't need to be a contract — it needs to be a shared written reference everyone can point to.
Want a more guided way to practise this?
Common questions
How long should scoping take?
For most projects, half a day to two days. For larger initiatives, a week. Spending less than half a day means you're skipping questions; spending more than a week usually means you're trying to plan instead of scope.
What if leadership won't commit to a deadline driver?
Push back politely and persistently. "To plan well, I need to know whether we're shipping for the May launch event or whether end-of-Q2 is a soft target. The plan looks different depending on which." If they refuse, treat it as a soft target and say so to the team.
Can the scoping memo change later?
Yes — explicitly, with the named decider, in writing. The point of the memo isn't to be a permanent contract; it's to be a shared reference that any change has to override deliberately.
How do I scope a project with unknown unknowns?
Scope a discovery phase explicitly: a fixed-time investigation that ends with a real scoping memo. Two weeks to investigate, then a written go/no-go and revised scope. This is honest about the uncertainty rather than pretending you can scope through it.
Bottom line
Eight questions at kickoff, written down and acknowledged, prevent most scoping disasters. Be specific about done, name what's out of scope, identify the single decider, and decide your off-track signal before things go sideways. The hour you spend here saves the quarter you spend later.