How to Read a PWS: The 5 Things Every Contractor PM Must Check Before Signing

Before we get into the checklist, a quick orientation on the documents themselves, because a lot of contractor PMs use the terms interchangeably, and they shouldn't.

PWS vs. SOW vs. SOO: What Each One Actually Is

Document	Full Name	What It Does	Who Controls the How?
SOW	Statement of Work	Describes tasks and activities the contractor must perform. Prescriptive: tells you what to do and often how to do it.	Government
PWS	Performance Work Statement	Describes outcomes and performance standards: what success looks like, not exactly how to achieve it. Contractor has more latitude in approach.	Contractor (within defined standards)
SOO	Statement of Objectives	States high-level goals and objectives, letting contractors propose their own PWS or technical approach in response. Most flexible format; often used in best-value acquisitions.	Contractor (proposes the approach)

You'll see a PWS on a lot of defense services work, because the FAR pushes agencies to describe services in terms of required results rather than how the work gets done (FAR 37.602). The PWS is your scope bible. It defines what you're being paid to do, what the government expects to receive, and under what conditions they'll consider your work complete. If there's a dispute about scope, the PWS is where both sides start.

The 5 Things Every Contractor PM Must Check in a PWS

Check 1: Period of Performance

Sounds basic. It's not. The period of performance (PoP) defines the start and end date of your obligation, and it has real implications for staffing, resource planning, and risk.

What to look for:

• Is the base PoP realistic for the scope? If the PWS describes two years of work crammed into a 12-month base period with options, you need to understand what happens if the options don't get exercised. Can you complete a meaningful deliverable in the base period, or are you set up to produce an incomplete product with no follow-on funding?
• When does the PoP start? Some contracts use date of award. Others use a specific date or a "date of receipt of notice to proceed" (NTP). The difference affects when your clock starts for deliverables.
• Are there option periods, and what triggers them? The FAR defines an option as a unilateral right of the government (FAR 2.101). The government decides whether to exercise it, at the option prices you proposed, and you don't get to renegotiate at renewal. Know the exercise window and any advance notice the contract promises.
• Are there any activities that must be completed before the PoP ends regardless of when they start? Transition-in requirements, initial deliverables, certifications, anything with a fixed due date tied to contract award.

Check 2: Deliverables and CDRLs

The PWS describes what you'll do. The CDRLs (Contract Data Requirements List) describe what you'll formally deliver. These two documents need to align, and they often don't perfectly.

What to look for:

• Does every major work product in the PWS have a corresponding CDRL? If the PWS says you'll produce monthly status reports but there's no CDRL for it, the submission schedule and format are undefined. That ambiguity usually resolves itself on the contractor's time and cost.
• Are the CDRL due dates achievable? Look at the first deliverable due date relative to PoP start. If a major report is due 30 days after award and you need government-furnished data to write it, you have a problem.
• What is the review and approval timeline? CDRLs often specify a government review period (e.g., 30 days). If the government doesn't approve within that window, what happens? If your next deliverable depends on approved output from the previous one, an approval bottleneck can cascade.
• Are revision requirements defined? How many revision cycles are included? What's the turnaround requirement? Vague language here means unlimited free revisions until someone draws a line, usually you.

Check 3: Government-Furnished Equipment and Information (GFE/GFI)

Government-Furnished Equipment (GFE) and Government-Furnished Information (GFI) are things the government promises to provide so you can do your work. They're also one of the most common sources of contract disputes.

What to look for:

• Is every GFE/GFI item specifically listed? "The government will provide necessary data" is not a commitment. A specific list of documents, systems, access credentials, equipment, and delivery dates is a commitment. If it's vague, ask for specificity during Q&A before award.
• When will GFE/GFI be provided? If you can't start work without government-furnished data and the PWS doesn't commit to a delivery date, you're taking schedule risk that isn't yours to own. Document this risk in your proposal and flag it during pre-award Q&A.
• What condition will GFE arrive in? Equipment that's supposed to be operational but arrives broken creates a delay that the government will argue is your problem. Establish at contract kickoff what the baseline condition of GFE is and document it.
• Who is responsible for maintenance of GFE during the PoP? This should be explicit. If you're using government-furnished servers and they go down, who has the obligation to fix them, and on what timeline?

Check 4: Acceptance Criteria

This is where ambiguity costs the most money. Acceptance criteria define when the government will formally accept a deliverable as complete. Without clear criteria, "done" is whatever the COR decides it is on any given day.

What to look for:

• Are acceptance criteria objective and measurable? "The report will be clear and comprehensive" is not a criterion. "The report will include sections A through G as defined in Attachment 1, formatted per the Data Item Description (DID) listed on the CDRL, and delivered within 5 business days of the reporting period" is a criterion.
• Is there a defined government acceptance period? If the government has 30 days to accept or reject a deliverable, that's defined. If the PWS says "the government will review," that's undefined, and an open-ended review period means an open-ended obligation on your side.
• What happens at rejection? How many rejection-resubmission cycles are anticipated? What are the performance standards for resubmission quality? If you fix a deficiency and resubmit, does the review clock restart?
• Who has authority to accept deliverables? The COR? The CO? A Technical Representative? If acceptance authority is unclear, you may get conditional acceptances from people who don't actually have authority, which creates contract compliance issues later.

Check 5: Special Contract Requirements

Section H of the contract (or an equivalent special requirements section in the PWS) is where non-standard, program-specific obligations live. Many PMs read Section C (the PWS) carefully and skim Section H. That's a mistake.

What to look for:

• Security requirements. What clearance levels are required? What facilities must be used? Are there special handling requirements for classified or CUI materials? What's the timeline and process for getting new personnel cleared?
• Key personnel clauses. If specific individuals are designated as key personnel, you usually can't replace them without government approval. Know who is designated key, what the approval process is for substitutions, and what qualifications are required for replacements.
• Organizational Conflict of Interest (OCI) restrictions. Does the contract restrict future work with certain entities? Are there firewall requirements between this work and other contracts? OCI problems can knock you out of future competitions, and breaking an OCI clause in your contract can put the contract itself at risk (FAR Subpart 9.5).
• Travel requirements and limitations. Is travel required? Is it funded separately from the base labor? Is there a travel cap? Travel that's required but not funded in the contract is a cost risk.
• Reporting and metrics requirements. Beyond CDRLs, are there informal reporting obligations (recurring briefings, dashboard updates, COR meeting requirements)? Understand the full reporting load before you staff the program.

The Devil Is in the Definitions

One of the most underused sections of any PWS is the Definitions section, usually near the front. The government defines specific terms in that section for a reason. Those definitions control how the entire rest of the document is interpreted.

Pay attention to how the PWS defines words like "support," "coordinate," "assist," "ensure," and "maintain." These words carry very different scope implications:

• "Support" or "assist": typically a supporting role to someone else's lead. Lower cost, less accountability.
• "Coordinate": sounds passive but often implies you own the process of getting people aligned and the burden if they don't get there.
• "Ensure": you're on the hook for the outcome, not just the effort. If you "ensure" a system is operational, it needs to be operational.
• "Maintain": implies continuous obligation, not a one-time task. Staffing implications matter here.

Read every sentence in the PWS that describes your obligations using these verbs. Ask yourself: Can I price this obligation based on what this word means? If the answer is no, you need clarification before award.

What to Do When You Find a Problem Before Award

Found ambiguous language? A GFE commitment that's too vague? Acceptance criteria that don't define "done"? Here's the right move: ask the question during the solicitation Q&A period.

Most RFPs (Requests for Proposal) set a deadline for written questions, and it can come well before proposals are due, so find the date in the instructions to offerors (Section L) on day one. This is your chance to put specific, well-framed questions to the government in writing and receive official written answers that become part of the solicitation record.

Good Q&A questions:

• Reference the specific section and paragraph of the PWS.
• State the ambiguity neutrally. Don't editorialize.
• Ask a specific, answerable question.
• Don't ask questions that reveal your pricing strategy or technical approach.

Example of a good Q&A question: "PWS Section 3.2 references government-furnished data. Will the government provide a specific list of data sets and delivery dates? Offerors require this information to develop a realistic schedule baseline."

If you don't ask, you don't get a clarification. And if you don't get a clarification, you either price the ambiguity (expensive) or assume the favorable interpretation (risky). Neither is a good position once performance starts.