Amey-Thakur 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
- Write what done looks like, observably. A statement someone can check rather than a direction of travel, since ambiguity here becomes argument later.
- List exclusions explicitly. What this project is not doing is more useful than the inclusion list, because that is where assumptions differ.
- Name dependencies and their owners. Anything outside the team that must arrive, with a person attached (see agent-dependency-manager).
- State the constraints that are fixed. Deadline, budget, or scope can be fixed, and pretending all three are is how projects fail slowly.
- Identify the assumptions the plan rests on. Written down, so that when one proves false the plan can be revisited rather than defended.
- 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).
- 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.