Three of the most common acronyms in federal solicitations — PWS, SOW, and SOO — describe how the government tells you what work it wants done. They look similar at first glance, but they imply very different procurement strategies, very different proposal expectations, and very different risk allocations. Confusing them can cost you proposals.
This guide walks through what each document type is, when the government uses each, and what each implies for how you write your proposal.
The short answer
| Document | Full Name | What It Specifies |
|---|---|---|
| SOW | Statement of Work | Detailed tasks the contractor must perform |
| PWS | Performance Work Statement | Outcomes the contractor must achieve, with measurable performance standards |
| SOO | Statement of Objectives | High-level goals; contractor proposes how to achieve them |
The progression from SOW to PWS to SOO represents an increasing transfer of solution discretion from the government to the contractor. SOW says "do these things." PWS says "achieve these outcomes." SOO says "meet these objectives — you tell us how."
Statement of Work (SOW): the prescriptive approach
An SOW is the traditional, prescriptive approach. The government specifies in detail the tasks the contractor must perform, the deliverables, the schedule, and often the methods. The contractor is responsible for performing those specific tasks — not necessarily for the broader outcomes those tasks are intended to produce.
Example excerpt from a typical SOW: "The contractor shall perform monthly maintenance on each server in the inventory, including operating system patching, log review, security configuration verification, and backup validation. The contractor shall produce a monthly maintenance report documenting all activities performed."
SOWs are still common in well-defined, repeatable work — facilities maintenance, base support services, certain IT operations work. The government uses SOWs when it knows exactly what tasks need to be performed and wants the contractor accountable for those specific tasks.
Proposal implications: Your technical approach should map cleanly to the listed tasks. Don't propose innovative alternatives — the government wrote the SOW because it wants those specific tasks performed. Innovation goes in efficiency, quality, or risk management — not in scope substitution.
Performance Work Statement (PWS): the outcomes approach
A PWS shifts the focus from inputs (tasks) to outputs (outcomes). Instead of telling you what to do, the government tells you what success looks like — typically with measurable performance standards, acceptable quality levels, and incentive structures.
Example excerpt from a typical PWS: "The contractor shall maintain server availability at 99.5% or higher during business hours. Monthly availability below 99.0% will result in performance review. The contractor's approach for achieving and measuring availability shall be described in the technical proposal."
The PWS is the most common document type in modern federal services contracting. Performance-based contracting under FAR Part 37 specifically encourages PWS use because it focuses on results, allows contractor flexibility to innovate, and ties payment to verifiable outcomes.
A PWS typically pairs with a Quality Assurance Surveillance Plan (QASP) that defines how the government will measure and verify contractor performance — what's being measured, how often, by whom, and what happens when standards aren't met.
Proposal implications: Your technical approach should describe how you'll achieve the stated outcomes — your methodology, your tools, your management approach, your quality assurance. The proposal is the place to demonstrate that your approach is more efficient, more reliable, or more innovative than competitors. Show your work.
Statement of Objectives (SOO): the discretionary approach
An SOO is the most contractor-discretionary document type. The government states broad objectives — the strategic outcomes it's trying to achieve — and the contractor proposes a complete approach: scope, methodology, deliverables, performance standards, and schedule.
Example excerpt from a typical SOO: "The objective of this acquisition is to modernize the agency's customer-facing IT systems to improve user experience, reduce operating costs, and enhance security posture. The contractor shall propose a comprehensive approach including specific modernization initiatives, sequencing, performance measures, and risk mitigation strategies."
SOOs are most common in complex, large-scale acquisitions where the government wants industry to bring its best thinking — large IT modernization programs, R&D contracts, novel mission requirements. They're high-effort to bid because the contractor essentially writes the PWS that the government would have written, plus the technical approach.
Proposal implications: SOO responses are essentially proposing your own scope. Your proposal must include a detailed PWS-equivalent of what you'll do, plus the rationale for why that's the right approach. Evaluators compare not just how well you'll execute, but the quality of the scope you've proposed. Two contractors with equally strong execution can win or lose on the strategic strength of their proposed approach.
How to read which type you're dealing with
The first place to look is the document title — but don't trust it blindly. Some solicitations call a prescriptive task list a "PWS," and some call an outcomes-based document an "SOW." The actual document content is what matters.
- If the document specifies tasks the contractor will perform, it's functionally an SOW.
- If the document specifies outcomes with measurable standards (like "99.5% availability"), it's functionally a PWS.
- If the document specifies high-level objectives and asks the contractor to propose the approach, it's functionally an SOO.
Read carefully — the document type frames everything about how to write the proposal.
Mixed documents: hybrid approaches
Many real-world federal solicitations use hybrid approaches. A common pattern is a PWS for the core services (with measurable performance standards) plus an SOW-style task list for specific deliverables (like reports, plans, and assessments). Read each section separately and respond to each section in its native style.
Key personnel implications
The document type often signals how prescriptive the government is being about staffing. SOWs typically have explicit, named labor categories with detailed qualifications. PWSes may specify key personnel positions but allow contractor discretion on labor categories. SOOs may not specify staffing at all — the contractor proposes the team.
Either way, every solicitation has key personnel requirements somewhere. Pulling them out of a 200-page document and turning them into recruiter-ready job reqs is exactly what our Recruiter Accelerator does — auto-generated job descriptions, salary ranges, and boolean search strings for every key personnel position, in minutes instead of days.
Bottom line
Understanding whether you're working with an SOW, PWS, or SOO is the first step in scoping your proposal effort. SOWs are the lightest proposal lift (you're describing how to execute defined tasks). PWSes require more thought (you're proposing methodology to achieve outcomes). SOOs are the heaviest (you're proposing the scope itself).
Mismatching your proposal style to the document type — proposing innovative scope substitutions on a prescriptive SOW, or executing-the-task-list on a strategic SOO — is a fast way to score in the bottom half of evaluators' rankings without ever knowing why.
For more on how the document type interacts with the rest of the solicitation structure, see our guides on how to evaluate an RFP in under 10 minutes, how to read Section M like a winning capture manager, and RFP shredding vs RFP summarization.