Three documents in federal contracting all describe the work to be done, and they get used almost interchangeably in conversation even though they are meaningfully different. A Statement of Work (SOW) tells the contractor what to do and how to do it. A Performance Work Statement (PWS) states the results required and lets the contractor decide how to achieve them. A Statement of Objectives (SOO) goes further still: the government provides only its high-level objectives, and the offeror proposes the entire approach. The single axis that separates them is who decides the “how.”
That axis is the whole game for a technical contributor, because it tells you how much of the solution is the government’s design and how much is yours to invent. This page walks through each document, what the FAR actually says, and what each one means for the person writing the technical content.
The one axis that separates them
Picture a spectrum of contractor latitude. On the left, the government controls everything, including the method. On the right, the government controls only the destination and leaves the route entirely to industry.
| SOW | PWS | SOO | |
|---|---|---|---|
| Government specifies | What and how | What results, to what standard | Objectives only |
| Contractor decides | Little; follows the method | How to meet the results | The tasks, the standards, the how |
| Who writes the work statement | Government | Government (or offeror, from a SOO) | Offeror proposes a PWS |
| In the contract? | Yes | Yes | No; the resulting PWS is |
Reading left to right, the contractor gains latitude and the government gains innovation, at the cost of control. That tradeoff is the reason an agency picks one over another.
SOW: the prescriptive one
A Statement of Work is the traditional, detailed approach. The government describes the work in specific terms and frequently dictates the method: the tasks, the sequence, sometimes the labor mix and the tools. It is used when the technical details are well understood and the agency wants the work done a particular way.
A quirk worth knowing: the FAR does not actually define “SOW.” It defines the PWS and the SOO (in FAR 2.101), but the plain Statement of Work is left to convention and to references like the military handbook on the subject. That partly explains why SOWs vary so much in quality and why so many are criticized as either too vague or too prescriptive.
The prescriptive nature carries a consequence that matters to bidders. When the government dictates the method, it also shoulders the risk of that method. If you follow the approach the SOW laid out and the result is unacceptable, the government has limited recourse, because you did what it told you to do. The flip side is less room for you to differentiate. When the “how” is already decided, your proposal competes on showing you can execute the prescribed approach reliably, rather than on a better idea.
PWS: the performance-based one
A Performance Work Statement is the document of performance-based acquisition. The FAR defines it as a statement of work for performance-based acquisitions that describes the required results in clear, specific, and objective terms with measurable outcomes (FAR 2.101). The defining move is that a PWS states what outcome is required and to what standard, rather than prescribing the method. The contractor decides how.
Two features come with that. Every requirement in a real PWS carries a performance standard, something measurable that defines acceptable work, and the government uses a Quality Assurance Surveillance Plan (QASP) to monitor your performance against those standards. The classic illustration is grounds maintenance: a SOW says mow the grass every Tuesday, while a PWS says keep the grass between two and four inches and lets you decide the schedule. The PWS gets the same outcome without dictating the method.
For you as a bidder, a PWS opens room to compete on approach. The government has told you the destination and the standard; your proposal earns its keep by presenting a method that meets the standard better, cheaper, or with less risk than the next offeror’s.
SOO: the objectives-only one
A Statement of Objectives goes the furthest. It is a short government document, included in the solicitation, that states only the top-level objectives of the acquisition. It deliberately leaves out the “how to” instructions, and it tasks each offeror with proposing a full Performance Work Statement in response. The government uses a SOO when it wants maximum flexibility and genuine innovation, and when industry may understand the best approach better than the agency does.
Per FAR 37.602(c), a SOO should contain, at minimum, its purpose, the scope or mission, the period and place of performance, background, the performance objectives (the required results), and any operating constraints. There is no fixed length.
Here is the part that trips people up. The SOO itself does not become part of the contract. The offeror reads the SOO, develops a proposed PWS that lists the tasks and performance standards needed to hit each objective, and that proposed PWS, from the winning offeror, is what gets incorporated into the contract. So a SOO is not just a looser SOW. It is an instruction to write the work statement yourself, which the government will then hold you to.
The labels and the reality do not always match
A caution, because the words get used loosely in the wild. Many agencies call a document a PWS but write it prescriptively, with the same “how to” detail as a SOW, and simply attach a quality assurance plan. The COR’s guidance on the subject notes this directly: the government has been slow to let go of the “how,” and plenty of so-called PWS documents are SOWs wearing a different label. So do not assume the title on the document tells you how prescriptive it is. Read the content. If it dictates method, it behaves like a SOW no matter what the cover page says. If it sets outcomes and standards and leaves the method to you, it behaves like a PWS.
What this means if you are the technical contributor
The document type is a direct signal of how much of the solution design lands on you:
- Under a SOW, the approach is mostly decided. Your job is to demonstrate that you can execute the government’s prescribed method reliably. The technical creativity in your response is bounded, so you compete on credibility and execution.
- Under a PWS, you own the “how.” The government set the outcome and the standard. Your technical approach is where the proposal wins or loses, because you are proposing the method, and a better method is a real discriminator.
- Under a SOO, you are effectively writing the work statement. You define the tasks, propose the performance standards, and build the metrics the contract will measure you against. This is the most technical-judgment-intensive scenario in proposal work, and it is the one where a strong technical contributor adds the most value. The PWS you propose becomes a major factor in the best-value evaluation, so the quality of your thinking is the product.
In all three cases, the document defining the work is Section C of the solicitation, which is exactly why a thorough team shreds it into the compliance matrix alongside Section L and Section M. And in all three, but most of all under a PWS or SOO, the place that work pays off is the technical approach section, where you turn the required results into a method an evaluator can score.
The practical first step is simple: when a solicitation lands, find the document that defines the work and read it for one thing first. Does it tell you how, or only what? The answer reshapes everything you write next.
The Proposal Stack is a newsletter for technical GovCon professionals who get pulled into proposal work and want to contribute well without becoming full-time proposal writers. The guides here decode the vocabulary. The newsletter covers how this plays out in practice, issue by issue. Subscribe here.