UFGS 01 32 01.00 10, Project Schedule — a clause-by-clause reference

Edition: August 2026, superseding February 2023. Preparing activity USACE, jointly issued with NAVFAC and AFCEC. References are in agreement with the UMRL dated July 2026. Verified 11 September 2026 against the PDF at wbdg.org/FFC/DOD/UFGS/UFGS 01 32 01.00 10.pdf — go to the PDF directly; the HTML landing page returns an empty shell.

UFGS 01 32 01.00 10 is a United States Government work and carries no copyright, so this page quotes it. That is the point of the page: for each requirement, the sentence that states it, with its section number, so a reviewer can check the quotation rather than trust a paraphrase. Every quotation below is from the August 2026 edition.

Part 2 — what software you may use

§2.1.1 states plainly: "The Government uses Primavera P6. Ensure exported schedule files are compatible with the version of P6 used by the Government."

The Contractor is not required to use it. §2.1.2.2, Other Than Primavera, sets the terms:

If the Contractor chooses software other than Primavera P6, that is compliant with this specification, provide for the Government's use two licenses, two computers, and training for two Government employees in the use of the software. These computers will be stand-alone and not connected to Government network.

If P6 is chosen, §2.1.2.1 requires the .xer export in a version no newer than the Government's, with the version confirmed at the kickoff meeting.

A note on the words "approved" and "compliant" on this page. They appear only inside quotations of the specification, and in every case they describe what the Contracting Officer does. This project approves nothing and decides no submission; whether a schedule is acceptable is the reviewing authority's determination. Quoting the clause that says so is a fact about a public document.

Part 3 — general requirements

§3.1 requires CPM network calculation and the Precedence Diagram Method for every schedule, pursuant to FAR Clause 52.236-15. §3.1.1 establishes the Scheduling Expectations Kickoff Meeting (SEKO), held with the post-award or preconstruction conference, where the Government reviews the scheduling specification and states its expectations. Several later clauses defer decisions to that meeting — the file naming convention (§3.5.1), the P6 version in use (§2.1.2.1), and an alternative to the weather calendar (§3.3.9).

§3.2 ties the schedule to money: "The schedule is the basis for determining contract earnings during each update period and therefore the amount of each progress payment." §3.2.3 permits the Contracting Officer to withhold 10 percent of a pay request where directed schedule revisions have not been incorporated.

The detailed schedule requirements (§3.3)

§3.3.1 Level of detail. The schedule is developed "to the appropriate level of detail to address major milestones and to allow for satisfactory project planning and execution", and failure to do so "will result in its disapproval". Worth noting for anyone citing this clause: the paragraph closes by announcing that the Contracting Officer "will consider, but is not limited to, the following characteristics and requirements to determine appropriate level of detail" — and in the published August 2026 text, no list follows before §3.3.2 begins.

§3.3.2 Activity durations. "Non-procurement activities Original Durations (OD) are not to exceed 20 workdays or 30 calendar days." Two numbers, one sentence. The reading that makes both operative is one limit selected by the activity's calendar — 30 where the calendar works all seven days, 20 otherwise; reading it as both makes the second number unreachable, and reading it as whichever is larger makes the first decorative. The clause does not say which.

§3.3.4 Procurement. Long lead procurement activities are "those with an anticipated procurement sequence of over 90 calendar days."

§3.3.8 Contract milestones and constraints. "The use of artificial float constraints such as 'zero free float' or 'zero total float' are prohibited. Mandatory constraints that ignore or affect network logic are prohibited. No constrained dates are allowed in the schedule other than those specified herein." Additional constraints go to the Contracting Officer case by case.

Three named milestones follow. §3.3.8.1: the first activity is a start milestone titled "NTP Acknowledged" with a Start On constraint at the acknowledgement date. §3.3.8.2: the last activity is a finish milestone titled "End Project", constrained to the Contract Completion Date so that an early finish shows positive float on the longest path and a late finish shows negative float. §3.3.8.3: contractually specified interim completion dates are constrained "to show negative float when the calculated late finish date of the last activity in that phase is later than the specified interim completion date." Phases use "Start Phase X" and "End Phase X" milestones (§3.3.8.3.1–.2).

§3.3.9 Adverse weather. AACE 84R-13 supplies the methods; "The preferred methodology is the use of a weather calendar." Anything else is discussed at the SEKO meeting.

§3.3.10 Calendars. The default calendar matches the physical work plan "with non-work periods identified including weekends and holidays", with seven-day calendars for Government acceptance activities and concrete cure, and seasonal calendars where applicable.

§3.3.11 Open ended logic. "Only two open ended activities are allowed: the first activity 'NTP Acknowledged' is to have no predecessor logic, and the last activity - 'End Project' is to have no successor logic." Everything else needs at least a start-to-start or finish-to-start predecessor and a finish-to-finish or finish-to-start successor. Predecessor open ends may be allowed in a time impact analysis with approval.

§3.3.13 Out-of-sequence progress. Allowed "only on a case-by-case basis subject to approval by the Contracting Officer", with logic corrections proposed before the update is submitted and the condition addressed in the narrative. This is one of the clauses where UFGS and its NAVFAC sibling diverge: UFGS 01 32 17.00 20 §1.4.2.f says out-of-sequence progress is not allowed, with no approval route stated.

§3.3.16 Leads, lags and start-to-finish. "Lags must be reasonable as determined by the Government and not used in place of realistic original durations, must not be in place to artificially absorb or create float, or to replace proper schedule logic." Then two flat prohibitions: "a. Leads (negative lags) are prohibited. b. Start to Finish (SF) relationships are prohibited."

§3.3.17 Retained logic. Calculations "must retain the logic between predecessors and successors ('retained logic' mode)" even where a successor has started and its predecessor has not finished; progress override "are not be allowed" — the grammatical slip is in the published text.

Submissions (§3.4) and what goes with them (§3.5)

• §3.4.1 Preliminary — "Within 15 calendar days after the NTP is acknowledged", detailing the first 90 calendar days, cost loaded to the award CLINs, summary in nature beyond that, used for payment for up to 90 days.
• §3.4.2 Initial — "Submit the Initial Project Schedule for approval within 42 calendar days after notice to proceed is issued", covering the entire performance period. "No payment will be made for work items not fully detailed in the Project Schedule."
• §3.4.3 Periodic updates — "Update the Project Schedule on a regular basis, monthly at a minimum." Actual start and finish dates "must match the date(s) reported on the Contractor's Quality Control Report".

§3.5.1 requires the electronic scheduling data in the software's own format ("e.g. .xer"), carrying the schedule type, full contract number, data date and file name, with the naming convention fixed at SEKO.

§3.5.2 Narrative Report is a stand-alone PDF or Word document titled "Schedule Narrative Report", and it is the clause most often under-served. Eight items are required as a minimum: work scheduled to start next period; activities on the critical path "in addition to activities on the next float path after the critical path"; current and anticipated problem areas, delaying factors and corrective action, identifying the party responsible for delay if applicable; activities that should have started or finished by their late dates and did not; every schedule change by activity ID and name, including new and deleted activities, logic, duration, calendar, lag, resource and actual date changes; out-of-sequence work; an explanation of the factors driving any change in the longest path from one monthly update to the next; and responses to USACE schedule review comments from previous updates.

The update cycle (§3.6) and weekly meetings (§3.7)

§3.6.1: meetings "at least monthly within five days of the proposed schedule data date", lasting no longer than 8 hours, with the schedule file and narrative submitted "a minimum of two workdays in advance of the meeting." Only changes approved in that meeting go into the resubmission, and "Only approved schedules may be used to generate invoices for payment." §3.6.2 sets the resubmission clock: "not later than 4 workdays after the periodic schedule update meeting."

§3.7 adds a three-week lookahead at the weekly QC meeting, with two bracketed options the specifier chooses between — a weekly progressed file uploaded to the contract system of record, and a separate weekly schedule meeting. The bracketed text is explicit that the weekly file "does not supersede the current Periodic Schedule Update" or serve as a basis for acceptance.

Time extensions (§3.8)

§3.8 sets the frame: ASCE 67-17 provides the delay analysis guidelines, the contract governs any conflict with them, and justification of delay goes to the Contracting Officer "within 10 days of a delay occuring".

§3.8.3 Time Impact Analysis (prospective) — for impacts that have not yet occurred. "Prepare a time impact analysis for approval by the Contracting Officer based on industry recommended practice AACE 52R-06. Utilize a copy of the last approved schedule prior to the first day of the impact or delay." Where that schedule is too old, an interim update is prepared; no other changes may be incorporated without the Contracting Officer's approval.

§3.8.4 Forensic Schedule Analysis (retrospective) — for impacts that have already occurred, and it "must account for the actual performance of both the impacted work and all other contract work in the schedule." On method: "If a methodology is chosen from AACE 29R-03, the method must adhere to the principles identified in ASCE 67-17. If there is a conflict with the methodology chosen from AACE 29R-03 and ASCE 67-17, ASCE 67-17 will govern."

§3.8.6 sets the entitlement test: "No time extension will be granted unless the delay consumes all available Project Float and extends the projected finish date ('End Project' milestone) beyond the Contract Completion Date."

Failure to achieve progress (§3.9)

Where progress falls behind for reasons that are not excusable, the Contracting Officer may require a written recovery plan detailing how progress will be made up. §3.9.1 then forecloses the cheap route:

Artificially improving progress by means such as, but not limited to, revising the schedule logic, modifying, or adding constraints, shortening activity durations, or changing calendars in the project schedule is prohibited.

Anything the recovery plan proposes in resources, manpower or work hours "must be evident at the work site and documented in the daily report".

Ownership of float (§3.10)

Except for the provision given in the paragraph IMPACT TO EARLY COMPLETION SCHEDULE, float available in the schedule, at any time, belongs to the Project and is available for Contractor and Government use. This includes activity and project float.

Activity float is defined as the workdays an activity can slip without delaying the End Project milestone; project float as the work days between the projected early finish and End Project. Compare the state agencies, where four documents say float is shared between the parties and Caltrans assigns named portions of it to each.

§3.12 Primavera P6 Mandatory Requirements — the eleven settings

The clause most worth a reviewer's time, because every item is a file or software setting rather than a judgement. "The following settings are mandatory and required in all schedule submissions to the Government:"

Items f and g restate §3.3.17 and §3.5.4.3 as declared settings, which is what makes them checkable: the exported file states what the scheduler chose, so the clause can be answered from the file rather than from an opinion about the network. P6 records the choice on the project row — CT_DrivPath for Longest Path, CT_TotFloat for the total-float definition — so item f is answerable from an exported .xer without re-running the schedule.

What this project does with this section

This section is implemented as a rule pack that checks an imported schedule against these clauses and cites the clause in every finding. Where a clause needs a fact the schedule does not carry — an approval record, the NTP acknowledgement date, the phase list, the contract completion date — the rule reports that it could not be evaluated and names the missing input, rather than supplying an industry default. Clauses that are not computations at all, such as §3.3.16's "lags must be reasonable", assemble the evidence and state the question for the reviewing authority to answer.

Reading a report: how findings are laid out · how rules are organised · what the tool does not do. Related pages: the state DOT comparison · the standards crosswalk · GAO's Schedule Assessment Guide · glossary.

Source: web/pages/ufgs-scheduling.md. Source commit date: 2026-09-11.