Project scope template that survives the project.
The scope document an agency or studio actually needs: one objective, an explicit in-scope and out-of-scope list, deliverables with owners, dates and acceptance criteria, the assumptions the dates depend on, and a sign-off that says who accepted it and when. Copy it as CSV and use it on the next project.
The template, filled with an example
The example is a website redesign for a fictional client, with five deliverables across eleven weeks. Change the names, the dates, and the deliverables — keep the structure.
Illustrative example only. The client, the project lead, the project code, and every date on this page are invented for illustration. This is not a real engagement and the names are not real companies.
Project header
- Project name
- Sample Client website redesign
- Project code
- PRJ-2026-018
- Client
- Sample Client Private Limited (example)
- Project lead
- Sample Delivery Lead (example)
- Start date
- 05-10-2026
- Target go-live
- 18-12-2026
- Quotation reference
- QTN-2026-0142
- Commercial basis
- Fixed scope, quoted amount, milestone payments
- Review cadence
- Weekly 30-minute review, Thursdays
In scope
- 6 page templates: home, about, services, three case studies.
- Responsive layout for the agreed device list, agreed at kickoff.
- CMS templates for the 6 pages, with the client's existing users imported.
- Up to 40 pages of client-supplied content loaded and formatted.
- One training session of up to 90 minutes for up to 5 client users.
Out of scope
- Content writing, editing, translation, or translation review.
- Photography, video, illustration, or any other commissioned creative work.
- Paid media, search advertising, or ongoing marketing.
- Hosting, domain registration, licences, and third-party subscription costs.
- Accessibility audit beyond the checks listed in the acceptance criteria, and any remediation work.
- Work arising from a change to the agreed scope — quoted separately before it starts.
Deliverables, owners, dates, and acceptance criteria
| ID | Deliverable | What it includes | Owner | Due | Accepted when |
|---|---|---|---|---|---|
| D1 | Sitemap and wireframes | Up to 6 page templates, low-fidelity, client comments captured in one pass | Design lead | 23-10-2026 | Client confirms the structure and the page list in writing |
| D2 | Visual design | Desktop and mobile layouts for the 6 templates, design system documented | Design lead | 13-11-2026 | Client signs off two screens as the visual standard |
| D3 | Front-end build | Responsive build against the approved design, browser support as agreed | Build engineer | 27-11-2026 | All templates pass the agreed device list |
| D4 | CMS integration and content load | Templates connected to the CMS, up to 40 pages of client-supplied content loaded | Build engineer | 11-12-2026 | Client editor can publish a test page without help |
| D5 | Launch checks and handover | Search and analytics setup, one training session, handover document | Delivery lead | 18-12-2026 | Go-live confirmed in writing by both sides |
Assumptions and dependencies
- Client provides content on time
- Content arrives in the agreed format by the date stated against the dependent deliverable. Dates move with the content, not the other way round.
- One round of revisions per deliverable
- Revisions are consolidated into one list. A second round of structural redesign is a change request, not a revision.
- Access and environments ready
- Client provides CMS, hosting, and domain access at kickoff, not halfway through the build.
- Named approver per deliverable
- One named person on the client side can approve or reject each deliverable, and tells us who it is.
Change control and sign-off
Anything outside the scope above is raised as a change request, priced before the work starts, and approved by the client-side approver named here. See the change request template for the form.
- Client-side approver
- Name / role (example)
- Vendor-side owner
- Name / role (example)
- Scope accepted on
- DD / MM / YYYY
- Review cadence
- Weekly, Thursdays
Project scope template (CSV — illustrative example data) Field,Value Project name,Sample Client website redesign Project code,PRJ-2026-018 Client,Sample Client Private Limited (example) Project lead,Sample Delivery Lead (example) Start date,05-10-2026 Target go-live,18-12-2026 Quotation reference,QTN-2026-0142 Commercial basis,"Fixed scope, quoted amount, milestone payments" In scope "6 page templates: home, about, services, three case studies." "Responsive layout for the agreed device list, agreed at kickoff." "CMS templates for the 6 pages, with the client's existing users imported." Up to 40 pages of client-supplied content loaded and formatted. One training session of up to 90 minutes for up to 5 client users. Out of scope "Content writing, editing, translation, or translation review." "Photography, video, illustration, or any other commissioned creative work." "Paid media, search advertising, or ongoing marketing." "Hosting, domain registration, licences, and third-party subscription costs." "Accessibility audit beyond the checks listed in the acceptance criteria, and any remediation work." Work arising from a change to the agreed scope — quoted separately before it starts. ID,Deliverable,Description,Owner,Due,Acceptance criteria D1,Sitemap and wireframes,"Up to 6 page templates, low-fidelity, client comments captured in one pass",Design lead,23-10-2026,Client confirms the structure and the page list in writing D2,Visual design,"Desktop and mobile layouts for the 6 templates, design system documented",Design lead,13-11-2026,Client signs off two screens as the visual standard D3,Front-end build,"Responsive build against the approved design, browser support as agreed",Build engineer,27-11-2026,All templates pass the agreed device list D4,CMS integration and content load,"Templates connected to the CMS, up to 40 pages of client-supplied content loaded",Build engineer,11-12-2026,Client editor can publish a test page without help D5,Launch checks and handover,"Search and analytics setup, one training session, handover document",Delivery lead,18-12-2026,Go-live confirmed in writing by both sides Assumption / dependency,Detail Client provides content on time,"Content arrives in the agreed format by the date stated against the dependent deliverable. Dates move with the content, not the other way round." One round of revisions per deliverable,"Revisions are consolidated into one list. A second round of structural redesign is a change request, not a revision." Access and environments ready,"Client provides CMS, hosting, and domain access at kickoff, not halfway through the build." Named approver per deliverable,"One named person on the client side can approve or reject each deliverable, and tells us who it is."
The deliverable table is the part worth copying most carefully. Every row has an owner, a date, and a sentence the client can answer yes or no to — which is what turns “we are waiting on feedback” from an opinion into a date that moved.
How to fill it in
Four steps, before the first kickoff meeting rather than during it.
Write the objective in one sentence
If the objective needs a paragraph, the project is not scoped yet. One sentence you could repeat to anyone on the team and get the same answer.
List what is in, then list what is out
The out-of-scope list is the more valuable half. Include the things clients habitually assume are included — content writing, hosting, photography, training beyond the first session — and put it in language the client will actually read.
Break the work into deliverables, not activities
A deliverable is something that gets accepted. “Design” is an activity; “visual design for 6 templates, accepted against two reference screens” is a deliverable with a date and a test.
Name an owner and an approver per deliverable
An unowned deliverable has no date. An unapproved deliverable has no finish. Write down the client-side approver too, or the review meeting becomes a search for authority.
When to use this, and when to stop
Every service business needs a scope. What changes is where it lives and who can change it.
When this template is the right tool
- You run a handful of projects a year and the scope lives in your head or in a chat thread.
- You want one shared definition of what is included, so the same question is not re-answered on every project.
- You are still learning which exclusions save you the most time, and writing them down is how you find out.
- You hand projects to someone else, and they need the scope to be readable without you in the room.
When you have outgrown it
- Scope is agreed verbally and reconstructed later from memory, whichever side remembers it more conveniently.
- Changes arrive as requests, get absorbed, and only surface as a margin problem months later.
- You cannot say, for one project, what was promised, what was delivered, and what was billed against.
- Several people edit the scope document and there is no single current version anyone can point at.
The same process in NoxOrigin
A won opportunity becomes a project with the client, the scope, and the commercial context already attached — no re-keying at hand-off. Deliverables, tasks, and assignments live on the project, scope changes are raised and priced as records rather than as messages, and quoted value stays comparable to billed and collected value so under-quoted projects surface before the work is finished.
- Projects & Work in NoxOriginProjects, tasks, assignments, and recurring follow-ups held against the client and the opportunity that created the work.
- Sales to project hand-offCarries the client, scope, contacts, and commercial context from a won opportunity into delivery instead of rebuilding it.
- Project profitabilityQuoted value against billed value per project, so unbilled and under-quoted scope becomes findable.
- Project profitability calculatorCompare quoted value plus approved change orders against direct cost and internal hours.
- Change request templateWhat to raise the moment something arrives that is outside this scope.
- Client onboarding checklistThe commercial and access steps that have to happen before the first deliverable can start.
Project scope template questions
Why does the template separate in-scope from out-of-scope?
Because the out-of-scope list is the part that does the work later. Most scope disputes are not about whether the client asked for something; they are about whether anyone said the request was outside the agreed scope and priced it. Writing the exclusions down, at the start, in language the client agreed to, is what makes a change request a normal part of the project instead of a confrontation.
What should an acceptance criterion actually say?
Something a person can check and answer yes or to, without interpretation. “Client confirms the structure in writing” is testable. “Design is good quality” is not, and it will be re-argued at the moment it is most expensive. Each deliverable in the example carries one because acceptance is where a project either closes or drifts.
Do I need this if I already send a detailed quotation?
A quotation states what you will do and what it costs. A scope states what the project is allowed to contain while it is being done — the exclusions, the assumptions, the acceptance criteria, and who approves. They are different documents answering different questions, and a project that has only one of them tends to run on memory.
Should the scope be signed or just sent?
Signed, or acknowledged in writing by email against a named approver. The signature is not the important part; the record of who accepted the scope and when is. That record is what you point at when a later request arrives and the conversation turns to whether it was included.
Write the scope once. Stop re-explaining it later.
If scope, delivery, invoicing, and collection are currently in four different places, the hand-off between them is the thing worth mapping.