1.3Scope, assumptions & exclusions
The essentials in 30 seconds
- Scope draws the boundary between what is included and what is excluded.
- With no written boundary, the project drifts (scope creep): "small additions" overflow schedule and budget.
- Writing exclusions and validating assumptions matters as much as writing inclusions.
Running mini-case — Bilal writes what is excluded
Bilal writes in black and white: the project does NOT include training the 15 warehouse staff, NOT migrating history, NOT maintenance. Noted assumption: "the accountant will provide the items file before the 15th". The owner is surprised — "training was obviously included!" — and that's exactly the discussion needed upfront rather than as an end-of-project conflict.
Sequel to cases 1.1-1.2 — Bilal protects the SMART objective with a written boundary.
1. Drawing the line
Defining the scope means drawing a sharp line between what is included and what is excluded. It is one of project management's most protective acts.
Without a clear boundary, the project insidiously expands (scope creep) until it overflows schedule and budget.
2. Included, excluded, assumptions
Good scoping states three things explicitly: what is included, what is excluded ("this will NOT be in this project"), and the assumptions you rely on (what you take as true, to be confirmed).
Writing exclusions and assumptions matters as much as writing inclusions: that is what prevents misunderstandings.
🔎 Concrete example — 🔎 Concrete example — Writing what is excluded
The evidence that saves the relationship.
"This project does NOT include maintenance / training / data migration."
→ what seems obvious to you is not obvious to the client.
Written exclusions prevent end-of-project conflicts.Outcome: a bulwark against implicit expectations.
Reflex: get the scope validated by the sponsor.
Section vocabulary
- Scope
- Everything the project must deliver — and by contrast, what it will not deliver.
Simple example: Bilal's configured software and control inventory — and nothing else.
What it is not: a vague intention ("take care of stock").
Reflex: anything not written in is out.
- Scope creep
- Progressive, uncontrolled expansion of scope, overflowing schedule and costs.
Simple example: Three "small" orally added modules doubling Bilal's schedule.
What it is not: a signed amendment adding budget and schedule accordingly.
Reflex: count additions accepted this month — even small ones.
- Exclusion
- What is explicitly OUT of scope. Writing it avoids implicit expectations and misunderstandings.
Simple example: "NO warehouse staff training" written by Bilal.
What it is not: an unspoken point each side assumes "obvious" differently.
Reflex: write at least three exclusions, especially in grey areas.
- Assumption
- An element taken as true for planning (e.g. "the client will provide content on time"), to validate and monitor.
Simple example: "Items file provided by the accountant before the 15th" at Bilal's.
What it is not: a verified fact guaranteed by contract.
Reflex: each assumption gets a name, a date and a checker.
- Specification document
- Document detailing the project's requirements and expected scope.
Simple example: The software functional detail Bilal will have written after scoping.
What it is not: the one-page scoping note (too early for detail).
Reflex: scoping first (the why), detail next (the precise what).
In practice — In practice — Bounding a project's scope
- List what is clearly INCLUDED in the project (major features/deliverables covered).
- Explicitly list what is EXCLUDED ("does not include…"), especially grey areas where the opposite might be assumed.
- Note working ASSUMPTIONS (what you take as true) and who must confirm them.
- Get this scope validated by the sponsor: it is your bulwark against scope creep.
Ready-to-say script — answering an out-of-scope "small addition" (30s)
"Gladly, we'll look into it. Since it's outside the validated scope, I'll cost the schedule and money impact by tomorrow, and you decide. It protects us both — and keeps small additions from derailing June 30."
Say to the requester: neither blunt refusal nor oral acceptance — an assessment before any decision.
Copy-paste template — project scope sheet
INCLUDED (the project will deliver): _______________
EXCLUDED (does NOT include): _______________
ASSUMPTIONS (taken as true, confirmed by / when): _______________
OUT-OF-SCOPE REQUEST → change process (cost / schedule impact): yes
VALIDATED BY (name + date): _______________Small business / small project
Three lines are enough — included / excluded / assumption — but written: on small projects oral additions pass most unnoticed.
Remote / multi-site
Share the scope sheet in the common space and require every request in writing: spoken words on video calls are forgotten even faster than in person.
Algerian SME
Bilal has the owner read the exclusions aloud: when the boss himself says "no training included", nobody can claim otherwise at project end.
Fixed-price client contract
Attach the sheet to the contract: each out-of-scope addition becomes a costed amendment — scope creep gets paid, or doesn't happen.
✓ Best practices
- Write exclusions as much as inclusions.
- Note working assumptions and get them confirmed.
- Route every new request through the change process.
✗ Common pitfalls
- Defining only the included and leaving the excluded implicit.
- Accepting successive "small additions" (scope creep).
- Basing the schedule on never-validated assumptions.
Key takeaways
- Scope draws the line between included and excluded.
- Without a clear boundary, the project drifts (scope creep) and overflows.
- Writing EXCLUSIONS matters as much as writing inclusions.
- Assumptions (taken as true) must be validated and monitored.
48h Challenge — apply tomorrow
Write for a real project 3 explicit exclusions ("does NOT include…") and 2 assumptions with checker and date, then get them validated by the sponsor. 20 minutes is enough.
- I can explain scope creep with an example.
- I've written my project's exclusions (at least 3).
- My assumptions have a checker and a date.
Frequently asked questions
What is scope creep and how to avoid it?
It is the progressive addition of "small" requests which, cumulated, explode schedule and budget without anyone deciding so. Avoid it with a written, validated scope, explicit exclusions, and a formal change management process (section 3.3): every new request is assessed (cost/schedule impact) before being accepted or rejected. Scope creep is a major cause of overrun, all the more dangerous for being silent.
Why write what is excluded — isn't it obvious?
Precisely: what seems obvious to you is not obvious to the client. Writing in black and white "this project does not include maintenance / training / data migration" prevents implicit expectations and end-of-project conflicts. Exclusions are often the part that saves the client relationship. They turn an end-of-project disagreement ("but I thought it was included") into a framed upfront discussion.
What is "scope creep"?