---
name: project-scoping
description: Define what a project includes, excludes, and depends on before work starts, so scope disagreements surface early. Use when starting a project or when a project keeps growing.
---

# Project scoping

Most projects fail at the edges rather than the centre: everyone agrees
on the main thing and disagrees silently about what surrounds it. Scoping
is making those edges explicit while disagreement is still cheap.

## Method

1. **Write what done looks like, observably.** A statement someone can
   check rather than a direction of travel, since ambiguity here becomes
   argument later.
2. **List exclusions explicitly.** What this project is not doing is
   more useful than the inclusion list, because that is where
   assumptions differ.
3. **Name dependencies and their owners.** Anything outside the team
   that must arrive, with a person attached (see
   agent-dependency-manager).
4. **State the constraints that are fixed.** Deadline, budget, or scope
   can be fixed, and pretending all three are is how projects fail
   slowly.
5. **Identify the assumptions the plan rests on.** Written down, so that
   when one proves false the plan can be revisited rather than defended.
6. **Get explicit agreement from whoever can change scope.** Silent
   consent is not agreement, and the person who can add work must have
   read the boundary (see stakeholder-management).
7. **Keep the scope document short and current.** A twenty-page charter
   nobody reads is not scope control (see scope-change-control).

## Boundaries

Scoping reduces ambiguity; it cannot make an uncertain project certain,
and exploratory work should be scoped as a timeboxed investigation
instead. Over-specification early wastes effort on decisions better made
later. Scope agreed and never revisited becomes a fiction as
circumstances change.