How Do I Write a Scope of Work for an RFP?
The scope of work is where the issuer defines what will be done, delivered and accepted - and it's the section every bidder prices against. Here are the sections it needs, how specific to make it, the difference between an SOW, a PWS and an SOO, and the omissions that cause disputes later.
The scope of work is the section of an RFP where the issuer defines what work will be performed, what will be delivered, by when, and how anyone will know it was done properly. It is written by the buyer, before the solicitation goes out, and it is the section every bidder prices against - which is why a vague one produces quotes you cannot compare and a contract you cannot enforce. At minimum it needs definitions, background, objectives, deliverables, a communication plan, a timeline and acceptance criteria.
What Sections Belong in a Scope of Work?
- Definitions. Every acronym and internal term you use. This is not filler - it is what stops a bidder from pricing a different thing than the one you meant.
- Background and problem statement. The current state, what has already been tried, and what is wrong with it. Bidders who understand the history propose better solutions.
- Objectives. What the finished work must achieve, stated as outcomes rather than activities. A paragraph, not a page.
- Deliverables and tasks. Each deliverable, the tasks that produce it, and who is responsible - yours or theirs. Put it in a table.
- Communication and reporting. Meeting cadence, status reporting, escalation path and who the vendor's day-to-day contact will be.
- Timeline and milestones. Dates for every deliverable and review, including the ones that depend on you.
- Acceptance criteria. How you will decide a deliverable is complete. This is the most commonly omitted section and the one that causes the most disputes.
- Constraints and assumptions. Systems they must work with, access they will and will not get, standards they must meet, and what you are assuming about their environment.
What Is the Difference Between an SOW, a PWS and an SOO?
They differ in how much of the solution you specify. The distinction comes from federal contracting but the logic applies anywhere: the more you dictate method, the more you own the outcome.
| Document | Who describes the how | Use it when |
|---|---|---|
| Statement of Work (SOW) | You do - it specifies tasks and methods | You know exactly how the work should be performed and want it done that way |
| Performance Work Statement (PWS) | The vendor does - you state required results and measurable standards | You know what outcome you need but vendors may have better methods than yours |
| Statement of Objectives (SOO) | The vendor does, and writes the PWS itself | You want the market to propose approaches, and you will evaluate the approaches as well as the price |
Under FAR 37.602, a statement of objectives must include, at minimum, the purpose, scope or mission, period and place of performance, background, performance objectives and operating constraints. Offerors then use it to develop the performance work statement - and notably, the SOO itself does not become part of the contract. The same rule directs agencies to describe work "in terms of the required results rather than either how the work is to be accomplished or the number of hours to be provided," and to enable assessment against measurable performance standards. That is a good instinct even in a private-sector RFP: specify the method only where the method genuinely matters.
Your next RFP is one search away.Search Bid BananaHow Specific Does a Scope of Work Need to Be?
Specific enough that two competent vendors reading it would price roughly the same work. That is the test, and it is easy to apply: hand the draft to someone uninvolved and ask what they would quote. Lack of specificity is the single most common defect, and it shows up as a price spread you cannot explain at evaluation time. Quantities, volumes, service levels, response times and who supplies what all belong in writing. Where you genuinely do not know a volume, say so and ask for unit rates rather than inventing a number - an honest unknown is manageable, a silent one is not.
What Goes in the Deliverables Table?
Four columns, minimum: the deliverable, the tasks required to produce it, who owns each task, and when it is due. The ownership column is the one people leave out and the one that prevents the most arguments, because a surprising share of project delays are caused by the buyer - data that was never provided, an approval that took three weeks, a stakeholder who was never available. Writing your own obligations into the table sets a fair expectation and gives the vendor a legitimate basis to flag a delay early rather than absorbing it silently and missing the date.
What Are the Most Common Scope of Work Mistakes?
Omitting acceptance criteria, so "done" is a matter of opinion. Describing activities instead of outcomes, so a vendor can complete every task and still not solve the problem. Leaving your own responsibilities out. Copying a scope from a prior project without checking that its assumptions still hold. And burying requirements in prose where a bidder will miss them - if it is a requirement, it belongs in a list or a table, not in the third sentence of a paragraph. Once the scope is solid, the rest of the document is comparatively easy; our guide to what makes a good RFP covers how to tell whether it worked, and the issuer's process end to end covers where the scope fits in the sequence.
Read Scopes Other Buyers Have Published
The most efficient way to write one is to read a dozen live solicitations in your category and steal the structure that recurs. Browse open RFPs on Bid Banana.
Frequently asked questions
What is a scope of work in an RFP?▼
The scope of work is the section where the issuer defines what work will be performed, what will be delivered, by when, and how completion will be judged. The buyer writes it before the solicitation goes out, and every bidder prices against it. At minimum it covers definitions, background, objectives, deliverables and tasks, communication, timeline and acceptance criteria.
What is the difference between an SOW, a PWS and an SOO?▼
They differ in who describes the method. A statement of work specifies the tasks and how they are performed. A performance work statement states required results and measurable standards, leaving method to the vendor. A statement of objectives goes further - vendors use it to write the PWS themselves. Under FAR 37.602 the SOO does not become part of the contract.
How detailed should an RFP scope of work be?▼
Detailed enough that two competent vendors reading it would price roughly the same work. Quantities, volumes, service levels, response times and who supplies what all belong in writing. Where a volume is genuinely unknown, say so and request unit rates rather than inventing a figure. Lack of specificity shows up later as a price spread you cannot explain.
What should the deliverables table include?▼
At least four columns: the deliverable, the tasks needed to produce it, who owns each task, and the due date. The ownership column matters most and is most often omitted, because many delays are caused by the buyer - data not supplied, approvals that stall, stakeholders who are unavailable. Recording your own obligations gives the vendor a fair basis to flag slippage early.
What are the most common scope of work mistakes?▼
Leaving out acceptance criteria so completion becomes a matter of opinion; describing activities instead of outcomes, letting a vendor finish every task without solving the problem; omitting the buyer's own responsibilities; reusing an old scope whose assumptions no longer hold; and burying requirements in prose where bidders miss them rather than listing them.