Statement of Work Examples: Draft Wording for Scope, Work Packages, Acceptance and Change Control
Statement of work examples for a consulting engagement, with draft wording for scope boundaries, work packages, acceptance criteria and change control, plus a review checklist to use before you issue it.

A statement of work (SOW) describes what will be done, by whom, by when and how everyone will know it is finished. Reading other people's examples helps only if you can see why each clause is there, so this guide breaks a sample consulting SOW into four working parts: scope boundaries, work packages, acceptance criteria and change control. Each has draft wording you can adapt and a check you can apply.
The scenario is fictional: a six-week strategy review for a regional building-supplies distributor, producing a recommendations report. Names, dates and quantities are placeholders. Replace them with facts you have verified.
What an example can and cannot tell you
An SOW is only useful if the people who read it understand the same thing. Oregon's transportation department, in its Statement of Work Writing Guide, notes that the document is read by people with diverse backgrounds and that it should meet a basic "fitness for use" standard: written clearly enough, with enough detail, to obtain services and deliverables that meet the intended purpose.
That guide is written for a public agency buying personal services, so treat its rules as good drafting practice rather than requirements for your engagement. The same goes for the US federal rule on ordering services under Federal Supply Schedules. It says that a statement of work must include a description of the work, location of work, period of performance, deliverable schedule, applicable performance standards and any special requirements. Private consulting engagements are not bound by that list, but it is a sensible minimum to test your own draft against.
An example reflects one set of facts, and wording that suits one jurisdiction or master agreement may conflict with another, so check every clause against the agreement your SOW sits under.
Example part 1: Scope boundaries
The scope section says what the engagement covers and, just as importantly, where it stops. The Oregon guide defines the scope of work as the range of services to be performed and the limit to which they can be changed, which is a helpful way to think about it: a scope is a boundary, not a description of enthusiasm.
Draft wording:
Purpose. This statement of work authorises [Consultant] to carry out a strategy review of purchasing across [Client]'s [number] branches under [governing agreement, date]. It authorises only the work described here.
In scope. Interviews with up to [number] stakeholders named by the sponsor; review of the documents listed in Appendix A; analysis of the purchasing options in Section 3; a written recommendations report and one presentation to the leadership team.
Out of scope. Implementation of any recommendation; supplier negotiations; system selection or configuration; interviews beyond the named stakeholders; feedback rounds beyond the consolidated round in Work Package 3.
Location and period. Work is performed remotely except for [number] on-site days at [location], between [start date] and [end date].
Conflict. If this statement conflicts with the governing agreement, [state which document prevails].
The last line is easy to skip and expensive to omit. A statement that quietly contradicts the master agreement invites a dispute about which one applies.
Scope check: Could a stakeholder who was not in the sales conversation read the in-scope and out-of-scope lists and predict what will and will not be delivered?
Example part 2: Work packages
Work packages break the scope into pieces that one person can be accountable for. For each, state the activity, the owner, the output and any client dependency.
The Oregon guide's drafting questions are a good prompt set: what will the work consist of, who is responsible for specific tasks, when are deliverables due and what will a successful outcome be.
| Work package | Activity | Owner | Output | Client dependency |
|---|---|---|---|---|
| 1. Discovery | Interview named stakeholders; review Appendix A documents | [Consultant lead] | Interview summary | Sponsor arranges access and shares documents by [date] |
| 2. Analysis | Compare purchasing options against agreed criteria | [Consultant analyst] | Options analysis | Criteria confirmed by sponsor at end of package 1 |
| 3. Recommendations | Draft report; present to leadership; incorporate one consolidated round of comments | [Consultant lead] | Recommendations report; presentation | Comments consolidated by sponsor within [number] working days |
Notice that each dependency names a person and a date. The Oregon guide recommends listing your assumptions and validating them with someone who knows, because listing them can bring out obligations that might have gone unwritten and expectations that later turn out to be wrong. Where a client commitment is unconfirmed, write it as an assumption and say what happens if it fails:
Assumption. [Client] provides the Appendix A documents by [date]. If they arrive later, the delivery dates in the table move by the same number of working days, and the parties agree any change to the fee through the process in Section 6.
The same guide suggests, where a large project is uncertain, drafting only the first phase in detail and adding later phases by amendment. If the second half of your engagement depends on what discovery finds, that is often cleaner than guessing.
Work package check: Does every package have one accountable owner, an output someone can inspect and a stated consequence if a dependency is late?
Example part 3: Acceptance criteria
Acceptance criteria turn "done" into something both sides can test. The Oregon guide says that best practice is to define deliverables for each task that are tangible and measurable; its example is an assessment task whose deliverable is a written report of findings. It also covers services with no tangible output, such as facilitating a meeting, where a supporting record such as an agenda and attendee list can show the work took place.
Draft wording:
Deliverable: Recommendations report.
Accepted when: (a) the report contains each section listed in Appendix B; (b) each recommendation cites the evidence it rests on, by reference to interview notes or documents; (c) the sponsor confirms in writing that the recommendations and evidence are approved.
Reviewer: [name, role]. Review window: [number] working days from delivery.
If rejected: the reviewer lists each shortfall against criteria (a) to (c). [Consultant] corrects and reissues within [number] working days, and the review window restarts.
Silence is not acceptance. If no response is received by the end of the review window, [Consultant] escalates to [named person] before treating the deliverable as accepted.
Criterion (c) mirrors the starting point in the DocStaple consulting template: "sponsor approves recommendations and evidence". Replace it if your approved scope requires a different test.
Replace the vague verbs
The Oregon guide lists words and phrases to avoid because they have more than one interpretation, including "assist", "work with", "help", "best efforts", "reasonable", "acceptable", "necessary" and "good". It suggests asking how the party will "assist", what the minimum "acceptable" standard is and who decides when something is "necessary". Applied here, "we will assist with the roadmap" becomes "[Consultant] drafts a roadmap of no more than [number] initiatives and revises it once after the sponsor's consolidated comments".
Acceptance check: For each deliverable, can you name the reviewer, the test they apply, the review window and what happens if it fails?
Example part 4: Change control
Change control is the agreed route for altering scope, fee, timetable or acceptance criteria after signature. Without it, changes happen through emails and hallway conversations and are remembered differently.
Federal government contracts illustrate the principle in their own setting: they generally make changes by written change order on Standard Form 30, issued by the contracting officer. That mechanism belongs to government procurement and does not apply to a private engagement, but the underlying habit is transferable: changes are written down, and someone with authority issues them.
The Oregon guide offers a second useful pattern. For services that may or may not be needed, it recommends tightly defined "contingency tasks", with a stated subject, extent and price limit, that can be started only once a written notice to proceed is issued. It observes that authorising such a task is quicker than amending the whole contract. Adapted for a consulting SOW:
Change process. Either party may request a change by written notice describing the change and the reason. Within [number] working days, [Consultant] states the effect on scope, fee, timetable and acceptance criteria. No change takes effect until [named client authoriser] and [named Consultant authoriser] approve it in writing. Approved changes are recorded in the change log, and the current version of this statement is kept with the project records.
Optional work. Work Package 4 (additional stakeholder interviews, up to [number], at [rate or fixed amount]) is performed only after written notice to proceed from the client authoriser.
Change check: Can you point to who may request a change, who assesses it, who approves it and where the approved version lives?
Review the SOW before you issue it
Use these prompts on a colleague's read-through, ideally by someone who was not in the negotiation:
- Fit: Does the SOW say which document prevails if it conflicts with the governing agreement?
- Boundaries: Are in-scope and out-of-scope items both listed, with locations and dates?
- Ownership: Does every work package have one accountable owner and named client dependencies?
- Assumptions: Are unconfirmed client commitments written as assumptions, with a consequence if they fail?
- Acceptance: Is each deliverable tied to a reviewer, a test, a review window and a rejection route?
- Language: Have "assist", "reasonable" and "acceptable" been replaced with an action and a standard?
- Change: Is there a named route for requests, assessment and written approval?
- Professional review: Have fee, liability and termination terms been reviewed by a qualified professional where they carry legal weight?
Adapt the examples in a structured Word draft
If you would rather not rebuild these sections each time, the consulting statement of work template is an editable Word file organised around work authorisation and boundaries, deliverables and acceptance criteria, responsibilities and dependencies, and change control and completion. It also has preparation and approval sections. It is a starting draft, not a guarantee that any statement of work is complete, compliant or enforceable. If the SOW is part of a proposal, the consulting proposal template covers the commercial framing that comes before it.
Sources: Statement of Work Writing Guide, Oregon Department of Transportation, FAR 8.405-2, Acquisition.GOV, FAR Subpart 43.2 Change Orders, Acquisition.GOV
Last updated: September 26, 2026
Frequently Asked Questions
Related Articles
Capability Statement Best Practices for Consulting Firms
Capability statement best practices for consulting firms, with fixes for vague competencies, weak past performance, generic differentiators and stale credentials.
Capability Statement Checklist for Buyer-Ready Consulting Drafts
A capability statement checklist for consulting firms, with review gates for core competencies, relevant experience, differentiators, credentials and contact details.
Capability Statement Examples: Four Sections Written Weak and Then Strong
Capability statement examples for a fictional consulting firm: core competencies, relevant experience, differentiators, and contact and credentials, each shown as weak and stronger draft wording with a review checklist.
Engagement Letter Best Practices
Best practices for engagement letters, including scope control, responsibility wording, limitation language and approval records.
Engagement Letter Checklist
Use this engagement letter checklist to review purpose, parties, responsibilities, limitations, approval and signature readiness.
Engagement Letter Examples: Purpose, Scope Limits and Signatures
Engagement letter examples for consulting work, with annotated wording for parties, responsibilities, scope limitations, approval and signatures.