Free scope of work template for service projects

The file, plyntum-scope-of-work-template.docx, opens in Word, Google Docs and Pages. It has ten sections:

1. Parties and project: client, provider, project name, dates and a project lead on each side.
2. Background and objectives: why the work is needed and what success looks like.
3. Deliverables: a table with each deliverable, its description, acceptance criteria and due date.
4. Out of scope: what the project does not include.
5. Timeline and milestones: dates, and which milestones trigger a payment.
6. Assumptions and client responsibilities: content, access, feedback rounds and revision limits.
7. Fees and payment: the pricing model, a payment schedule, the hourly rate for extra work and payment terms.
8. Change requests: how a change is requested, priced and approved, with a change log.
9. Acceptance: when a deliverable counts as accepted.
10. Sign-off: name, position, signature and date for both sides.

The example text in square brackets comes from a website project. Replace it with your own.

1. Start from the outcome. Write two or three sentences on why the client wants the work. Every deliverable should serve that aim; anything that does not belongs on the out-of-scope list.
2. List deliverables as things you hand over. “Homepage design, desktop and mobile” can be accepted or rejected. “Design support” cannot.
3. Give each deliverable an acceptance criterion. Say who approves it and how: a written approval, a passed test, a live URL.
4. Write the exclusions. The out-of-scope list prevents more arguments than any other section. Name what clients often assume is included: copywriting, stock images, hosting, extra languages.
5. Limit feedback and revisions. One consolidated round of feedback per deliverable and a fixed number of revision rounds keep the timeline honest.
6. Tie payments to milestones. A deposit and payments on approved milestones keep cash moving and give both sides a checkpoint.
7. Agree how changes work before you need it. A written request, an answer on price and timeline within a set number of days, and approval from both project leads.
8. Sign before work starts. A scope signed after the first week describes what already happened, not what was agreed.

The terms overlap, and teams use them differently. A common split:

• Proposal: sells the project. It explains the approach and the price and is written before the client says yes. See the free project proposal template.
• Scope of work: describes the work itself: deliverables, exclusions, acceptance and changes. It is the document the team works from.
• Statement of work (SOW): usually a more formal document that adds fees, schedule and terms to the scope of work, often attached to a master agreement. This template can serve as a simple one.
• Contract or master services agreement: sets the legal terms, such as liability, intellectual property, confidentiality and termination. The template does not replace it.

This template is not legal advice. If the scope will be binding, have it reviewed against your contract and local law.

The example text in the file follows one project. It shows the level of detail that prevents disputes:

A signed scope protects you only if someone notices when the work drifts from it. Most drift arrives as small requests: one more banner, a quick call, another revision. For the patterns and how to stop them, read scope creep: what it is, examples and how to prevent it; for pricing the extra work, read how to bill for scope creep.

In PLYNTUM the agreed scope sits with the client and the project. Each request has an owner and a recorded decision, and an accepted request becomes a task with the client and files attached. People record time against tasks on every plan; from Core, approved time becomes project cost, so you can see what a change cost against the budget. PLYNTUM does not write proposals, scopes or contracts: the scope document itself stays in Word or Google Docs.