Download the scope of work template and change register
The text download includes an original completed planning example and a blank form. The CSV records four fictional change requests, affected deliverables, assessment questions, and unresolved decisions. Both files are available without registration.
The example concerns BriefRelay's fictional client-intake handoff. It defines planned outputs rather than work actually delivered. The resource contains no payment terms, signature block, or completed agreement.
Use it to prepare a concrete delivery conversation. Replace the example with your project, name the actual decision and delivery owners, and connect its scope version to the document or agreement that governs the work.
What is a scope of work?
A scope of work defines the work's delivery boundary: outputs, included and excluded work, responsibilities, assumptions, dependencies, and acceptance expectations. It gives a team or supplier a shared basis for discussing what belongs in the project.
Asana distinguishes that scope from a broader statement of work, which can also include contractual and administrative terms. Terminology varies, and scope can be one section of a larger document. Read the actual governing agreement before assuming a template defines an obligation.
For a SaaS project, an output such as an authorized intake receipt is more assessable than a promise to improve client experience. The broader outcome can explain the purpose, while the deliverable states what the work should produce.
Describe outputs that a reviewer can recognize
BriefRelay's fictional scope contains four deliverables. D-1 is the permitted submission path, D-2 the receipt path, D-3 the support handoff, and D-4 the user guidance. Each has a stable ID and a proposed acceptance responsibility.
D-1 includes a required title, agreed file types, and a visible rejection path. D-2 includes a stable submission reference that remains scoped to the authorized requester. D-3 covers status lookup and an exception runbook without exposing private file contents.
D-4 includes one help article and a short training walkthrough that follow the recorded candidate. Those outputs matter because a working interface may still leave customers and Support unsure how to recover from a rejected submission.
Give each deliverable a boundary and review question. That makes it easier to assess a proposed change or identify a missing prerequisite without debating whether a vague description sounded complete.
| Deliverable | Included output | Proposed acceptance responsibility |
|---|---|---|
| D-1 Submission path | Required input, permitted types, rejection recovery | Product reviews Engineering's evidence |
| D-2 Receipt path | Stable reference and scoped access | Product reviews ordinary and denied-access cases |
| D-3 Support handoff | Status lookup and exception runbook | Support rehearses one recovery scenario |
| D-4 User guidance | Help article and walkthrough | Support reviews the steps against the candidate |
State exclusions and dependencies
The example excludes payments, a replacement identity provider, unrestricted file formats, a custom CRM, production data migration, and ongoing response-time commitments. These limits make the small delivery decision easier to understand.
An exclusion should describe a real boundary, not hide work needed to complete an included output. If the receipt requires a stable reference mechanism, the scope must say whether that mechanism already exists, is included, or is an unresolved dependency.
The exercise assumes an agreed identity context, staging file store, workspace-scoped identifiers, synthetic fixtures, and available reviewers. Name who supplies each input and how the team will respond if it is unavailable.
Keep assumptions revisable. An unavailable dependency can affect delivery sequence, verification, ownership, or the decision to continue. Record the effect before substituting a different workflow that changes the meaning of the original scope.
Make acceptance and handoff observable
Acceptance needs an observation and a reviewer. For D-2, an authorized requester should see the correct accepted reference, and an unrelated workspace should not retrieve that receipt. The relevant evidence must identify the candidate and environment.
Use the acceptance criteria guide to make those expectations specific. A statement such as stakeholder is happy leaves the important behavior, review process, and unresolved questions unclear.
Define handoff contents as well as product behavior. The example calls for the candidate identifier, deliverable list, verification references, open issues, support owner, and recovery instructions. The receiving person needs enough context to use and maintain what is delivered.
Delivery and acceptance are separate events. Record the actual review decision and date when they exist. A completed example in a planning template should not be treated as evidence that a real reviewer accepted an implementation.
Handle a change before it becomes an implied commitment
CR-1 asks to send each accepted intake to a CRM. That request adds an external contract, identity mapping, repeated-delivery behavior, support responsibility, and new verification. It is more than a sentence appended to the existing submission deliverable.
The fictional register marks CR-1 Deferred for impact review. The requested outcome is recorded, while implementation and dates remain undecided. The owner needs to assess the changed boundary, resources, sequence, dependencies, and evidence before choosing a revised scope.
CR-4 asks to revise receipt wording after an unclear walkthrough. Even a smaller change deserves classification: is it clarification of the agreed behavior, or a new expectation? Record the reason and affected version so the answer remains traceable.
Use a short change record with requester, outcome, reason, affected IDs, impact, decision owner, decision, date, and revised scope version. The register supports the decision process; entering a request does not itself authorize or schedule the work.
Connect the scope to adjacent planning documents
The project charter records the project's purpose, authorization, and high-level boundaries. The scope of work gives the delivery boundary more detail. A PRD explains the product behavior and relevant edge cases.
The work breakdown structure decomposes agreed outputs into smaller packages. A schedule can then sequence them. Keeping IDs connected helps the team see which acceptance observations and tasks belong to a changed deliverable.
Document names are less important than the questions they answer. A very small internal change may need one concise record rather than several copied documents. Preserve the important decisions without creating competing versions of the same requirement.
If a supplier or customer agreement governs the project, align the scope with its actual review and change process. This planning resource does not establish the required contractual terms or who has authority to bind an organization.
Review the scope before starting and at handoff
Read the included outputs, exclusions, prerequisites, acceptance responsibilities, and change path together. Ask each owner to identify an unclear assumption. A missing decision is more useful when it is visible before execution than when it becomes a dispute at handoff.
At delivery, compare the actual artifact and evidence with the current scope version. Record unresolved work and its owner. Keep a new request separate from a defect against an already agreed acceptance expectation.
The downloads were checked for consistent D-1 through D-4 references, explicit fictional labels, and change states that preserve unmade decisions. No BriefRelay project was approved, delivered, or accepted as part of creating these resources.
Sources and original exercise checked October 28, 2026. A useful scope makes the next delivery and review decisions concrete enough for the people responsible to assess.