Start with the outcome, not a task list
Scope is the agreed boundary around a project: the work the team intends to do and the work it does not intend to do. Without that boundary, a reasonable request can quietly turn into a new assignment. A logo project might grow into packaging design; a class website might grow into a full content migration. Naming the boundary early helps everyone plan time, feedback and handoff.
Begin with one or two sentences describing the intended outcome and who it serves. For example: “Create a five-page portfolio site that helps prospective clients understand the designer’s services and make contact.” This gives the scope a purpose. You can then judge proposed tasks against it instead of treating every related idea as a requirement.
Write the in-scope list in deliverable terms
An in-scope list should describe outputs and the work needed to produce them. For the portfolio site, it might include a page structure, designs for five named pages, implementation using an agreed platform, a contact form and a basic check on common screen sizes. State who supplies inputs such as text, images and access credentials. “Build the site” is too broad if one person assumes it includes writing every page while the other expects to provide finished copy.
Add enough detail to make completion recognizable. Specify the formats for final files, where they will be delivered and what review is included. A freelancer might offer two rounds of consolidated feedback on page designs. A student team might agree to submit a working prototype and a short explanation of design decisions. These details need not predict every task; they should clarify what a finished handoff looks like.
Make the out-of-scope list specific and neutral
Out-of-scope statements work best when they name plausible requests, not vague exclusions such as “anything extra.” For the same site, the list could say that copywriting, a new logo, ongoing maintenance and adding pages beyond the five agreed pages are not included. These items may be valuable, but they require their own decision about time and responsibility. An exclusion is a planning tool, not a judgment about whether an idea is good.
Look especially for work that sits beside the main deliverable. A video editor may need to distinguish editing supplied footage from filming new material. A small team preparing a product demo may include a clickable prototype but exclude a production-ready application. If a task is likely to be assumed by one party and overlooked by another, give it an explicit place on either the in-scope or out-of-scope list.
Check the boundary against people, time and dependencies
Before work begins, walk through the scope with the people who will approve or contribute to it. Ask what they expect to receive, what they expect to provide and how they will know the work is complete. Compare their answers with the brief. This conversation can reveal gaps that a task list misses, such as who chooses the final images or who tests the contact form after launch.
Record assumptions and dependencies alongside the boundary. If a design depends on receiving approved copy, say so. If the schedule allows for one reviewer to collect comments from a larger group, name that process. A boundary is only useful when it reflects the way the project will run. Keep the agreed version in a shared, easy-to-find document so collaborators are checking the same reference.
Give new requests a route, not an automatic yes or no
New ideas will appear after work starts. When they do, compare each request with the stated outcome, deliverables and exclusions. If it fits within the agreed work, clarify any effect on priorities. If it changes the boundary, describe what would need to change: the deliverable, schedule, workload or something else. For example, adding a sixth page may mean removing another page from the first release or agreeing on a separate phase.
Update the brief when a change is accepted, including who made the decision. This prevents an informal conversation from becoming a different memory for each collaborator. At delivery, use the scope as a final check: show what was completed, note any agreed changes and identify ideas left for later. The aim is not to make a project rigid. It is to make choices visible so the finished work matches a shared understanding.
