A construction schedule review checklist, sorted by what decides each item
Most schedule review checklists are a flat list. That is the wrong shape, because the items on it are not the same kind of question. Some are settled by the file and nothing else. Some cannot be settled at all until you know which specification the contract incorporates, because the number changes from agency to agency. And some are not decidable by any tool, ever, by anyone who has not seen the site and read the contract.
This checklist is sorted by that cut. Each item says what to look at, what a problem looks like, and — the part most checklists leave out — what it does not prove on its own. A schedule can be clean on every mechanical item on this page and still be unbuildable.
A note on numbers before you start. This page states no threshold of its own. Where a named authority publishes one it is attributed and linked: the DCMA 14-point metrics, the GAO Schedule Assessment Guide, or a specific agency clause on the agency comparison page. Where no authority we can cite states a number, the item tells you to count the thing and compare the count against the specification governing your project. That is not modesty; a generic threshold asserted in our own voice would be an opinion dressed as a check.
How this relates to what the packs check
CONFORMANCE.md §4 is the published list of what the rule packs do not check, clause by clause — cost loading, activity coding, resource loading, scheduler qualifications, narrative content, submittal transmittals, software admin preferences. This page is the other side of that list: the review a person still has to run, and the part of it a file can shorten. The two are meant to be read together, and neither is a superset of the other.
Part 1 — Mechanical: decidable from the file alone
Every item here is a query over the imported schedule. A reviewer can settle it without the contract, without the site, and without asking anybody a question. These are the items worth automating precisely because they are boring, and they are the ones a reviewer most often runs out of time for.
1. Open ends
Look at: every activity that is not the project start or the project finish milestone, and check whether it carries at least one predecessor and at least one successor.
A problem looks like: an activity with nothing driving it, or nothing depending on it. An open-ended activity floats free of the network: its dates are produced by its constraint or its calendar rather than by the logic, and a delay to it propagates nowhere.
It does not prove: that the logic is wrong. Some open ends are deliberate and some are artefacts of an extract. What it proves is that the computed dates for that activity mean less than the dates around it. Thresholds differ sharply — DCMA §4.1 states a figure that should not be exceeded, while the AACE source-validation reading this project implements allows no tolerance at all and requires a predecessor and a successor on every activity but the two endpoints. Which applies to you is a question about your contract.
2. Dangling logic
Look at: activities whose predecessors bind only their start, or whose successors are driven only by their start. A start-to-start tie in with no finish-to-start or finish-to-finish tie out leaves the finish unconstrained.
A problem looks like: an activity that can run for any duration without pushing anything. It has a predecessor and a successor, so an open-ends count passes it, and it is still effectively detached at one end.
It does not prove: anything about intent. Dangling logic is what you get from an ordinary modelling shortcut as often as from manipulation. It matters because it hides duration growth from the completion date.
3. Negative float
Look at: the distribution of total float, and specifically anything below zero. Then look at why: negative float is produced by a constraint, by a contractual completion date the network cannot meet, or by a backward pass anchored on something other than the last activity's own finish.
A problem looks like: a schedule showing the job late against a date the contract requires. Several agencies prohibit negative float in a baseline outright — VDOT is one — and DCMA §4.7 states that ideally there should be none.
It does not prove: who caused it, or that time is owed. Negative float is the arithmetic consequence of a constraint meeting a duration. The reason sits in the constraint inventory, item 6, and the entitlement question is not a schedule question at all.
4. Out-of-sequence progress
Look at: activities showing progress before their predecessors are complete, and then at the scheduling option in force — retained logic or progress override changes what the remaining work is allowed to do.
A problem looks like: work started ahead of its driving logic. The plan and the execution have diverged, and the forecast is now computed through relations the job is not honouring.
It does not prove: a breach. The specifications disagree on this in plain text: the NAVFAC Division 01 section states out-of-sequence progress is not allowed and names no approval route, while the USACE section at §3.3.13 permits it case by case subject to the Contracting Officer's approval. One schedule, two answers, and which one is right is a fact about which section your contract carries. See the UFGS page.
5. Actual dates beyond the data date
Look at: every actual start and actual finish, compared against the data date. Then the reverse: forecast dates sitting before it.
A problem looks like: an activity recorded as having happened in the future. It is one of the few purely arithmetic errors in scheduling, and it is unambiguous. DCMA §4.9 states there should not be any.
It does not prove: that the rest of the status is sound. A file can be clean on this and still carry percent-complete figures nobody earned. The check that would settle that reads the quality control daily reports, which are not in the schedule file — which is why the UFGS rule for it abstains until those records are supplied.
6. Constraint inventory
Look at: every constraint in the file, by type and by activity: mandatory, start-on, finish-on, as-late-as-possible, and the rest. Count them, then read each one.
A problem looks like: a mandatory constraint overriding logic, or a constrained activity sitting at exactly zero float. DCMA §4.5 states a ceiling on hard constraints as a share of incomplete tasks.
It does not prove: that the constraint is artificial. This is the single clearest case on the page. UFGS §3.3.8 prohibits artificial float constraints — and artificiality is intent, which no computation reaches. What a tool can honestly report is the population the prohibition describes: constrained activities at zero float, listed, for a person to read. It cannot report that they breach the clause. See ALAP, mandatory and start-on constraints in the glossary.
7. Calendar inventory
Look at: how many calendars the file declares, how many activities use each, which declare holidays and non-work periods, and whether the hours per day agree across them.
A problem looks like: a calendar assigned to a handful of activities for no stated reason, a holiday list that is empty on a job spanning a winter, or working-time definitions that disagree between calendars in a way that makes durations non-comparable.
It does not prove: manipulation. An over-restrictive calendar is one of the three mechanisms NYSDOT names as float suppression, and a calendar that reflects a genuine seasonal restriction is the same object in the file. The inventory is the evidence; the reading is the reviewer's. How calendars are stored in an XER covers what actually survives an export.
8. Activity count and duration profile
Look at: the number of activities, the distribution of original durations, and the count of activities above whatever cap applies.
A problem looks like: a schedule too coarse to manage the work, or too granular to maintain — and the specifications put numbers on both ends. Caltrans §8-1.02C states a band on the activity count and a band on the per-activity duration in working days. WVDOH §108.3.1.4 bounds the count from both sides, relative to contract value, and caps durations in working days. NYSDOT states its own cap, and the USACE section states one that the activity's calendar selects between two figures. Six authorities, six answers — this is the most-specified check in construction scheduling and it has no universal number.
It does not prove: that a long activity is wrong. A long-lead procurement item is long because procurement is long. Most of the specifications that state a cap also state exemptions, and the exemption list is part of the clause.
9. Relationship-type mix
Look at: the share of links that are finish-to-start, and the count of each other type. Then the start-to-finish links specifically.
A problem looks like: a network built mostly on start-to-start and finish-to-finish ties, which makes the critical path harder to trace and float harder to interpret. DCMA §4.4 states a floor on the finish-to-start share and says start-to-finish should be very rare and justified. Several agency specifications ban start-to-finish outright.
It does not prove: anything about the sequence being right. Overlapping trades genuinely overlap, and a schedule of a linear job may legitimately be dense with start-to-start ties.
10. Lag and lead inventory
Look at: every link carrying a lag, every link carrying a lead (negative lag), the calendar each lag is computed on, and lags attached to relationship types where they compound.
A problem looks like: a lead, which lets a successor start before its predecessor's driving event and can hide a duration inside the logic. Also: a long lag doing the work an activity should do, so that the time is in the network but nobody is accountable for it. DCMA §4.2 states the goal for leads and §4.3 a ceiling on lags as a share of links.
It does not prove: that any individual lag is unjustified. UFGS treats reasonableness of lags as a question requiring a person; the honest output is the inventory plus the question, not a verdict.
11. Critical path continuity
Look at: whether a continuous chain runs from the earliest activity to the completion milestone, and whether the set of activities on the longest path matches the set at zero total float.
A problem looks like: a broken chain, or a divergence between the two sets. Divergence is normal under some settings and diagnostic under others — an activity at zero float that is not on the longest path usually has a constraint behind it.
It does not prove: that the critical path is credible. That is item 21, and it is judgement.
12. Declared scheduling settings
Look at: what the file records about how it was calculated: retained logic or progress override, whether open ends were treated as critical, how total float was defined, the critical-path definition in force.
A problem looks like: a setting that changes the answer without appearing anywhere in the printed schedule. A schedule recalculated under different settings from the one it is compared against is not comparable to it.
It does not prove: an error. It is the precondition for every other number on this page meaning the same thing across two updates. What an XER file carries covers which settings survive the export and which do not.
Part 2 — Clause-dependent: you must know the specification first
Every item below is decidable, and none of them is decidable until somebody states which document governs. There is no industry default to fall back on, and substituting one silently is how a review produces a confident wrong answer. Ask which specification the contract incorporates, then read the number off it.
| Item | What varies between specifications | Where to look |
|---|---|---|
| Maximum activity duration | The cap, the units (working or calendar days), and which activity classes are exempt | Agency comparison |
| Activity count band | Floors, ceilings, and whether the band scales with contract value | WVDOH, Caltrans |
| Narrative content | Whether one is required at all, and the headings it must carry | Agency comparison |
| Update frequency and deadline | Monthly, and how many days after the data date the submission is due | Agency comparison |
| Initial submission deadlines | Preliminary and detailed schedule due dates, counted from award or from notice to proceed | WVDOH, UFGS |
| Float ownership | Shared, belonging to the project, or split into named classes with one owned by the agency | Float ownership |
| Required software and format | Named product, version floor, and submission file format | Schedule file formats |
| Share of activities allowed on the longest path | Capped, bracketed for the specifier to fill in, or not stated at all | UFGS, Caltrans |
| Near-critical threshold | Stated as a float value in working days by some agencies, derived from update frequency by others | Caltrans |
| Time impact analysis | Whether one is required, prospective or retrospective, and which method is named | Delay method comparison |
| Constraint types permitted | Which constraints may be used, and which require written acceptance | Agency comparison |
| Out-of-sequence progress | Prohibited outright, or permitted case by case | UFGS |
Two practical notes on this part.
A specification binds where the contract incorporates it, not where the agency name matches. A Caltrans clause applies where the bid item list carries the CPM bid item; a VDOT category III provision applies where that category, rather than category I or II, is the one the contract carries — and the clause numbering shifts between categories, so citing the wrong category cites a different requirement under the same number.
Some of these documents are not contract terms at all. An agency's reviewer training manual and its sample comment library state what its staff look for; they state no requirement the contractor agreed to. That distinction is worth making explicitly in a review comment, because a comment citing training material as though it were a specification is the one a contractor will push back on first.
Part 3 — Judgement: no tool decides these, and the checklist should say so
Each item below names who decides it. That is the useful content: not a box to tick, but the name of the person whose call it is.
13. Are the durations achievable?
Decided by the people who will do the work, against production rates, crew sizes and quantities. A duration is a claim about productivity, and nothing in a schedule file carries the quantity it is a rate for. A review can ask for the basis; it cannot compute the answer.
14. Does the sequence reflect how the work will be built?
Decided by the superintendent and the design team. This is the item that most often produces the genuinely valuable review comment, and it is entirely outside the file: knowing that a particular tie is impossible, or that two activities cannot share the same area, requires knowing what the activities are. An agency's own review comment library bears this out — a large share of the comments filed under its judgement heading turn out to be ordinary lag-and-window rules blocked on exactly one thing: knowing which activity is which trade. That classification boundary, not scheduling logic, is what keeps most of those comments manual.
15. Is the critical path credible?
Decided by the reviewer, reading the chain end to end. A continuous longest path is mechanical; whether the chain it runs through is the one that will actually control the job is not. A critical path running through submittals and procurement for two-thirds of its length is arithmetically sound and tells you something is modelled wrong.
16. Is the scope complete?
Decided against the contract documents and the drawings. Missing scope is invisible to every check on this page: a schedule missing an entire work item is internally consistent, passes its open-ends check, and computes a completion date that means nothing.
17. Is a change a true impact?
Decided by the contract administrator, and in a dispute by the reviewing authority or a tribunal. The schedule can show that a completion date moved between two updates and can decompose that movement into what the work did and what somebody revised about the plan — that decomposition is mechanical, and CONCEPTS.md §7 describes it. Whether the movement is an impact for which time is owed is not a schedule question.
18. Is a revision a correction or a rewrite?
Decided by whoever holds the update log. Between two updates, activities get added and deleted, lags change, constraints change, durations change and calendars change. All of that is detectable. Whether a given change repaired a modelling error or moved the goalposts requires the reason for the change, and the reason is not in the file.
What a clean mechanical pass does not mean
This is the part of the checklist that matters most, and it is the reason to read Part 1 with Part 3 rather than instead of it.
A schedule that is clean on every item in Part 1 has demonstrated that it is internally consistent and computable. It has demonstrated nothing about whether the work can be done that way, whether the durations are real, whether the scope is complete, or whether the party who submitted it is entitled to anything. Those questions were never in the file.
The inverse is also true and is worth stating to a contractor: a schedule with findings against it is not thereby a bad schedule. Most mechanical findings have an ordinary explanation, and the review comment that carries the explanation alongside the count is the one that gets resolved in one pass instead of three.
What this tool does with the list
It runs Part 1, cites the clause behind each finding, and names the activity by the identifier a planner sees in their own software rather than an internal key. For Part 2 it checks against the clauses of whichever specification you name, and where a clause needs a number the file does not carry — a contract completion date, a list of accepted constraints, a quality control record — it reports that it could not decide and names the input that would settle it. For Part 3 it assembles the evidence and states the question, and stops.
Whether a submission is acceptable is the reviewing authority's determination. See what it does, the rule packs and their dependencies, and the limitations.
Related reading
- Float ownership across the specifications — the one item in Part 2 where the documents genuinely disagree on principle rather than on a number.
- DOT and federal requirements compared — the clause-by-clause table behind Part 2.
- The DCMA 14-point metrics — where most of the attributed thresholds on this page come from.
- GAO-16-89G — ten best practices with no pass-or-fail thresholds, deliberately.
- Concurrent delay and delay method comparison — for what happens after review, when the argument starts.
- Glossary — float, lag, data date, longest path, constraint types.
Source: web/pages/schedule-audit-checklist.md. Source commit date: 2026-09-11.