- In-Scope: My responsibilities as a project
- Out-Of-Scope: Things that will not be delivered or considered
- Dependent-Scope: Other people's responsibilities, that my project relies on
Explicitly structuring your scope statements around which 'dimension' of scope they refer to can make your scope clearer, encourage you to think about the projects in different ways, and make a point unavoidable by restating it from three or four different angles.
Each "dimension" of scope is a single narrow class of items that may be in or out of scope. I've listed a partial brain-dump of the dimensions you could use below.
- Problem: User issues to address or ignore
- Functional: User facing features that are included or excluded
- Non-Functional Requirements: All non-functional requirements can be part of scope, either as area we are targetting to improve, or where we make no promises. (Note that I'm a big fan of phrasing these as negative NFRs - things we can do without is what drives intelligent compromise.)
- System: Which technical systems we are responsible for, or will not change
- Interfaces: System interfaces or integrations that we take responsibility for changing, or normally rely on others for
- Activity: User activity or tasks considered, or ignored (Useful as part of a process when you highlight activities to automate or stay manual)
- Users/Customers: Which user bases are considered, and which excluded
- Organisational: Parts of the organisation whose issues and needs are in scope - very useful when deciding stakeholder and interview lists.
- Legislative: Which parts of law are to be complied with, or whose compliance is a main point of the program
- Deliverables: What documents, sing-offs, or artefacts are included
- Detail: How much details (Descriptive vs Prescriptive) will be included
- Supporting: Which activities or systems will be able to function based on our delvierables. This one's quite useful to say you will produce just-enough to support a particular activity or example (say, estimation) but not enough for another (say, full-build)