Performance Work Statements: How Government Defines Requirements

A Performance Work Statement (PWS) describes the required outcomes and performance standards for a service contract, rather than prescribing how work should be done.

Key characteristics:

• Outcome-focused — defines what, not how
• Measurable standards — clear success criteria
• Contractor flexibility — choose your approach
• Performance accountability — tied to QASP

PWS vs SOW:

• PWS — Describes outcomes and performance standards
• SOW (Statement of Work) — Describes specific tasks and methods

Why agencies prefer PWS:

• Encourages contractor innovation
• Focuses on results, not process
• Shifts risk to contractor
• Simplifies government oversight

See also: RFP Response Guide

Typical PWS components:

1. Introduction/Background:

• Agency mission and context
• Why this requirement exists
• Relationship to larger programs

2. Scope:

• Overall boundaries of the work
• Geographic locations
• Applicable time periods

3. Performance Objectives:

• What outcomes are required
• How success is measured
• Acceptable quality levels

4. Deliverables:

• Specific outputs required
• Delivery schedules
• Format requirements

5. Applicable Documents:

• Referenced standards
• Regulations that apply
• Agency policies

6. Special Requirements:

• Security requirements
• Certifications needed
• Transition considerations

How performance is measured:

PWS includes or references performance standards that define acceptable performance.

Common metrics:

• Quality — Accuracy, defect rates, compliance
• Timeliness — On-time delivery, response times
• Quantity — Volume, throughput
• Customer satisfaction — Survey scores, complaints

Acceptable Quality Level (AQL):

• Minimum acceptable performance
• Below AQL = performance failure
• Often expressed as percentage (e.g., 95% on-time)

Linked to QASP:

The Quality Assurance Surveillance Plan (QASP) defines how the government will monitor performance against PWS standards.

Consequences of failure:

• Payment deductions
• Negative CPARS
• Termination for default
• Non-exercise of options

See: Quality Assurance Guide

What to look for:

Critical requirements:

• Shall vs. should vs. may — "Shall" is mandatory
• Performance metrics with consequences
• Key personnel requirements
• Clearance requirements

Hidden challenges:

• Unrealistic timelines
• Conflicting requirements
• Vague performance standards
• Inadequate government support assumed

Discriminators:

• Where can you differentiate?
• What efficiencies can you offer?
• What innovations are possible?

Questions to ask (during Q&A):

• Clarify ambiguous requirements
• Understand evaluation priorities
• Get data on current performance
• Identify unstated assumptions

Bid/no-bid factors:

• Can you meet all mandatory requirements?
• Are the standards achievable?
• Is the scope stable?

Proposal approach:

Compliance first:

• Map every PWS requirement to your proposal
• Use compliance matrix
• Address every "shall" explicitly
• Show how you'll meet each standard

Technical approach:

• Describe your methodology
• Explain why it achieves outcomes
• Include processes and tools
• Show innovation where appropriate

Management approach:

• How you'll organize the work
• Quality control processes
• Risk mitigation
• Communication with government

Staffing approach:

• Key personnel qualifications
• Staff mix and ratios
• Recruiting and retention
• Training programs

See: Compliance Matrix Guide

Statement of Work (SOW):

• Describes specific tasks and steps
• Government prescribes methods
• Contractor executes as directed
• Less contractor flexibility
• Used for well-defined requirements

Performance Work Statement (PWS):

• Describes outcomes and results
• Government defines "what," contractor decides "how"
• Contractor responsible for achieving results
• More contractor flexibility and risk
• Used for performance-based contracts

Which is better?

PWS advantages for contractors:

• Opportunity to innovate
• Can leverage your expertise
• Efficiency gains benefit you

PWS challenges:

• More risk if standards are aggressive
• Must understand outcomes deeply
• Can't blame poor specs for failure

SOW advantages:

• Clear direction
• Less interpretation required
• Government shares more risk

Proposal mistakes:

• Parroting the PWS — Just restating requirements without approach
• Missing mandatory elements — Overlooking "shall" requirements
• Generic approaches — Not tailored to specific PWS
• Overpromising — Committing to unachievable standards

Execution mistakes:

• Ignoring metrics — Not tracking performance standards
• Scope creep — Doing work outside PWS
• Poor documentation — Can't prove compliance
• Late notification — Not flagging issues early

Interpretation mistakes:

• Assuming intent when language is unclear
• Not asking questions during solicitation
• Interpreting ambiguity in your favor

Best practices:

• Read PWS multiple times
• Create requirements traceability matrix
• Ask clarifying questions
• Document your interpretation

Managing to the PWS:

Performance tracking:

• Monitor all metrics continuously
• Track trends before problems occur
• Report performance proactively
• Address issues immediately

Scope management:

• Know what's in scope and what's not
• Document out-of-scope requests
• Request modifications for scope changes
• Don't perform free work

Documentation:

• Keep evidence of deliverables
• Document performance data
• Maintain correspondence
• Track issues and resolutions

Customer communication:

• Regular status reporting
• Early warning on issues
• Collaborative problem solving
• No surprises

See: CPARS Guide for performance ratings