How to Write a Scope of Work

Most project disputes do not start with bad intentions. They start with an agreement that was not specific enough about what was actually getting built. A scope of work makes the agreement concrete before the work begins, so clients and contractors both know what is being delivered, when, and for how much. Transparency up front is cheaper than a dispute after the fact.

This is what a scope of work looks like in OpenLedger

What to include in a scope of work

A good scope of work does not need to be long. It needs to be specific. Here are the four things every scope of work should cover.

1. Define your deliverables

List every output the project will produce. Be specific about format, quantity, and what done looks like for each item. Vague deliverables invite disagreement: "website" means something different to everyone. "Five-page responsive website with a contact form and CMS" does not. For each deliverable, include the unit type: are you delivering screens, features, endpoints, hours? That unit is what you are pricing and tracking.

2. Set a timeline with milestones

Attach dates to each deliverable, not just a single project end date. Milestone-based timelines give both parties checkpoints to catch drift early, before it compounds into a deadline problem or a billing dispute. A project end date with nothing between it and the start date is not a timeline. It is just a deadline.

3. Define what is out of scope

This is the section most people skip, and it is the one that causes the most problems. If a client might reasonably expect something to be included, write it down as excluded if you are not doing it. "Does not include SEO optimization." "Does not include copywriting." "Does not include hosting setup." Explicit exclusions are not rude; they are protective for both sides.

4. Agree on acceptance criteria

How will both parties know when a deliverable is done? "Client approval" is too vague: approval within how many days, based on what criteria, with how many revision rounds? A brief acceptance clause prevents open-ended revision loops and gives the contractor a clear path to getting paid.

Scope of work templates: Construction Scope of Work · Consulting Scope of Work · Marketing Scope of Work · Software Development Scope of Work

Scope of work vs. statement of work

A scope of work is the part that says what is actually going to get built or delivered: the tasks, the milestones, the boundaries of the project. A statement of work is the bigger document that a scope of work often lives inside, alongside things like pricing, payment terms, and timelines. In everyday use, people say the two almost interchangeably, and that is fine. What actually matters is getting the deliverables written down clearly, however you label the document. That is what this guide, and OpenLedger, are built around.

Build your own scope of work

OpenLedger gives you a live, shareable deliverables ledger, not a static document. Enter your email to get started.

Common mistakes in project scope of work documents

Even experienced contractors repeat the same avoidable mistakes. Here are the ones that cause the most damage.

Writing the scope after the work has started. A retroactive scope is not really a scope. It is a record of what happened. You lose the whole point, which is alignment before you build anything.

Using "and any other related tasks" language. This phrase exists to seem helpful and ends up being a blank check. If it is related, define it. If you cannot define it yet, say so explicitly.

Not versioning the document when scope changes. Scope always changes. The original agreement is still real; any additions or changes should be documented as amendments, not silently absorbed.

Tying payment to project completion instead of milestone delivery. This is covered in more detail below, but it is common enough to name here. Single-payment-on-completion is where scope disputes go to become payment disputes.

How payment should tie to a project scope of work

One of the most common structural mistakes in freelance and contractor work is tying payment to a single completion date rather than to individual deliverable milestones. When payment is milestone-based, both parties have aligned incentives: the contractor delivers, the client pays, and the project moves forward. When payment is tied to "project completion," you get disputes about what completion means, scope creep goes uncompensated, and the power balance shifts entirely toward whoever controls sign-off.

The fix is simple: every deliverable in your scope of work should have a price attached to it. Not just a total project budget, but a per-deliverable price that both parties agreed to before the work began. That way, if scope changes, the financial implication is already clear. If work is completed and not paid for, the record is already there.

This is the structure OpenLedger is built around. Every deliverable has a unit, a unit price, and a timeline. The financial agreement is as specific as the creative one, because that is the only version that actually protects both sides.