Statement of work scoping
Statement of work scoping converts a vague client request into a document you can price, sign, and deliver against. Kodelytics runs requirements discovery, builds the effort estimate, and writes the assumptions, exclusions, acceptance criteria, and milestone structure that decide whether a fixed-fee project makes money or loses it.
A statement of work is a commercial instrument, not paperwork. The margin on a fixed-fee project is decided before anyone writes code — in whether the estimate reflected real effort, whether the exclusions were written down, and whether acceptance was defined tightly enough that the client and the team agree when the work is finished. Agencies lose money on underscoped projects far more often than on badly built ones.
The tell is that overruns are always explained in delivery language — the team was slow, the client was difficult, requirements moved — when the cause is almost always upstream. Delivery discipline is hard to change and slow to improve. A scope document is a two-week habit change with immediate financial effect.
A statement of work is the document that defines what will be delivered, on what commercial terms, and how completion is judged. It differs from a proposal in that it is contractually binding, and from a contract in that it describes work rather than the relationship.
What's actually wrong
These are the symptoms buyers of this service recognize before they can name the problem.
- Fixed-fee projects consistently land over the estimate, and nobody can say exactly where.
- The SOW is two pages of deliverable bullets with no assumptions or exclusions section.
- Estimates are produced by adding up the parts the team can picture, then adding a buffer.
- "That was always in scope" is a live argument on more than one active project.
- Milestones are calendar dates rather than accepted deliverables, so payment isn't tied to progress.
- Change orders exist in principle and have never once been issued.
What the engagement includes
- Requirements discovery with the client's stakeholders — the ones who sign off, not just the ones who briefed.
- A written functional scope, broken to a level a developer can estimate against.
- Effort estimation with a stated method: story points or hour bands, plus the confidence level per line.
- An explicit assumptions list — what must be true for the estimate to hold.
- An explicit exclusions list — the things a reasonable client would otherwise assume are included.
- Acceptance criteria per deliverable, written so acceptance is testable rather than a matter of opinion.
- A milestone and payment structure tied to accepted deliverables.
- A change control clause with a defined re-estimation process and rate.
Why exclusions are the highest-value section
Exclusions name the things a reasonable client would otherwise assume are included: data migration from the legacy system, training, content entry, post-launch support past the warranty window, redirect mapping, accessibility remediation, browser support below a stated version.
Writing them feels adversarial and does the opposite. An exclusion surfaced in week one is a conversation; the same exclusion surfaced in week nine is a dispute with an invoice attached. Clients who have bought this kind of work before read a thorough exclusions list as evidence the provider has done it before.
Change control that actually gets used
Most agencies have a change control clause and have never issued a change order. The clause isn't the problem — the moment of use is. Scope changes arrive verbally, mid-call, inside a friendly conversation, and re-pricing feels petty.
Make it small and routine: a three-line change record sent the same day, stating what changed, the effort delta, and the three options — absorb, defer, or re-price. Issued routinely it stops reading as escalation and starts reading as competence. Part of this engagement is making that habit survive after the SOW is signed.
Choosing the commercial model
| Model | Use when | Risk sits with | Requires |
|---|---|---|---|
| Fixed fee | Scope is genuinely knowable | Provider | Decomposed estimate, tight exclusions |
| Banded hours | Shape is clear, depth isn't | Shared | Band assumptions in writing |
| T&M with cap | Discovery is the work | Client | Weekly burn reporting |
| Retainer | Work is continuous | Shared | A defined baseline and a scope boundary |
How it's scoped and priced
Scoping is delivered as a fixed-fee engagement per SOW, or as part of a monthly retainer for agencies that need scoping capacity continuously. A single project SOW typically takes one to two weeks from first discovery session to signable document, depending on stakeholder availability.
For agencies with a recurring problem rather than a single project, the better entry point is a Delivery & Scoping Review: Kodelytics reviews recent SOWs against what those projects actually cost to deliver, and returns the gap analysis with a scoping template your team can reuse.
Kodelytics does not publish rates. Every engagement is quoted after a discovery call, because the same service name covers materially different amounts of work.Ask for a quote.
What you get at the end
- A signable statement of work, in your template or a supplied one.
- The underlying estimate model, with assumptions visible per line item.
- A reusable SOW template and scoping checklist.
- A change order template and process document.
Questions
What should a statement of work include?
At minimum: a functional scope, deliverables, assumptions, exclusions, acceptance criteria per deliverable, a milestone and payment schedule tied to acceptance, a change control process with a stated rate, and the commercial model — fixed fee, banded hours, or time and materials with a cap. An SOW without exclusions and acceptance criteria is a wish list.
Fixed fee, banded hours, or time and materials — which should we use?
Fixed fee where the scope is genuinely knowable and the client needs a number. Banded hours where the shape of the work is clear but the depth isn't, with the band's assumptions written down. Time and materials with a cap where discovery itself is the work. The mistake is quoting fixed fee on work that belongs in a band.
How do you estimate work you haven't done before?
By decomposing until the parts resemble something the team has done, estimating those, and pricing the genuinely unknown parts as a separate discovery phase rather than burying them in a buffer. An honest range with stated assumptions survives client scrutiny better than a precise number that turns out to be wrong.
Can you scope work for a technology stack you don't build in?
Yes, with the client's technical lead supplying the implementation view. Kodelytics owns the structure, the estimation method, and the commercial framing; the developers who will build it own the effort numbers.
Will you talk to our client directly?
Where it helps, yes — discovery is faster when the person writing the scope hears the requirement first-hand. This is normally white-labelled.