Contracting 101: Section F — Managing Dates, Deliverables, and the Period of Performance

Once you understand what your contract requires you to do, the next question seems pretty straightforward: When do you have to do it?

For contracts using the Uniform Contract Format, Section F is Deliveries or Performance. This is where the contract specifies requirements for the time, place, and method of delivery or performance.

At first glance, it can look like one of the easier sections of the contract. Find the period of performance, put the dates in your tracker, and move on.

Except your contract doesn't really have one date.

It may have an overall period of performance, separate periods for individual CLINs, option periods, delivery dates, recurring deliverables, reporting deadlines, notification requirements, task or delivery order dates, and other milestones scattered throughout the contract.

So, I don't think of Section F as simply the place where I find the POP. I think of it as the starting point for understanding when performance has to happen and how those dates affect the rest of contract administration and project management.

Start With What the Dates Actually Mean

One of the first mistakes you can make is assuming every date in the contract works the same way.

A contract might establish performance using specific calendar dates. Another might require delivery within a certain number of days after award or after the effective date. An IDIQ contract may establish delivery or performance requirements at the individual task or delivery order level.

Those distinctions matter.

If something is due 30 days after award, you need to know what event starts that clock. If a delivery requirement applies to a particular CLIN, you need to know that rather than assuming it applies to the entire contract. If you're working under an IDIQ, the ordering vehicle may have its own ordering period while individual task or delivery orders establish their own periods of performance and deadlines.

Don't just capture the date. Capture what the date belongs to and what triggers it.

Your POP Is Not Your Deliverables Schedule

Knowing that your period of performance runs from October 1 through September 30 does not tell you everything you need to know about when the company has to perform.

Maybe a status report is due monthly. A technical deliverable may be due 60 days after award. A notification could be required within a certain number of days after a specific event. A final report might be due before or after the end of performance. A CDRL may establish its own submission schedule.

And some requirements may be specifically tied to the beginning or end of the POP rather than a fixed calendar date. Something may be due a certain number of days after performance begins, before the POP ends, or within a specified period following completion.

Those requirements may appear in the SOW/PWS, a CDRL, an attachment, a clause, or elsewhere in the contract rather than neatly in Section F.

That's why I wouldn't build a contract calendar from Section F alone.

Start there but then work through the rest of the contract and identify every date-driven obligation that someone needs to manage.

Connect Section F Back to Sections B and C

This is where the sections we've already covered in this series start working together.

Section B tells you what the Government is buying and how it is structured and priced. Section C and the SOW/PWS tell you what work you're required to perform. Section F helps establish when and where that performance or delivery has to occur.

Those pieces should make sense together.

If Section B contains multiple CLINs, I want to understand the period of performance associated with each one. If the PWS requires recurring tasks or deliverables, I want to understand where their due dates are established. If a CLIN has a different POP from the overall contract, that needs to be understood and tracked.

And this isn't just a Contracts issue.

Program Management needs those dates to manage the work. Program Control needs them for budgets, forecasts, staffing, funding management, and project setup. Finance or Accounting may need them to establish the project correctly in the accounting system. The technical team needs to understand the schedule it is responsible for meeting.

A date sitting in the contract doesn't do much good if the people responsible for performing and managing the work don't know it exists.

Dates Should Influence How You Set Up the Project

This is where Section F becomes especially important from a Program Control perspective.

Periods of performance aren't simply dates Contracts needs to track. They can affect how the project is structured, how costs are captured, how funding is monitored, and whether you have enough visibility to understand where the project's costs are actually being incurred.

For example, a contract may contain multiple CLINs with different periods of performance, with funding associated with particular CLINs and ACRNs. Knowing the overall contract POP isn't enough. You need to understand which work is being performed under which CLIN, during what period, and against what funding.

That should be considered when the project is initially established in your accounting or project management system.

If different CLINs have different POPs, funding sources, or reporting requirements, your project structure needs to provide enough visibility to manage those differences appropriately. Otherwise, you may be able to see total project costs while having a much harder time determining whether costs are being incurred against the correct portion of the contract or whether you're approaching a funding limitation associated with the work you're performing.

This is one of the reasons I believe Contracts and Program Control should be working together during project setup. Contracts understands how the award is structured. Program Control understands how that structure needs to translate into charge codes, budgets, forecasts, funding controls, and reporting. Finance or Accounting may also need to be involved depending on the company's systems and processes.

The structure of the contract should help drive the structure of the project.

Trying to figure that out six months into performance is much harder than thinking through it correctly at the beginning.

Options Are Not Automatic Extensions

Option periods deserve special attention because seeing them listed in the contract can create a false sense of certainty.

If your contract has a base year plus four option years, that does not mean you automatically have five years of performance.

The contract establishes the potential for those option periods, but the Government still has to properly exercise the option in accordance with the applicable contract terms. For contracts containing FAR 52.217-9, for example, the clause establishes written-notice requirements associated with extending the term of the contract.

From the contractor side, that means I want option-related dates on my radar well before the current performance period ends. I want to know what the contract says, what notice provisions apply, whether the Government has actually exercised the option, and whether the resulting modification reflects the next period of performance.

This also matters operationally. Staffing plans, subcontract arrangements, budgets, forecasts, funding expectations, and other decisions may depend on continued performance.

There is a big difference between “the contract contains an option” and “the option has been exercised.”

Modifications Mean Your Dates—and Your Systems—May Need to Change

Contract dates don't stay static simply because you captured them correctly at award.

A modification may extend the period of performance, change a delivery date, revise a milestone, exercise an option, add work, change a CLIN, or otherwise affect the schedule.

When that happens, filing the modification in the contract file isn't the end of the job.

Ask: What changed, and who needs to know?

If the POP changes, do the project or charge-code dates need to change? Does Program Control need to revise the forecast? Are budgets or staffing plans affected? Does a subcontract period need to be extended? Did a deliverable date move? Does the change affect how you're monitoring funding?

If your deliverables tracker still shows the original date after a modification changed it, you don't have an accurate tracker. If your accounting system prevents employees from charging after the old POP even though the contract was extended, you have another problem. And if Program Control is forecasting against dates that are no longer valid, the fact that Contracts filed the modification correctly doesn't solve the operational issue.

Contract changes have to make their way into the systems and tools your team actually uses to manage performance.

Pay Attention When the Dates Don't Agree

You may find dates in Section F, Section B, the SOW/PWS, a CDRL, an attachment, an order, or a modification. Ideally, they all work together.

Sometimes they don't.

Maybe the overall period of performance ends September 30, but a deliverable appears to be due afterward. Maybe a modification extended the POP but didn't clearly address another schedule.

Maybe an individual CLIN has a performance period that doesn't seem to align with the work described elsewhere in the contract.

Don't pick the date you like best.

And don't quietly “fix” the discrepancy in your internal tracker.

Figure out what the contract actually requires and, when necessary, seek clarification through the appropriate contractual channel. If there is a genuine inconsistency that affects performance, that's something you want resolved before the deadline becomes a problem.

Turn the Contract Into a Working Calendar

By the time I finish reviewing the contract, I don't want to know only the start and end date. I want to know the dates that actually require action.

That might include performance periods by CLIN or order, deliverable due dates, recurring reports, required meetings, notification deadlines, option-related dates, Government review or approval periods that affect our work, subcontract milestones, and other time-sensitive obligations that need to be managed.

Not every one of those dates will come from Section F, and that's the point.

A good contract calendar is built from the whole contract.

I also want more than a date in a spreadsheet. For an important requirement, I want to know what is due, where the requirement came from, what CLIN or portion of the contract it relates to, who owns it, who reviews or approves it internally, where it goes, and whether we need evidence that it was completed.

That's the difference between maintaining a list of dates and actually managing the contract.

The Bottom Line

Section F may be shorter than some of the other sections of your contract, but don't mistake shorter for less important. The FAR considers time of delivery or performance an essential contract element, and from a contractor's perspective, those dates can affect nearly every part of performance.

Start with Section F and understand the time, place, and method of delivery or performance. Then connect those requirements to Section B, the SOW/PWS, your deliverables, applicable clauses, attachments, orders, modifications, funding, and internal project structure.

Most importantly, don't walk away from your review knowing only that “the POP ends September 30.”

Know what work is authorized during that period, which CLINs and funding support it, how your project is structured to capture and manage the associated costs, what deliverables or other obligations are triggered by the beginning or end of that period, and who is responsible for each requirement.

Your contract doesn't have one date. It has a schedule of obligations that should drive how your team sets up, performs, tracks, and manages the work.