Contracting 101: Section C — Finding and Understanding What You Actually Agreed to Do

If Section B tells you what the Government is buying and how it's priced, Section C starts answering the next obvious question: What exactly did we agree to do?

For contracts using the Uniform Contract Format, Section C is titled Description/Specifications/Statement of Work. Depending on how the contract was assembled, the detailed requirements may appear directly in Section C, or Section C may point you to a separate Statement of Work (SOW), Performance Work Statement (PWS), specification, or other document included elsewhere in the contract package.

That makes one of the most important lessons about reviewing Section C surprisingly simple: follow the references. If Section C directs you to a PWS included as an attachment, reading Section C isn't enough. You need to read the PWS and continue following the documents it references until you understand the complete requirement.

Just as importantly, Contracts shouldn't be doing that review alone.

SOW vs. PWS: What's the Difference?

You'll commonly encounter either a Statement of Work or a Performance Work Statement. Although the terms aren't always used perfectly consistently in practice, there is a useful distinction between them.

A Statement of Work (SOW) describes the work the contractor is expected to perform and may include specific tasks, processes, requirements, or methods. A Performance Work Statement (PWS) is used for performance-based acquisitions and focuses on the required results, including measurable outcomes, while generally giving the contractor greater flexibility in determining how those results will be achieved.

In plain language, I tend to think of it this way: a SOW generally focuses more on the work to be performed, while a PWS focuses more on the result the Government needs from that work.

Don't get too hung up on the title, though. From a contract administration standpoint, what matters is understanding what the document actually requires your company to do.

This Shouldn't Be the First Time Your Team Has Seen the Requirement

When the award arrives, the SOW or PWS shouldn't be completely new to your team. You've already reviewed the solicitation, developed a technical approach, built staffing and pricing around the requirement, and submitted a proposal explaining how your company intended to perform the work.

That doesn't mean the final requirement will necessarily be identical to the version you originally proposed against. Requirements can change through amendments, discussions, proposal revisions, and negotiations. That's one reason the post-award review is so important.

One of the first things I want to know is whether the requirement we received at award matches the work we proposed and negotiated.

Compare the final SOW/PWS against the version your team used to develop its proposal. Did the scope change? Are the deliverables the same? Do the staffing requirements align with what you priced? Are the performance standards what you expected? Did something change that affects your technical approach, schedule, staffing, or cost?

Those are questions you want answered before performance begins, not three months into the contract.

Your proposal should be part of that comparison too, but there's an important distinction here: don't automatically assume your entire proposal became part of the contract. Determine whether the proposal, technical proposal, or specific portions of it were expressly incorporated into the final award.

If they were incorporated, those portions are part of the contractual agreement and need to be administered accordingly. If they weren't, the proposal is still an important part of your post-award review because it documents the approach, assumptions, staffing, and pricing your company developed based on its understanding of the requirement.

Either way, if what you proposed and what you were awarded don't line up, stop and understand the difference before you start performing.

Contracts Cannot Review the Technical Scope Alone

This is an area where I think companies sometimes put too much responsibility on the Contracts function.

Contracts absolutely needs to review the SOW or PWS. From a Contracts perspective, I'm looking for contractual obligations, deliverables, reporting requirements, dates, incorporated documents, approvals, notification requirements, potential risk areas, and anything else that needs to be tracked or communicated.

But a Contracts professional isn't necessarily the engineer, scientist, cybersecurity specialist, logistician, software developer, or other technical expert who understands the details of the work being performed.

The appropriate technical lead or subject matter expert needs to review the final SOW/PWS too.

That person should be able to confirm that the technical requirement reflects what the team understood and proposed, and recognize technical details, dependencies, assumptions, or changes that may not stand out to someone reviewing the document primarily from a contractual perspective.

The strongest post-award reviews are collaborative. Contracts understands the contractual obligations. The technical team understands what it takes to perform the work. Program Management understands how the pieces come together operationally. Finance and Program Control understand what the requirements mean for staffing, budget, funding, and performance tracking.

You need those perspectives together.

Read It Like Someone Who Has to Perform It

Once you've confirmed that the awarded requirement is what everyone expected, the review becomes more detailed. You're no longer simply trying to understand the overall mission. You're identifying the individual requirements someone inside the company will have to perform, manage, document, submit, approve, or track.

That includes obvious items such as tasks and deliverables, but also performance standards, reporting frequencies, staffing requirements, key personnel, required qualifications, hours of coverage, place of performance, travel, Government-furnished property or information, meetings, approvals, dependencies, and documentation requirements.

This is also why words such as shall, must, submit, provide, maintain, report, notify, obtain, document, and comply deserve attention. They frequently signal an obligation, and somewhere inside your organization someone needs to know about it.

Some of the requirements that cause problems later don't look particularly significant when you first read them. A sentence in the middle of a paragraph may require notification to the Contracting Officer within a certain number of days. Another may require Government approval before key personnel can be replaced. A monthly report may seem routine until nobody realizes it is due on the fifth business day rather than at the end of the month.

The useful part of contract review is pulling those requirements out and turning them into something the team can actually manage.

The SOW or PWS Doesn't Stand Alone

Finding a requirement in the SOW or PWS is often only the beginning. You may have to look elsewhere in the contract to understand exactly how that requirement is supposed to work.

Suppose the PWS requires a monthly status report. The PWS may describe the report without telling you everything you need to know about it. You may still need to determine when it's due, who receives it, whether there is a required format, how the Government will inspect or accept it, and whether a Contract Data Requirements List (CDRL) or Data Item Description (DID) provides additional instructions.

Those answers can be spread across several parts of the contract. Section E may address inspection and acceptance, Section F may contain delivery or performance information, Section G may provide administration instructions, and Section H may add special contract requirements. Attachments and exhibits may provide another layer of detail.

This is one of the reasons I teach people not to administer a contract section by section. The contract may be organized that way, but the requirements frequently cross sections. Your job is to connect them.

Pay Attention to Referenced and Incorporated Documents

Government contracts can contain a lot of references. Your SOW or PWS may point to technical standards, security requirements, specifications, manuals, attachments, or other documents that add detail to the requirement.

Don't ignore something simply because it isn't printed directly in Section C. Determine how the document is referenced or incorporated and what obligations it creates. The appropriate team members also need access to the documents that govern their work.

Pay attention to revision numbers and dates as well. If the contract identifies a specific version of a document, make sure you're working from the version the contract actually requires rather than whatever version happens to be easiest to find.

The same attention should be given to your own proposal when it, or portions of it, has been incorporated into the award. If your technical proposal is part of the contract, your team needs to understand the commitments contained there just as clearly as it understands the Government's SOW or PWS.

Turn the Scope Into Something the Team Can Use

Once you've identified the requirements, the next step is deciding who owns them and how they'll be managed.

If the PWS requires a monthly report, someone should know who prepares it, who reviews it, when it's due, where it's submitted, and what happens when the person who normally handles it is unavailable. If certain positions require specific qualifications, HR and the Program Manager need that information before recruiting or replacing staff. If Government approval is required before replacing key personnel, that requirement needs to be built into the staffing process rather than discovered after the replacement has already started.

This is where a contract requirements matrix, deliverables tracker, responsibility matrix, compliance calendar, or similar tool becomes valuable. The purpose isn't to create paperwork for the sake of having more paperwork. It's to take requirements buried across a large contract package and turn them into responsibilities that people can actually execute.

Those responsibilities shouldn't stay exclusively with Contracts. Program Management, the technical team, Finance, Program Control, HR, Security, IT, Quality, and other functions may all own pieces of the requirement. The goal is to make sure each stakeholder understands the requirements that affect them and knows what they're responsible for throughout performance.

Scope Doesn't Change Just Because Someone Asked

The SOW or PWS you receive at award may change during performance. Requirements evolve, tasks are added or removed, deliverables change, and the Government's needs can shift. What shouldn't happen is allowing an informal request to quietly become contractual scope.

A COR, Government Program Manager, or technical representative may ask the team to do something that sounds reasonable and closely related to the existing work. That doesn't necessarily mean the person asking has authority to change the contract. Only a Contracting Officer acting within the scope of their authority can execute a contract modification on behalf of the Government.

That doesn't mean every change requires a bilateral modification; contract clauses may authorize the Government to make certain changes unilaterally. It does mean your team needs to recognize when a request may represent a change to the contractual requirement and get Contracts involved rather than simply treating the request as part of the existing scope.

Good scope management isn't about being difficult with the customer. It's about making sure both parties understand what work is being performed, what the contract requires, and whether a change needs to be formally addressed.

The Bottom Line

When you reach Section C, the assignment isn't simply to read Section C. The real goal is to make sure the company understands exactly what it agreed to do.

Start with the final requirement and compare it to what your team proposed and negotiated. Determine whether your proposal, or portions of it, were incorporated into the award. Have Contracts review the requirement for contractual obligations, but make sure the appropriate technical experts review it for the work they actually have to perform.

Then connect those requirements to the rest of the contract and turn them into responsibilities your team can manage throughout performance.

Nothing in that review should be a surprise. If it is, stop and figure out why.

Understanding the SOW or PWS isn't solely a Contracts responsibility or a Program Manager responsibility. It's a team responsibility, and everyone who owns a piece of performance needs to understand what the company actually promised to deliver.