Project Scope Template: Deliverables, Exclusions and Review Steps

What you can use
Copy a project scope worksheet with deliverables, exclusions, input dependencies, review limits, and a worked example for a small solo service project.

← All SoloHatch guides

SOLOHATCH FIELD GUIDE · OFFERS AND CLIENTS

Want to fill this in? Use the free Project Scope Builder to generate, copy, download or print your outline.

A useful project scope explains what will be produced, what inputs it depends on, how it will be reviewed, and what happens when the request changes.

Use the worksheet below to turn a broad request into a manageable piece of work. It is a planning document you can adapt to your service and discuss with the client. Confirm the commercial terms and any specialist requirements through the appropriate process for your project.

Choose your scope format

The outline is a planning aid. Confirm the deliverables, inputs, review route and commercial terms for your project before starting.

Ask about this resource or its downloads →

Copy this project scope template

PROJECT
Project name:
Client and main contact:
Date and version:

PURPOSE
The situation this project addresses:
Who will use the finished work:
How the client plans to use it:

DELIVERABLES
Item:
Quantity:
Format:
What “complete” means for this item:

INPUTS AND DEPENDENCIES
Required materials or decisions:
Who supplies each input:
Expected input dates:
What cannot proceed without them:

INCLUDED WORK
The activities needed to create the agreed deliverables:

EXCLUDED WORK
Related activities or outputs outside this project:

REVIEW AND APPROVAL
Who consolidates feedback:
Who gives final approval:
Included review stages:
What counts as a revision:
How new requests will be assessed:

TIMING
Proposed stages:
Dependencies affecting those stages:
How a delay will be communicated:

HANDOFF
Files, access, instructions, or other items to be delivered:
Who receives them:
What happens after handoff:

OPEN QUESTIONS
Decisions still needed before starting:

Describe an output that can be checked

“Improve the business” does not identify the work to deliver. “Prepare a two-page service overview using the approved descriptions” is easier to evaluate because the output, size, and input are visible.

Use completion checks tied to the work you control. A document might need the agreed sections, approved contact details, the correct file format, and readable text at its intended size. These checks can confirm the deliverable without promising that every reader will take a particular action.

Keep the purpose in the document because it guides choices. Keep it separate from the completion checks because a business aim may depend on traffic, timing, pricing, or decisions outside your project.

Filled example: a service overview PDF

Illustrative example: a solo designer is creating a service overview for a small consultancy. The quantities and stages below are planning choices for this example, not industry standards or customer results.

Purpose
Help prospective clients compare three existing services before a call.
Deliverable
One two-page PDF, plus an editable source file in the agreed format.
Inputs
Approved service descriptions, current prices, logo files, and contact details supplied by the consultancy.
Included work
Organize the approved text, create the page layout, and prepare the agreed handoff files.
Excluded work
Developing new services, changing prices, building a website, writing a separate email campaign, and arranging printing.
Review
One content-structure check and one layout feedback round, with one consolidated response at each stage.
Completion checks
All three services appear, supplied details are accurate, links work where applicable, and both agreed file types are delivered.

The important boundary is between arranging approved material and inventing the underlying service. If the client later asks for a new package, that request changes the input and the work. It deserves a separate decision rather than being absorbed invisibly into layout revisions.

Make exclusions useful to the reader

A long list of everything you do not do is difficult to use. Name the nearby tasks a client could reasonably assume are included. For a PDF project, editable files, copywriting, printing, and later updates may be worth discussing. For a website project, the nearby tasks will be different.

Pair a boundary with a route forward. For example: “This scope uses your approved service descriptions. If those descriptions need to be developed, we will define that work before proceeding.” The client can see both the limit and the next decision.

Use a change note when the request shifts

When a new request arrives, first determine whether it is a correction, an agreed revision, or additional work. The answer depends on the scope you actually agreed, not the label placed on the message.

  • Correction: the delivered work does not match an agreed input or completion check.
  • Included revision: the change fits the agreed output and review stage.
  • Additional request: the change adds an output, changes an approved input, or requires work beyond the agreed boundary.
CHANGE NOTE
Requested change:
Why it is needed:
Which agreed item it affects:
Effect on deliverables:
Effect on inputs, effort, price, or timing:
Options:
Decision needed from:
Work that can continue while this is decided:

In the example, correcting a mistyped supplied phone number is different from adding a fourth service and a new page. Write the effect of the latter request before agreeing to a new delivery date or price.

Clarify review stages before collecting feedback

A review round needs a purpose. A structure review asks whether the right material is included and ordered sensibly. A layout review checks the presentation of that material. Mixing every decision into every round can reopen work that the client thought was settled.

Ask for one consolidated response where practical, while allowing the client to gather input from their team. State how you will handle contradictory comments. A named approver makes the next decision visible; it does not make other people’s feedback irrelevant.

Check these points before starting

  • Can both people name the same final output?
  • Are quantity, format, and completion checks clear?
  • Are essential inputs available or assigned to someone?
  • Could a nearby task be mistakenly assumed to be included?
  • Is the feedback and approval route workable?
  • Is there a clear way to assess a changed request?

If a question remains open, keep it visible and decide whether it blocks the whole project or only one stage. Avoid using a polished document to hide an unresolved decision.

Your next step

Apply the worksheet to one upcoming project and ask the client to explain the scope back in their own words. If their description adds an output or assumes a different review process, resolve that difference before starting.

Use the client intake form template to gather the necessary inputs, and the first sellable offer guide when the service itself still needs a narrower boundary.

This guide was developed with AI assistance. Examples are illustrative, and templates should be adapted to your situation. SoloHatch is operated by My Target Limited. About SoloHatch · Browse all guides