ingridleiria SOW and Scope
Every scope dispute is a sentence that nobody wrote. Six weeks in, the client asks for something that feels adjacent, the delivery lead says yes because the relationship matters, and by month three that yes is the baseline. The cost is rarely one argument; it is a margin that quietly halves and a renewal conversation held while both sides privately believe the other behaved badly.
The second failure is the document that exists but cannot be used: deliverables with no acceptance criterion, assumptions with no consequence, and a change control clause nobody invokes because invoking it feels aggressive. That document does not prevent disputes, it only proves afterwards that the dispute was foreseeable. A statement of work is read most carefully when the relationship is under strain, and it should be written for that reading.
When to use this, and when not to
Use it once a client has agreed to buy: turning an accepted proposal into a signable scope, drafting an engagement letter or Exhibit A under a master agreement, reviewing a scope somebody else wrote, drafting a change order mid-engagement, or diagnosing an engagement that has drifted from what was sold.
Do not use it to sell. The document that persuades a client to buy is proposal-writer and the deck before it is discovery-to-proposal-deck; a scope written in persuasive language neither sells nor binds.
Adjacent cases. Papering the associate, contractor, or fractional leader who staffs the engagement is contractor-msa-and-task-order, a different pair of documents in a fixed signing order. Agreements that are not client scope at all, including non-disclosure, referral and partnership papers, employment terms, vendor contracts and investment instruments, are business-agreements-drafting. Delivery of what this scopes is program-management, and the fee behind it is pricing-and-resourcing-model.
This skill drafts commercial scope. Governing law, liability, indemnity and insurance belong in the master agreement and are reviewed by counsel; drafts produced here go to counsel before execution.
What you need before starting
The accepted proposal or its equivalent. Deliverables, price, dates, and the outcomes promised.
The governing agreement this sits under. A master services agreement, framework, or standard terms, with its execution date. Missing: state that the SOW is subject to an agreement still to be signed, and that no work should start until it exists.
The price, structure, and payment schedule. From pricing-and-resourcing-model. Missing: do not invent a schedule, and leave visible bracketed placeholders so the document cannot be signed by accident.
The delivery lead's view of what will be asked for, and the client's named approver. The person who will run the work knows which requests are coming. Missing: ask them what this client will ask for that you are not being paid for, and write the exclusions from the answer. Where no single approver with decision authority is named, write in a role and a default turnaround of five business days, marked for confirmation, because an engagement with several approvers produces contradictory feedback and unbudgeted rework.
The assumptions the estimate rests on, and the client's procurement mechanics. Data availability, access to named people, environment readiness; then purchase order requirements, invoicing portal, insurance certificates, and any data processing addendum. Missing: reconstruct the assumptions with the delivery lead, since an unwritten one cannot be relied on when it fails, and ask about procurement before signature, because it otherwise surfaces in week one and delays the first invoice by a month.
The method
Confirm what this sits under and in what order things get signed. Name the governing agreement and its date on the first page, and give the SOW a unique number. Where no agreement exists, produce or request it first rather than proceeding.
Reconcile against the proposal line by line before drafting. Deliverables, price, dates, outcome language. Every difference is either an error to fix or a change to raise now. Rule: never resolve a difference silently in your own favour, because it will be found and read as bad faith rather than carelessness. Then write the objectives in two measurable paragraphs, since they are what a reader uses to decide which reading of an ambiguous clause was intended.
Write scope of services at the level that answers the in-or-out question. The test for each sentence: could a delivery lead use this to decide whether a requested task is inside the fee? A description only an insider can interpret will be interpreted by the client instead.
Build the deliverables table, and give every row an acceptance criterion. "A report" is not a deliverable; "a written report of no more than thirty pages covering the three areas named in section three, delivered as PDF and editable source" is. Rule for the criterion: it must be checkable by someone who did not do the work.
Write exclusions from the delivery lead's fears, not from a template. Rule: if a reasonable client might assume it is included and you would refuse it, exclude it now, where it is a scoping detail rather than a refusal.
Give every assumption a consequence. Not "we assume data will be available by 14 March" but "if the data is not available by 14 March, the timeline extends day for day and the resulting effort is chargeable at the rates in section nine". An assumption without a consequence is a hope with a date next to it.
Write client responsibilities as named inputs with turnarounds. People by role, systems access, decisions, feedback within a stated number of business days, one point of contact with authority. Rule: express every turnaround in business days, never as "promptly".
Define acceptance, including deemed acceptance. How a deliverable is submitted, the feedback window, and the rule that silence for a stated period is acceptance. Rule: cap review at two or three rounds and state what a further round costs, because uncapped review is the commonest route to an unprofitable engagement with no identifiable moment of failure.
Tie payment to milestones, using the proposal's numbers. Include the expenses policy with a cap, invoicing details, and payment terms. Where a purchase order is required, say invoices cannot be raised without one, and who provides it.
Write change control so that it is usable, not merely present. Who may request a change, in what form, who estimates and approves it on each side, and how it is priced, with a one-page template attached. State that no work outside this SOW happens without a signed change order, and brief the delivery lead that raising the first one early and small is what keeps the mechanism usable later.
Close the standing clauses, then sweep for consistency. Team and substitution on notice; term, termination for convenience with payment for work performed, and handover obligations; intellectual property, confidentiality and data stated or referenced. Then check that deliverable names, dates, and the fee agree with each other and with the proposal.
Reviewing an existing SOW
Read it against the structure above and rank findings by the size of the dispute each invites, not by their order in the document. In the order they usually matter: deliverables with no acceptance criterion; missing exclusions; assumptions with no consequence; responsibilities with no turnaround; uncapped review or no deemed acceptance; payment not tied to milestones; absent change control; and any clause contradicting the proposal or the master agreement. Give each finding a clause reference, the dispute it invites in one sentence, and replacement wording, because a review without wording is one the recipient will not act on before signature.
Worked example
Situation. Halden Systems, a forty-person data engineering firm, had a signed proposal with Corvid Insurance to migrate eleven years of policy records to a new platform. Fee 142,000 pounds across four milestones, sixteen weeks, five people at peak. All figures in this example are pounds sterling. Corvid's procurement team required an SOW under a master agreement signed two years earlier.
Task. A signable SOW within five working days, consistent with the proposal, that the delivery lead could hold to when Corvid asked for more.
Action. The reconciliation came first and found three differences. The proposal said sixteen weeks from signature; the delivery plan assumed sixteen weeks from data access, four weeks apart on the calendar. The proposal listed eight deliverables, the plan had eleven, because three had been split. Both were raised with Corvid rather than resolved quietly.
The first draft of the deliverables table promised zero data loss, because that was what Corvid had asked for verbally and the delivery lead wanted to give it. It was abandoned: Halden could not control the completeness of Corvid's source extracts, and the promise made Halden guarantor of a problem it could not inspect. It became an acceptance criterion instead, a reconciliation report showing record counts and control totals matching the source extract within a stated tolerance, every variance itemised and traced to a source-side cause.
Exclusions came from one question to the delivery lead, and the load-bearing assumption, a production-like copy of the source by end of week two, carried a day-for-day extension and chargeable standby. Acceptance allowed two review rounds, feedback in ten business days, and deemed acceptance after ten business days of silence.
Result. Signed in nine days, four longer than planned, because the sixteen-weeks-from-what question went to Corvid's programme board. Two change orders followed, at 9,000 pounds and 14,000 pounds, both signed within a week; the delivery lead's view was that the first was easy only because it was small and early, which is the argument for raising one deliberately.
A second scenario, where it goes differently
The same firm sold a six-month advisory retainer to a mid-size distributor: two days a week of a named architect, with no fixed deliverable list because the work was reactive by design. Fixed deliverables and acceptance criteria do not apply here, and forcing them produces a fiction. The SOW instead defines the capacity purchased (sixteen days a month, named person, substitution of an equivalent on ten days' notice), how work is requested and prioritised (one named requester, a written backlog, monthly prioritisation), the cap (unused days do not carry beyond one month, days above sixteen need written approval), and what acceptance means without a deliverable (a monthly written summary, deemed accepted after ten business days).
Exclusions carry more weight here than anywhere else, because an open scope expands by default. What changed: with fixed deliverables the document protects the boundary of the work, and with a retainer it protects the boundary of the time.
Output
STATEMENT OF WORK no. [SOW-YYYY-NN]
Issued under the Master Services Agreement dated [date] between [parties]
Effective date [date] Client [entity] Provider [entity]
1 Background and objectives measurable, two paragraphs
2 Scope of services in-or-out at sentence level
3 Deliverables table below
4 Exclusions written from the delivery lead's answer
5 Assumptions each with its consequence
6 Client responsibilities inputs, access, turnarounds in business days
7 Timeline and milestones with dependencies on section 6
8 Acceptance rounds, feedback window, deemed acceptance
9 Fees and payment tied to milestones, expenses, invoicing
10 Change control process, approvers, pricing, template attached
11 Team and substitution 12 Term, termination, wind-down
13 IP, confidentiality, data 14 Signatures
| # | Deliverable | Description | Format | Due (milestone or date) | Acceptance criterion | | 1 | | | | | | | 2 | | | | | |
The attached change order template carries: change order number and the SOW it amends; who requested it, their role and the date; what is added, removed or altered; the deliverables affected; the days added and which milestones move; the fee impact and revised payment schedule; and a signature line for one named approver on each side.
Failure modes
Outcome promises the team cannot control. "Zero data loss", "improved adoption", "reduced cost". Recognise them because delivery depends on the client's behaviour or their data. Reframe as an acceptance criterion on something you produce, or as a target explicitly labelled as one.
The SOW that contradicts the proposal. Recognise it by putting the two side by side and comparing deliverable names, dates, and the fee. The client will cite whichever document favours them. Reconcile before drafting, never after signature.
The deliverable with no acceptance criterion. Recognise it because the row would make just as much sense for a different client. Ask what a reviewer who did not do the work would check, and write that down.
Assumptions that read as reassurance. "We assume the client will provide timely access." Nothing follows from it. Every assumption needs the sentence beginning "if this fails, then", and every turnaround written as "promptly" needs a number of business days instead.
Uncapped review, and change control that exists but is never used. Recognise the first because the document says how feedback is given but not how many rounds are included or what silence means. Recognise the second in delivery rather than drafting, by asking the delivery lead what has been absorbed since kickoff. Both are quiet routes to an unprofitable engagement with no identifiable moment of failure. Fix the second by raising the first change order early and small, which sets the norm while the relationship is comfortable.
Edge cases
No master agreement exists. Do not paper the commercial terms alone. Produce or request the governing agreement first and state that the SOW takes effect only on its execution; where the client insists on starting, a short letter of intent limited in value and duration is the narrower risk and goes to counsel.
The client insists on their own template. Do not redraft it into yours. Review it against the structure above and negotiate only the clauses that decide the outcome: deemed acceptance, review rounds, change control, payment triggers, termination for convenience, and outcome language. Concede the rest, because arguing over everything spends the goodwill those clauses need.
Fixed price on a scope nobody can yet specify, or work that has already started. For the first, do not price the unknown: scope a short first phase whose deliverable is the specification, and name the second with a range to be scoped on its output. For the second, backdate the effective date to the actual start and list what has been delivered as accepted on signature, because pretending work began on the signature date leaves the most exposed period governed by nothing.
Your deliverable depends on another supplier, or the client's procurement terms cannot be varied. In the first case name the dependency and write the consequence of their delay in the same form as an assumption, and write your acceptance criterion against what you receive rather than what they should have sent. In the second, work inside their template, put the commercial protection where it permits it, usually in the deliverable descriptions and assumptions, and raise anything unworkable before bidding rather than after award.
Quality bar
- Every deliverable has a format, a due point, and an acceptance criterion checkable by someone who did not do the work.
- Every assumption states what happens if it fails.
- Every client responsibility has a turnaround expressed in business days.
- Review rounds are capped, and deemed acceptance is defined.
- Payment is tied to milestones and matches the proposal figure exactly.
- Change control names its approvers and has a template attached.
- Exclusions name the things this client would reasonably assume are included.
- Nothing in the document promises an outcome the team does not control.
- A reader could settle a scope question from the document alone, without asking either party what was meant.
Adapting this to your context
The turnarounds, the review caps and the deemed acceptance windows come from mid-size services firms contracting with corporate clients under a master agreement. They are drafting defaults, and several are jurisdiction-sensitive.
- Ten business days for feedback and for deemed acceptance. Shorten both to five for fast-moving work, and lengthen them where the approver is a committee that meets monthly. The window should match how often that body meets.
- Two or three review rounds. Software and design work commonly needs more and prices them explicitly. A deliverable that must pass an external review may need that round handled as a separate milestone.
- Deemed acceptance itself. Restricted or unusual in some jurisdictions and often prohibited in public sector and consumer contracts. Confirm with counsel for the governing law, and where it is unavailable, protect the same interest with a milestone payment trigger.
- Fixed deliverables with acceptance criteria. Where the work is genuinely reactive, as in the retainer scenario, the document protects capacity and prioritisation instead. Do not force a deliverable list onto work that has none.
- What not to change. Every assumption states what happens if it fails, nothing promises an outcome the team does not control, and a scope question is answerable from the document alone.
Related skills
proposal-writer produces the accepted document this one converts into contractual scope, and any discrepancy between the two becomes the client's argument. discovery-to-proposal-deck and ideation-deck sit further upstream, before anything has been bought. pricing-and-resourcing-model supplies the fee, the payment structure, and the effort assumptions that become the assumptions section. contractor-msa-and-task-order papers the individuals who staff what this document scopes, in its own signing order, and business-agreements-drafting covers every agreement that is not client scope. program-management runs the delivery this defines and is where change control is actually exercised. partnership-assessment handles a counterparty who is a partner rather than a client, which needs governance and exit terms rather than deliverables and acceptance.