SOW, PWS and SOO for Software Companies: How Federal Requirements Are Written

Every federal contract for software or services has a section that says what the contractor will actually do. In the uniform contract format it is Section C, and it comes in three main forms: a statement of work (SOW), a performance work statement (PWS) or, before award, a statement of objectives (SOO) that asks you to write the PWS yourself.

The form the agency chooses tells you a lot about how it wants to buy, how it will measure you, and how much room you have to propose your own approach. This guide covers what each document is, how they differ, and how a software company should read and answer each one. It is written for founders, capture leads and whoever writes the technical volume.

---

Where the requirement sits

In an RFP using the uniform contract format, Section C holds the description of the work, whether that is a specification, a SOW or a PWS. Section B lists the line items and prices, Section F covers deliveries or performance, and Section J lists attachments, which is often where a long PWS, a quality assurance surveillance plan or a SOO is attached. Our guide to Sections L and M covers how the instructions and evaluation criteria relate to it.

Orders under an IDIQ or a GSA Schedule carry the same kind of document, usually shorter. Each task order request has its own SOW, PWS or SOO, and the scope of the order is limited to it.

---

Statement of work: what to do

A statement of work describes the tasks the contractor will perform, and often how and with what resources. A software SOW might list the environments to stand up, the reports to deliver each month, the number of help desk staff and their hours, and the tools to use.

SOWs are clear about effort and easy to price task by task. Their weakness is that they buy activity rather than outcomes. A contractor can perform every listed task and the system can still fall short, and any better method you know of has to fit inside the tasks as written. If the SOW specifies a technology or a staffing model, that is the one you propose unless the solicitation invites alternatives.

---

Performance work statement: what result, measured how

A performance work statement is the core document of performance-based acquisition under FAR Subpart 37.6. The FAR states a preference for performance-based acquisition when agencies buy services, and FAR 37.602 asks agencies, to the maximum extent practicable, to:

• describe the work in terms of required results, rather than how the work is to be done or the number of hours to be provided;
• enable assessment of performance against measurable standards; and
• rely on measurable standards and financial incentives in a competitive environment to encourage innovative and cost-effective methods.

For a software company, a PWS reads more like a service level agreement than a task list. Instead of “provide three engineers to maintain the application,” it says something like “the application is available 99.9 percent of the time each month, measured by the agency’s monitoring” or “critical defects are resolved within one business day.”

A PWS is usually paired with a quality assurance surveillance plan (QASP), which describes how the government will check performance against the standards. Under FAR 37.604, the agency may write the QASP itself or ask offerors to propose one. Read the QASP as closely as the PWS: it says what will be measured, how often, and what happens when you miss.

---

Statement of objectives: write your own PWS

A statement of objectives goes one step further. The government states what it wants to achieve and the constraints it works under, and each offeror proposes its own PWS. Under FAR 37.602, a SOO includes at least:

• the purpose of the acquisition;
• the scope or mission;
• the period and place of performance;
• background;
• performance objectives, meaning the required results; and
• any operating constraints.

Offerors use the SOO to develop the PWS, but the SOO itself does not become part of the contract. The PWS you propose does, once the government accepts it.

SOOs suit software well, because the best method is often what the agency wants to discover. Guidance for digital services acquisitions, including the TechFAR Handbook, discusses the SOO as a fit for agile development, where the backlog will change during performance. Our guide to modular contracting and agile covers how agencies break software work into smaller pieces.

---

How the three compare

	Statement of work	Performance work statement	Statement of objectives
Who writes the work description	The government	The government, or the offeror in response to a SOO	The government writes objectives; the offeror writes the PWS
What it describes	Tasks, and often methods and resources	Required results and measurable standards	Objectives and constraints
How performance is judged	Whether the tasks were done	Against the standards, often through a QASP	Against the standards in the PWS you propose
Room for your own approach	Limited	Moderate	Wide
Part of the contract?	Yes	Yes	No; your PWS is

In practice, many documents mix the styles. A PWS can still include a few required tasks, and a SOW can include performance standards. Read for substance, not for the label at the top.

---

How to read one before you bid

• Read it before the evaluation criteria. Section C or its attachment defines what you will be held to. Sections L and M define how you will be scored. You need both, and the work description comes first.
• Find every “shall.” Build a compliance matrix of each requirement and where your proposal answers it. A requirement you missed is a weakness in evaluation and a dispute after award.
• Check the standards against your product. If the PWS requires a level of availability, response time or security posture, compare it with what your product and your hosting actually deliver today, not what is on the roadmap.
• Look for assumptions about staffing. A SOW that counts heads or hours fits a staffing model. If you sell a product with support, say how your approach meets the need, and confirm the solicitation allows it.
• Look for licensing and data terms. Requirements for source code, deliverables or data delivery affect your intellectual property. Our guides to software license terms and data rights cover what to look for.
• Ask questions in writing. Use the solicitation’s question period. If a draft RFP or a sources sought notice comes first, comment on the requirement then, while it can still change.

---

How to write a PWS in response to a SOO

When the government gives you a SOO, your PWS becomes the contract’s description of the work. Write it the way you would want it enforced.

• Map every objective. Show which part of your PWS meets each objective in the SOO, in the same order.
• State results you can measure. Pick standards you can meet consistently and that the government can verify, such as availability, defect resolution times or release cadence.
• Say how they are measured. Name the data source and the period, and propose a QASP if the solicitation asks for one.
• Keep it achievable. Every standard in an accepted PWS is a promise. An ambitious number that helps in evaluation can become a performance problem, and a record in your past performance, if you miss it.
• Respect the constraints. Operating constraints in the SOO, such as security requirements, hosting locations or interfaces with existing systems, carry over even though the SOO itself does not.

---

After award: scope is the boundary

Once the contract is signed, the SOW or PWS marks the edge of what you agreed to do.

• Compare each request with the scope. If a program office asks for something new, check whether the work statement already covers it. If it does not, it needs a change from the contracting officer, not a conversation with the program office. Our guide to contract modifications covers who can authorize what.
• Do not absorb unwritten changes. Extra work done at the direction of someone without authority may not be recoverable. Our guide to claims and equitable adjustments covers what happens when the government changes the work without a formal modification.
• Watch the standards. On a performance-based contract, the standards in the PWS and the QASP decide whether performance is acceptable, so track them yourself rather than waiting for the government’s assessment.
• Read the current rule text. The FAR is being rewritten under the Revolutionary FAR Overhaul, so section numbers and wording may change. Confirm the provisions in each solicitation, and get advice from counsel when a term is unclear.

---

What this means for a software company

• The label tells you how you will be measured. A SOW measures tasks, a PWS measures results, and a SOO asks you to define the results yourself.
• Performance-based is preferred for services. Expect more PWSs and SOOs, and be ready with standards your product can meet.
• A SOO is an opportunity. It lets you propose the approach your product is built for, but the PWS you write becomes binding.
• Scope protects both sides. Read it before you bid, and check every new request against it after award.

---

Where this fits

The work statement is where a buyer’s requirements meet your product. Before you respond, it helps to know how your company looks across the categories federal buyers review, from compliance posture to registration and federal track record. Score your company’s federal readiness to see where you stand.

---

Related reading

• Reading a Federal RFP: Sections L and M for Software Companies
• Modular Contracting and Agile Delivery for Software Companies: How Agencies Buy in Increments
• Contract Modifications for Software Companies: Bilateral, Unilateral and the Changes Clause
• Tradeoff vs. LPTA for Software Companies: How Agencies Weigh Price Against Quality
• Sources Sought and RFIs for Software Companies: Why Answering Early Shapes the Contract
• Glossary: IDIQ · Task order · GSA Schedule