How to Write a Construction Scope of Work

Most construction disputes do not start with bad materials or bad crews. They start with a "we thought that was included" conversation halfway through the job. A scope of work makes the build concrete before the first wall comes down, so homeowners and contractors both know what is being done, in what order, and for how much. Change orders should be the exception that gets written down, not the default way the project actually runs.

← Back to Scope of Work Guide

This is what a scope of work looks like in OpenLedger

What to include in a construction 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 construction scope of work should cover.

1. Define your deliverables

List every phase of the build as its own line item, not one lump "renovation" entry. Be specific about materials, finish level, and what done looks like for each phase. "New kitchen" means something different to every homeowner. "Shaker-style cabinets, quartz countertops, tile backsplash installed" does not. Include the unit type for each deliverable: are you tracking days, square footage, fixtures, rooms? That unit is what you are pricing and scheduling around.

2. Set a timeline with milestones

Attach dates to each phase, not just a single completion date. Construction has dependencies, framing has to finish before electrical, electrical before drywall, so milestone dates double as a sequencing check. A project end date with nothing between it and the start date will not tell you if the job is on track until it is already behind.

3. Define what is out of scope

This is the section that prevents the most arguments on a job site. If a homeowner might reasonably assume something is included, write it down as excluded if it is not. "Does not include permit filing." "Does not include appliance procurement." "Does not include structural engineering review." Explicit exclusions protect the contractor from scope creep and protect the client from surprise change orders.

4. Agree on acceptance criteria

How does the homeowner sign off on each phase? "Client approval" is too vague, approval within how many days, based on what inspection, with what recourse if something does not meet spec? A brief acceptance clause per phase prevents a final walkthrough from turning into a renegotiation.

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 construction scope of work documents

Writing the scope after demo has already started. A retroactive scope is a record of what happened, not an agreement about what would happen. You lose the alignment before the first swing of the sledgehammer.
Using "and any related work" language in the contract. This phrase exists to sound flexible and ends up being a blank check for change orders. If it is related, name it. If you cannot name it yet, say so explicitly.
Not versioning the scope when the client adds requests mid-project. Scope changes on almost every job. The original agreement stays real; additions should be logged as amendments with their own price, not quietly folded into the existing budget.
Tying payment to project completion instead of phase delivery. A single payment on completion is where scope disputes become payment disputes, and on a months-long build, that is a long time for a contractor to carry unpaid work.

How payment should tie to a construction scope of work

One of the most common structural mistakes in contractor work is tying payment to a single completion date rather than to each phase as it is finished. When payment is milestone-based, a framing crew gets paid when framing is done, not when the whole house is done six weeks later. Incentives stay aligned: the crew delivers, the client pays, the job keeps moving. When payment is tied to "project completion," you get disputes about what completion means, unpaid change orders, and a power imbalance that favors whoever controls the final sign-off.

The fix is the same one that applies to any industry: every deliverable in your scope of work should have a price attached to it, not just a total project budget. That way, if the scope changes, the cost of that change is already clear, and if a phase is finished and not paid for, the record already exists. This is the structure OpenLedger is built around.