Scope and Boundaries: The Two Lists Every Project Needs
Most projects don't fail because someone did the wrong work — they fail because nobody ever wrote down which work was the right work. Here's how to define inclusions and exclusions that actually hold up under pressure.
4 min read
There's a particular kind of project death that happens slowly. Nobody makes a bad decision. No one misses a deadline dramatically. Instead, a week before launch, someone in a review meeting says "wait, isn't the mobile version part of this?" and the room goes quiet. The mobile version was never discussed. It was never excluded either. It simply lived in the gap between what was written down and what people assumed — and that gap is where projects go to die.
Scope is not paperwork. Scope is the shared hallucination your team agrees to have about what you're building. The job of a scope document is to make that hallucination identical in everyone's head, and the only reliable way to do that is with two lists, not one.
The Inclusions List: Be Boringly Specific
Most teams write inclusions at the wrong altitude. "Redesign the checkout flow" is not scope — it's a headline. Scope is what happens when you force yourself down to the level where reasonable people can no longer disagree about what's being delivered.
A usable inclusions list looks like this:
Deliverable, not intention. "Three checkout screens: cart, payment, confirmation" beats "improved checkout experience."
Environments and platforms named. Desktop web only? Say so. Chrome and Safari but not IE? Say so.
Quantities where quantities exist. "Two rounds of design revision." "Migration of the last 24 months of order data." Numbers are boundaries in disguise.
Acceptance criteria attached. How will we know this item is done? If nobody can answer, the item isn't scoped — it's just a wish.
The test is simple: hand the list to someone who wasn't in the kickoff. If they can build a mental picture that matches yours, you've written scope. If they have to ask you three clarifying questions, you've written a headline.
The Exclusions List: Where the Real Work Happens
Here's the uncomfortable truth — your inclusions list will never be complete enough to defend itself. Requirements are infinite; your list is finite. Everything you didn't mention lives in an ambiguous zone where a stakeholder can plausibly say "well, I assumed."
That's what the exclusions list is for. It's not pessimism, it's precision. Write down the things people are most likely to assume are included:
Adjacent surfaces. "This project covers web checkout. Native app checkout is out of scope."
The obvious next step. "We are building the reporting API. The reporting dashboard UI is a separate project."
Ongoing work after delivery. "Post-launch monitoring, content updates, and SEO optimisation are not included."
Things that were discussed and cut. This is the most valuable category. If someone raised multi-currency support in kickoff and the team decided against it, that decision belongs in writing — otherwise it will resurface in week six as if it were always agreed.
Exclusions don't make you look inflexible. They make you look like someone who was listening. And when a genuine change request arrives later, you have a clean baseline to change from, which is the only thing that makes a change request negotiable instead of a fight.
The Counterpoint: Rigid Scope Can Be Its Own Failure
It's worth saying plainly: a scope document defended too hard becomes a monument to what you believed on day one. Markets shift. Users behave unexpectedly. A competitor ships something that makes your third deliverable irrelevant. Teams that treat their scope as sacred sometimes deliver exactly what was agreed and exactly what nobody needs anymore.
The distinction isn't between rigid and flexible — it's between controlled change and uncontrolled change. Scope creep isn't "the requirements changed." Scope creep is "the requirements changed and nobody adjusted the timeline, the budget, or the expectations." A healthy project has a visible door for new work: a request comes in, someone assesses the impact, a decision is made and recorded. This is why intake matters as much as planning. In Casperry, new work arrives as a structured Request rather than a Slack message, and each project keeps a Source view showing the requests and events that led to it — so when someone asks "why are we building this?" six weeks in, there's an actual answer instead of an argument.
Making Boundaries Stick
A scope document that lives in a shared drive is a scope document nobody reads. Boundaries only hold when they're attached to the daily surface where work actually happens — the board, the tasks, the timeline. Two habits make the difference. First, name one accountable person per scope area, not a committee; ambiguity about ownership is how out-of-scope work quietly gets started by someone being helpful. Tools that enforce a full RACI on each task — exactly one Accountable, everyone else Responsible, Consulted or Informed — make that structural rather than cultural. Second, keep the exclusions list somewhere visible, not buried in a kickoff deck. A short "Not in this project" section in a shared doc, reviewed at every milestone, will save you more hours than any estimation technique.
The goal was never to say no to everything. It's to make sure that every yes is deliberate, priced, and visible to the people who'll have to live with it.
If you're tired of scope decisions scattered across email threads and half-remembered meetings, Casperry keeps intake, planning and ownership in one place — worth a look next time you're setting boundaries on a project.