Scope of Work (SOW): What It Is and What to Include

What Is a Scope of Work?

A scope of work (SOW) is the document that defines exactly what a consultant, evaluator or contractor will deliver, by when, for how much, and under what conditions. In M&E it is used to hire evaluators, survey firms, data analysts and MEL system advisors. Once signed, it becomes part of the contract, so it is the text both sides go back to when they disagree about what was promised.

A good SOW answers four questions without leaving room for interpretation: what work will be done, what will be handed over, when each piece is due, and how the client will decide whether each piece is acceptable.

"Scope of work" and "statement of work" are used interchangeably. Some organizations reserve "scope" for the boundaries of the work (what is in and what is out) and "statement" for the full document, but in practice both names refer to the same thing.

Scope of Work vs. Terms of Reference

The two documents overlap heavily and many organizations use the names for the same thing. The difference, where there is one, is emphasis.

For an evaluation, the practical rule is simple: use whatever name your organization or donor uses, and make sure the document contains both halves. A ToR without firm deliverables and deadlines invites scope creep. A SOW without purpose and questions gets you a report nobody uses. See Evaluation Terms of Reference for the evaluation-specific version.

U.S. federal procurement adds two related formats. A performance work statement (PWS) describes the work in terms of required results rather than how the work is to be done, and a statement of objectives (SOO) states only the goals and lets bidders propose their own PWS (FAR 37.602). Development programs funded through U.S. contracts sometimes use these instead of a traditional SOW.

Why It Matters

Most consultancy disputes trace back to the SOW. When deliverables are vague ("a report on findings"), the consultant delivers the minimum and the client expects the maximum. When acceptance criteria are missing, the client cannot reject weak work without a fight. When the timeline ignores client review time, every deadline slips and the consultant's days run out before the final draft.

A precise SOW also makes procurement fairer. Bidders price the same work, so proposals can be compared on quality and cost rather than on how each bidder guessed what was wanted. And writing it forces the commissioning team to agree on what they actually need before money is committed, which is where many evaluations go wrong.

What Does a Scope of Work Include?

A complete SOW usually covers these sections, in roughly this order:

1. Background. One or two paragraphs on the program and why the work is needed now. Enough context for a bidder to price the work, not a program history.

2. Purpose and objectives. What the work is for and who will use it. For an evaluation, name the decisions the findings will inform.

3. Scope and boundaries. What is included and, just as important, what is excluded: geographic areas, time period, program components, populations. Explicit exclusions prevent the most common arguments.

4. Tasks and methods. The work the contractor will do. For an evaluation, the evaluation questions and any required methods. For data collection, the instruments, sample size, sites and data quality procedures.

5. Deliverables. Each product listed separately with its format, language, length and due date. For example: inception report, data collection tools, cleaned dataset with codebook, draft report, final report, presentation.

6. Acceptance criteria. How the client will judge each deliverable and how many rounds of comments are included. This is the section most often missing.

7. Timeline. Start and end dates, milestones, and the time the client needs for review at each stage.

8. Level of effort and budget. Days per team member, or a total budget ceiling, and the payment schedule tied to accepted deliverables.

9. Team qualifications. Required skills, experience and languages for key personnel.

10. Management and reporting. Who the contractor reports to, check-in frequency, and how changes to the scope are approved.

11. Data, ethics and ownership. Data protection and consent requirements, safeguarding, who owns the data and products, and any publication restrictions.

Example Outline

A SOW for a baseline survey contracted to a data collection firm might run 6 to 10 pages:

1. Background (half a page)
2. Purpose of the baseline and how results will be used (half a page)
3. Scope: districts, target groups, sample size and sampling method (1 page)
4. Tasks: instrument translation and pretesting, enumerator recruitment and training, data collection, quality checks, cleaning (1 to 2 pages)
5. Deliverables table: training report, pilot report, daily progress updates, cleaned dataset and codebook, field report (1 page)
6. Acceptance criteria: completion rates, back-check share, error thresholds, dataset format (half a page)
7. Timeline with client review periods (half a page)
8. Level of effort, budget ceiling and payment schedule (half a page)
9. Required team and qualifications (half a page)
10. Data protection, consent, safeguarding and data ownership (1 page)

Annexes: draft questionnaire, list of sites, indicator definitions, and the quality standards the dataset must meet.

Common Mistakes

Deliverables with no definition. "A final report" says nothing about length, structure, language or the standard it must meet. List each deliverable with enough detail that two people would agree on whether it has been delivered.

No acceptance criteria. Without them, every disagreement becomes a negotiation. State what makes a deliverable acceptable and how many review rounds are included in the price.

Timelines that forget the client. Consultants plan their own days but not the two weeks the client takes to comment on a draft. Build client review and approval time into every milestone.

Too many tasks for the budget. A SOW that asks for a mixed-methods evaluation across six countries in 30 days will attract either no good bidders or a bidder who plans to cut corners. Check the level of effort against the task list before release.

Scope that is never closed. Phrases like "and other tasks as needed" give the client flexibility but make the work impossible to price. Use a change procedure instead: new tasks are agreed in writing with their own time and cost.

Variation by Type of Engagement

Evaluations. The SOW reads like a ToR: purpose, evaluation questions, methods expectations and evaluator qualifications carry most of the weight. An inception report is usually the first deliverable, and it is where the method gets fixed.

Data collection. Tasks, sample, quality checks and dataset standards dominate. Acceptance criteria should be measurable: response rates, back-check rates, missing-data thresholds.

MEL system design. The deliverables are usually a MEL plan, indicator reference sheets, data collection tools and a training. Specify who must be involved in development, not just what will be handed over.

Short advisory assignments. A two-page SOW is often enough: the question to be answered, the product, the days, and the deadline. Do not pad short assignments with sections that do not apply.

In every case the test is the same: could a stranger read the SOW and tell whether the contractor has done the job?