The Scheduler's Standard

A schedule is a model of how the job will actually be built — a falsifiable claim about crews, sequence, and time. It is simultaneously three other things: a communication instrument (the only document on the project that everyone from the foreman to the CFO reads), a measurement instrument (progress, payment, and earned value all hang off it), and a legal record (in any dispute, the schedule chain is Exhibit A, and tribunals use it to judge not just delay but your credibility). Every rule in this document exists to protect one of those four functions. When you're unsure why a rule exists, ask which function it defends.

Hold on to this number: SmartPM's analysis of more than 50,000 real construction CPM schedules rated 88% of them at medium-to-high risk of being ineffective — with missing logic the leading cause. The industry's base rate is failure. Most schedules are decoration around a date somebody wanted. The whole point of this document is to put you in the other 12%.

The NDIA's Generally Accepted Scheduling Principles (GASP) are the cleanest definition of the target I know. Eight tenets — the first five make a schedule valid, the last three make it effective. The order matters: polishing dashboards on an invalid schedule is the standing anti-pattern of our profession.

Start from the contract, not from the software

Build a deliverable-oriented WBS from the contract scope before you write a single activity, and hold it to the 100% rule: every WBS level captures all of the scope of the level above — nothing invented, nothing missing. GAO's first best practice is "capture all activities" because omitted scope is the defect that kills schedules quietly: the file looks complete, the metrics pass, and the critical path is fiction because the work that actually governs isn't in it. [GAO-16-89G BP1 · AACE 23R-02]

Decompose the way the job is actually managed — phase → area/floor → discipline/trade → work package — and mirror the cost-code/CSI structure, so the schedule, the estimate, the daily reports, and the pay application all speak the same language. When those four documents share a coordinate system, every cross-check in this guide becomes mechanical instead of heroic.

And scope means everyone's scope. The scope that gets forgotten is never yours — it's the owner's and the world's: design reviews, environmental permits, AHJ inspections, utility tie-ins, owner-furnished equipment, phased NTPs. Each is an activity with a duration and a responsibility code — never an assumption buried in a lag. For the owner, a scheduled obligation creates accountability. For you, it is the contemporaneous record that establishes entitlement when their review runs long. No activity, no clean delay analysis. [UFGS 3.3.6 · 78R-13]

Activity design — the three rules

One nature of work per activity. One responsible party, one trade, one feature of work, one location. "Submit and review shop drawings" must be split — you submit, they review, and responsibility for delay must land on exactly one party. "Install drywall and paint" must be split — different crews, different QC, different production rates. This rule, more than any duration cap, is what makes a schedule usable as a monitoring tool, a payment instrument, and a claims record at once. [UFGS 3.3.7]

Duration must be measurable between updates. The governing principle, stated verbatim in the federal spec: durations must "allow the progress of ongoing activities to be accurately determined between update periods." An activity longer than about two update cycles can't be objectively statused — percent complete becomes a negotiation instead of a measurement. The hard caps: 20 workdays under UFGS for non-procurement work; DCMA flags a schedule when more than 5% of incomplete tasks exceed 44 working days. Procurement and fabrication are the recognized exception — vendor elapsed time, not crew work. The design test is simpler than the caps: if you can't say what 50% done looks like, the activity is too big. [UFGS 3.3.2 · DCMA #8]

Names and IDs carry information. Verb-noun-location names with the defining content in the first 30 characters ("INSTALL CULVERT STA 0+00–1+00", not "Culvert works phase 2 continued"). Structured IDs with an area/discipline prefix and numeric gaps of 4–10 (FOUND-100, FOUND-110) so activities can be inserted without renumbering — because renumbering destroys update-to-update comparability, and that comparability is the audit trail every forensic analysis depends on. A tool-assigned A1000-series ID carries zero information and forces every reviewer to rebuild context. [UFGS 3.12 · Ten Six]

Two P6 disciplines ride with the coding: keep activity codes and calendars at project level, never global — global data does not survive an XER exchange with the other party — and keep IDs at 10 characters or fewer. [UFGS 3.12]

Level of detail — one model, five altitudes

You do not build five schedules; you build one network and present it at five levels. Detail lives where the work is near; far-future work rides in coarser packages that still carry logic to the contract milestones — that logic is what keeps the critical path and float meaningful through the back of the job. This is rolling wave, and the discipline that keeps it honest is detailing the next wave before the work arrives (the federal spec forces it: no payment for work not fully detailed). [AACE 37R-06 · PASEG]

The four relationship types — and the honest uses of each

Finish-to-start is the default for a reason: it produces an unambiguous handoff whose status can't be argued. DCMA expects ≥90% FS; a healthy practitioner profile runs about 80% FS, 10% SS, 10% FF. Start-to-finish is effectively banned everywhere — it inverts normal logic and is almost always either a modeling error or a trick to hold a date. [DCMA #4 · UFGS 3.3.16]

The lag doctrine

A lag may represent exactly one thing: a genuinely time-consuming non-work condition — concrete cure, settlement. Never work. Work hidden in a lag is invisible: it cannot be statused, resourced, coded, or seen on any report, and the lag portion of a path never shows percent complete. The federal doctrine, verbatim in spirit: lags must be reasonable, must not substitute for realistic durations, must not absorb or create float, must not replace logic. [UFGS 3.3.16]

• FS links carry no lag. A lag on an FS almost always means a missing activity. Make the activity.
• A lag never exceeds its predecessor's duration. If it does, the thing it represents deserves to be an activity.
• Leads (negative lags) are banned — zero. A lead claims the successor can start before its driver has produced anything. It distorts float, hides the true driver, and when the overlap proves infeasible it becomes the owner's interference-claim exhibit. Overlap honestly: split the predecessor, or use SS with a positive lag.
• Even cure is better as an activity — "Cure slab, 3d" on a 7-day calendar. A lag has no calendar of its own on display, and P6 evaluates it on whichever calendar a global option picks (Part 4). Winter's advice: model it visibly.

Open ends — exactly two

One activity with no predecessor (NTP), one with no successor (project completion). Everything else carries at least an FS or SS predecessor into its start and an FS or FF successor off its finish. The reason is mechanical: an activity with no successor cannot transmit delay — its slip silently vanishes from the completion forecast, and its float is meaningless. Open ends are the cheapest way to game float, which is why owner specs are stricter than DCMA's 5% tolerance. And do not "fix" open ends by wiring everything to the finish milestone — the statistic goes green while the network still can't propagate delay through the real work; you've hidden the defect from the next reviewer. [UFGS 3.3.11 · DCMA #1]

Hard logic, soft logic, and the one question that separates them

Hard logic is physics: foundations before columns, rough-in before cover-up. Preferential (soft) logic is your chosen sequence among feasible alternatives: which wing first, which way the crew flows. The interrogation question for every tie is — "what physically prevents the successor from starting earlier?" If the answer is a crew, a preference, or a resource rather than physics, the tie is preferential, and you must know it, because preferential logic is exactly what gets resequenced in a recovery and exactly what gets challenged in a claim as self-inflicted float sequestration. Disclose your major preferential decisions (crew flow direction, area order) in the basis document, so reviewers can tell plan choices from physical necessity. [AACE 24R-03 · 78R-13]

Crew logic — the silent killer

A network with only hard logic shows one drywall crew working every floor simultaneously. Then a delay hits, activities stack on top of each other in the model, and the schedule says the slip is recoverable when no contractor on earth could staff that stacking. Crew logic — soft ties chaining a crew's successive areas (drywall L2 → drywall L3) — is what makes the model tell the truth about a finite workforce. Its absence is the single most damaging omission in construction schedules. The visible signature of a healthy network is the trade train: each trade enters an area only after the predecessor trade releases it.

Procurement chains — where the real critical path lives

Every long-lead item (rule of thumb: any submit→approve→fabricate→deliver sequence over 90 calendar days) gets the full explicit chain: prepare/submit shop drawings → review & approval → fabrication → delivery → install, with review durations set to the contractual period — commonly 21–30 calendar days on federal work — not the optimistic 7-day cycle that forces rushed approvals. Work backward from required-on-site dates to derive latest-submittal dates, and code review activities to the owner so their queue time is visibly theirs. Submittal slippage compounds: two weeks late on a custom-equipment submittal routinely becomes six weeks on delivery, because you lost your fabrication slot. [UFGS 3.3.4]

Know the current lead-time reality cold — a scheduler who doesn't is building fiction. As of 2025–26: medium-voltage switchgear 52–80 weeks, pad-mount transformers 40–65, substation-class transformers 75–110, diesel generators 50–78 (large units 90–110), big UPS 30–60, applied chillers ~40, custom AHUs 16–28. The data-center rule generalizes: if you're not ordering electrical gear 12–18 months before mobilization, you're already behind. [Terrapin CG 2026]

The end of the job is organized by systems, not areas

Construction proceeds area by area; startup and commissioning proceed system by system — and your logic must pivot where they meet. Mechanical completion of a system spans areas; central plant starts before distribution; power, controls, water, and ductwork all converge before an AHU starts; TAB, functional testing, and integrated systems testing run in sequence, not in one "commissioning" bar. A baseline that carries area logic to the end systematically understates the finish — the last 5% of ten areas is the first 100% of every system, and the schedule must show which incomplete area blocks which system. Tie substantial completion to this systems logic; it is what stops liquidated damages. [UFGS 3.3.5]

Durations are computed, not felt

The formula is not optional: Duration = Quantity ÷ (crew daily output × number of crews × efficiency) — output from your own history first, subcontractor input second, RSMeans crew tables or DOT production-rate databases third, with an efficiency factor for congestion, weather exposure, and site conditions. The reason is auditability: when the owner challenges a 15-day duration, "take-off shows 12,000 SF at 800 SF/day" ends the argument; "experience" does not. The same quantities feed the cost loading, so time and payment stay coherent — and the build-up exposes infeasible plans before day one, because a milestone that needs a production rate no crew has ever achieved is wrong at submission, not at month nine. [FHWA · RSMeans · UFGS 3.3.15]

Two tells reviewers use on your durations, so use them on yourself. Honest long durations come in even multiples of 5 workdays; odd durations on or near the critical path (a 23 here, a 31 there) are the classic sign someone reverse-engineered the network to land on a date. And concurrent activities of the same trade must sum within the crews the estimate actually carries — the histogram check below. [Winter]

Calendars — where work is allowed to happen

Assign each activity the calendar its work logically belongs to: the 5-day project calendar with holidays for crew work; a 7-day calendar for cure and owner acceptance periods; seasonal calendars for paving and earthwork; weather calendars for weather-sensitive outdoor work. The weather calendar is the contract-preferred method (AACE 84R-13): take the anticipated adverse-weather table — NOAA 30-year normals, stated per month — and block those days as non-work days, so weather-sensitive durations stretch automatically without padding. A practitioner's trick: place the blocked days Tuesday–Thursday so they never collide with Monday holidays. Why it matters beyond neatness: weather scatter in calendars — not durations — is what lets a time-extension analysis cleanly separate unusually severe weather (excusable) from the normal weather you already own. A contractor who never planned normal weather cannot claim it. [UFGS 3.3.9 · AACE 84R-13 · Winter]

And one discipline that will save you a Part-4-sized headache: every calendar carries the same hours per day (8) and the same day start/end times. Mixed day-lengths corrupt float display and date arithmetic at the boundaries.

Resource loading and the histogram test

Load the baseline because an unresourced schedule is a set of unfalsifiable assertions — durations that can't be checked against crews, recovery plans that can't be verified, payment that can't flow from progress. On owner work the schedule is the payment mechanism: activity cost aggregates exactly to the pay items, the earnings report from the update drives the invoice, and front-end loading is prohibited by name. Cost-load closeout deliberately — punch list at ≥1% of contract value, O&M manuals, as-builts — so money remains on the table to keep crews engaged through turnover. [UFGS 3.2, 3.3.20 · GAO BP3]

Then run the one feasibility check no metric replaces: the manpower histogram, per trade. It should build, plateau, and taper — roughly bell-shaped. Sharp isolated spikes mean trade stacking or missing crew logic. A peak far above the trade's average (suspicion starts around 1.5–2×) means the plan needs more crews than the market, the site, or supervision can support — and check the peaks against site capacity: hoisting, laydown, badging. A baseline whose histogram is infeasible will fail in month three no matter how clean its DCMA score is. [78R-13]

On leveling: the auto-leveler answers a real question ("with these resource limits, when does the work finish?") but produces dates no logic trace can explain, unstable across runs — and float from a leveled schedule is fiction. For a contractual baseline, encode resource reality as crew logic instead, and keep the critical path traceable. If you must level, declare it, and stop quoting float. [Weaver]

Margin — time owned on purpose

Three different things get called "float," and confusing them is expensive. Total float is a shared network byproduct — it belongs to the path (and contractually, usually to the project), and whoever needs it first uses it. Contingency/margin is deliberately allocated reserve, sized from risk analysis, owned by the PM, and visible. Padding is margin hidden inside durations or lags — invisible, consumed silently by whoever runs late first, double-counted the moment a risk analysis adds uncertainty on top, and condemned by every owner spec and float-sequestration case. The honest implementations: a named, zero-resource schedule margin activity immediately before the completion milestone (NASA/PASEG practice — consumption shows as its duration shrinking); or the project float between your early finish and the contract date, disclosed. NASA's sizing defaults where no risk analysis exists yet: 1–2 months of margin per year of duration in design and construction, roughly double through integration and testing. [NASA SP-2010-3403 · PASEG · AACE 70R-12]

The two passes

The forward pass walks the network left to right: each activity's early start is the latest condition imposed by all of its predecessor links — not just the last FS one — and early finish = ES + duration, counted on the activity's own calendar. The backward pass mirrors it from the finish: late finish is the earliest condition imposed by all successor links; late start = LF − duration. Total float is the gap between the two: TF = LF − EF = LS − ES.

One hand-calculation trap: in whole-date arithmetic, EF = ES + Dur − 1 — a 1-day activity starts and finishes on the same date — while a time-based engine like P6 computes at instants (start 08:00, finish 17:00) and never shows the −1. If your hand check is off by exactly one day, you mixed the two conventions. [Weaver]

The float taxonomy — and what each number is for

Float is an output. You never type it, never "manage" it directly; you change it only by changing logic, durations, calendars, or constraints. Anyone who asks you to "add float" is asking you to change the model — make them say which input they want changed.

Constraints — classify by which pass they touch

A constraint is a date wired into the passes. Sort every type by what it clamps, and the safe-versus-dangerous split falls out on its own:

The policy that falls out (and that owner specs codify): two constrained dates — a Start On at NTP, a late-finish constraint on contract completion (so negative float becomes a meaningful early-warning signal) — and everything else earns its constraint case by case, documented. Every float conversation begins with a constraint inventory. [UFGS 3.3.8 · DCMA #5]

Multiple calendars — why the longest path stops matching lowest float

Float is stored in hours and expressed in each activity's own calendar, so the same real-world slack reads as different numbers on different calendars — and a driving-path activity can carry phantom float across a calendar boundary. Weaver's canonical case: a 24×7 engineering activity finishing Friday 21:00 feeding a 5×8 commissioning activity that can't start before Monday 08:00 shows 59 hours of float while sitting on the critical path. This is why "filter TF ≤ 0" draws a critical path with holes in a multi-calendar schedule, and why P6's Longest Path option exists: criticality by driving-relationship trace from the latest finish, not by float value. Know its limits too — it traces one chain, ignores paths driving interim milestones, and needs the Multiple Float Path tool to enumerate the parallel drivers. Defenses: common 8-hour days everywhere, as few calendars as possible, critical = longest path, and a TF ≤ 2-day band to sweep in near-parallel work across weekend gaps. [Weaver · Harris · AACE 49R-06]

Out-of-sequence progress and the three calculation modes

When work starts before its logic allows — and it will — the scheduling mode decides where the remaining work goes. This single setting changes the forecast more than most logic edits:

If retained logic's forecast looks wrong because the crew genuinely will continue out of sequence — fix the logic to match the field (that is what the update is for), don't switch the mode. Winter's surveys of real schedules put the scale of OOS beyond argument: roughly 36–40% of started activities start out of sequence, an average of ~70 workdays early. OOS is the normal condition. Part 7 covers the discipline. [Harris 2023 · Winter 2018–19]

P6 internals that bite — the short list

First, the right posture: the DCMA 14-point assessment is a minimum integrity floor, not a certification of realism. A schedule can pass all fourteen and still be unbuildable, unresourced, and unowned. Every threshold is a tripwire that obligates investigation — the expert response to a red metric is "why is it like this, and is the reason documented," never "make the number green." Cosmetic fixes are worse than red metrics, because they hide the defect from the next reviewer. [DCMA-EA PAM 200.1]

GAO's ten practices, four characteristics

GAO-16-89G is the owner-side acceptance framework: ten best practices rolling up into four characteristics of a reliable schedule. The assessor's trick worth stealing: the practices are interrelated — a major deficiency in sequencing (BP2) automatically caps the scores for the critical path (BP6), float (BP7), and traceability (BP5). One rotten practice poisons the set.

The review beyond the metrics

The quantitative screen must be paired with the qualitative review the metrics cannot see (AACE 78R-13): full scope inclusion, constructability of the sequence, timing/phasing sanity (weather windows, seasons), contract compliance, clear activity descriptions, resource balance, appropriate level of detail. And the acceptance process itself is a negotiation with rules of restraint — the owner shouldn't insist beyond the contract, acceptance is not approval-as-liability-transfer, and an accepted baseline legally functions as the reference frame for every future negotiation. Two review-table traps: an early-completion baseline (accepting one can make the owner liable for delay costs even if the job finishes by the contract date — demand full resource loading before entertaining it), and unenforced spec deviations (repeatedly letting a clause slide can waive it; acknowledge deviations in writing, with limits). [Winter · 78R-13]

Finally: a baseline is not reviewable without its basis document (AACE 38R-06) — scope basis, duration and productivity bases, calendars including weather, constraint inventory, float strategy, calculation settings, long-lead assumptions, exclusions, and the risk position. The schedule records what and when; the basis records why. Without it, change management has no reference, your successor inherits a black box, and in a dispute you cannot prove what the plan assumed.

In Hulett's worked construction case, the deterministic completion date had about a 4% chance of being achieved, and the P80 sat roughly seven months later. Three mechanisms drive that gap: duration estimates are optimistic and their distributions right-skewed (there are more ways to be late than early, so the mean lands later than the P50); risk events — things that may or may not happen — are absent from the deterministic model entirely; and network structure adds merge bias at every point where parallel paths converge. [Hulett · GAO BP8]

What to do about it

• Run the schedule risk analysis — and run it on a healthy schedule. AACE 64R-11's first section is "minimum conditions of satisfaction": constraints clip simulated distributions and open ends stop delay propagation, so an SRA on a sick network is a confidently wrong S-curve. Health first, simulation second.
• Attach risks, not just ranges (AACE 57R-09): give each register risk a probability and a multiplicative impact range, assign it to the activities it affects, and let the simulation fire it per iteration. Cause-and-effect survives; correlation emerges naturally; and you can rank mitigations by re-running with each risk removed and measuring days saved at the target percentile. 20–40 strategic risks and ~3,000 iterations is the working scale, even on very large programs.
• Read the right indices. Criticality index = share of iterations an activity lands on the critical path — parallel near-critical paths each carrying meaningful CI is the quantitative signature of merge bias. Cruciality = correlation of activity duration with project duration. The Schedule Sensitivity Index combines them and is the best single ranking: it discounts critical-but-certain tasks (they can't hurt you) and volatile-but-never-critical ones. The classic failure is briefing the deterministic critical path as "what to watch" while the tornado chart shows the P80 driven by a different path entirely.
• Set contingency from a percentile, not a percentage. Contingency = (date at chosen confidence) − (deterministic finish). P80 is GAO's "conservative" benchmark; P50–P65 is riskier than it sounds because the distribution is right-skewed. Hold it as a visible margin activity before the completion milestone — one aggregated block, not dispersed crumbs that get consumed prematurely — and re-run the SRA at decision points and whenever the burn outruns the plan.
• Track the near-critical band, not just the zero-float path. AACE 92R-17's insight: size the band by the time you'd need to take corrective action — if re-sequencing crews takes 15 working days, any path within 15 days of critical can go unrecoverable before you can react. And trend the band: a path burning 5 days of float a month will overtake a static critical path (Part 9).

Collect status at the workface

Walk the job with the schedule in hand. See the physical state — rebar set versus poured versus stripped — then confirm dates against the daily reports, never against memory. The contractual teeth are real: on federal work, actual dates that contradict the daily QC reports are explicit grounds for schedule disapproval, which blocks the pay application. And in a dispute, every contradiction between your actuals and the dailies impeaches the whole schedule as a record. Status weekly even when you report monthly — problems should surface before the month closes, not in the update meeting. [UFGS 3.3.12 · GAO BP9]

The interview at the workface is six questions per activity (PASEG): started? — when. Not started? — when will it, and what's blocking it. Finished? — when. Not finished? — how many workdays to finish (remaining duration, never percent). What's physically complete? And for loaded work, what hours remain? Ask duration, not percent, because a foreman seven days into a ten-day activity says "70%" even when all the hard work is left — "how many more days" is a question field people can actually answer.

The two questions are independent

Remaining duration answers "how many workdays of work remain." Physical percent answers "how much of the deliverable exists." They are independent judgments, entered separately, with the software link between them disabled — the spec says it verbatim: independent functions. The engine only ever forecasts from RD; earned value only ever reads physical %. Let the tool derive one from the other and you get the 90% syndrome: the schedule "finishes" arithmetically while the work stalls — teams reporting 90% by impression are routinely 60–70% by effort, because the tail (testing, punch, integration, closeout) is the open-ended part. Structural defenses: earn % from measured quantities; re-estimate RD from the work actually left and the crew actually available; compare duration-% against physical-% every period and chase divergence; and when an activity lingers at high percent, split the remainder into its own activity so the tail has a duration, logic, and an owner. [UFGS 3.3.12/18/19 · PASEG 9.1.2]

The forecast is a production-rate calculation

For quantity-driven work, remaining duration = remaining quantity ÷ demonstrated rate — the recent 3–4 week actual from the dailies, not the bid rate, not the baseline rate. Planned 20 boards a day but running 12? The RD is computed at 12 until something concrete changes — a named crew, a second shift — and the update meeting is where that something gets named. This single habit, applied to every critical and near-critical activity, is what separates a forecast from a wish, and it moves completion dates months before a percent-driven schedule admits a problem.

Blocked work gets modeled, not dragged: if it waits on an incomplete predecessor, status the predecessor and let logic move it; if the blocker is unmodeled — a permit, an RFI, an owner decision — add the missing predecessor, because "awaiting decision on CO-14" in the network is a contemporaneous causation record, while a silently dragged date is nothing. Suspended work gets split, so the restart is a discrete activity with remobilization time in it.

And when recovery is claimed, believe it on three conditions only: the mechanism is named and resourced (crews, shifts, resequence — visible in the loaded schedule); the implied production rate doesn't materially exceed anything demonstrated; and one or two update cycles actually show the promised rate before downstream commitments believe it. Run PASEG's bow-wave check as the standing counter-test: unstarted tasks pushed one period ahead, every period, compress the final months into a rate spike the project has never achieved.

Out-of-sequence discipline

Expect a third of started activities to be out of sequence — that's the measured base rate, so a report showing zero OOS means nobody looked. The routine: run the OOS report every period, and first verify the predecessors' status — a large share of "OOS" is a statusing error, classically a forgotten procurement activity nobody marked complete. For real OOS, repair the logic to match how the field is actually building, case by case with the superintendent; leave it only when it's a benign early start against soft logic, and even then say so in the narrative — the spec demands either the correction or the justification, never silence. Never "clean up" OOS by flipping to progress override. [Winter · UFGS 3.3.13]

The cycle, in order

The narrative — eight elements, none optional

The monthly narrative is analysis, not a table dump — the spec's phrase is your "thorough analysis of the schedule output." The federal standard is the cleanest checklist in the industry: [UFGS 3.5.2]

1. Work scheduled to start in the next period.
2. The critical path, described in words — and the next float path behind it.
3. Problem areas and delaying factors, their impact, corrective actions, and the responsible party.
4. Activities that per their late dates should have started or finished this period but didn't — and why.
5. Every schedule change, by activity ID, with its reason — additions, deletions, logic, durations, calendars, lags, resources, actual-date changes. All of them.
6. Out-of-sequence work, with the correction or the justification.
7. An explanation of the drivers whenever the longest path changed from last period.
8. Written responses to the owner's prior review comments.

Element 5 deserves the emphasis: the reviewer will diff your native file and find every change anyway. An undisclosed change discovered by the reviewer reads as manipulation even when innocent — and one such discovery converts every future submission into an adversarial review. Disclose everything; run the diff yourself first.

Writing for the record

State facts with dates and activity IDs. Identify delays and causes in the period they occur — a delay first mentioned twelve months later looks invented, and the notice clock (typically 5–28 days, 21 common) may have already killed the entitlement. Record weather against the contract's anticipated table. Log time-extension requests and their status. Never casually assign yourself fault, and never stay silent about a problem the daily reports show — silence next to a documented problem is impeachment material. The monthly exchange of update, narrative, review comments, and responses is the schedule record of the project. [AACE 45R-08]

Revision control and the re-baselining sin

Between updates: actuals and remaining-duration re-estimates are your normal work. Structural changes are controlled — activities are not added or deleted without approval (an ID or description change counts as a new activity); original durations don't change without justification; approved change-order fragnets, coded to their mod, are the legitimate vehicle for new scope. Never delete from a baselined schedule — zero it, mark it, document it — because deletion breaks logic and destroys comparability.

Re-baselining is legitimate exactly when the contract changes the plan of record: an executed mod with time, a directed and accepted recovery schedule, an agreed resequencing — processed through change control, with the superseded baseline archived, never overwritten. Re-baselining because the variances have grown embarrassing is the cardinal sin: it erases the variance history, converts the schedule into a political instrument, and forfeits the contemporaneous record that any later analysis — yours or theirs — depends on. The tell: if the motivation is to make the variance report look better rather than to reflect an agreed change in obligations, it's the sin.

The archive — one immutable native file per period, forever

Each period's approved update is frozen as a uniquely named native file (XER/XML — a PDF is a picture, not a schedule), and next month starts from a copy. The period-by-period native archive is the raw material of every retrospective delay method; a missing or overwritten period is an unfillable hole that analysts treat with suspicion. File the narrative, the reports, and the minutes with the same period so the record set stays coherent. This is cheap discipline with enormous option value: the strongest analysis methods years from now are exactly the ones that need every update in native format. [UFGS 3.5.1 · AACE 29R-03]

The milestone trend chart

Every period, plot the current forecast of contract completion and each key interim milestone. A line drifting later at a steady rate is the plainest statement in project controls: the plan is losing time systemically, even while each individual update has a perfectly good explanation. Senior management reads this one chart faster than any table you will ever build.

Float erosion

Compare total float on the critical and near-critical paths to last period, every period. Decreasing float on a near-critical path means it is about to go critical — and a path losing 5 days a month will overtake a static critical path while everyone watches the wrong bars. Watch the population too: a swelling count of activities under ~10 days of float signals a volatile critical path and coming resource strain.

The indices — and how they are gamed

Know how the building goes together

The judgment behind every good network is construction sense: which crew goes where next; whether the tower crane and hoists can actually feed the floors at the pace the bars imply (on high-rise work, vertical transportation is often the true critical resource); that finishes need conditioned air, which needs an AHU started, which needs permanent power, controls, water, and ductwork all converged; that the envelope must close before the weather window does. A sequence review that ignores laydown, hoisting, and seasonality is not a constructability review — it's a topology check.

The consensus of every good planner I know: to plan something, you should know how to build it. Field time first; quantities and estimating second; software third. If your career hasn't allowed enough of the first two yet, borrow relentlessly — which is the next point.

The schedule is built with the people who will execute it

A baseline built alone at a desk fails the constructability review and, worse, fails the field — supervisors treat owner-required CPM as irrelevant unless they helped make it, and a schedule nobody owns fails no matter how technically clean it is. Run the planning session with the PM, procurement, superintendents, and the major subs; get subcontractor sign-off that their portions are achievable (a date imposed on a sub is a wish; a date a sub signed is a commitment); and bridge to the field through the cascade — master schedule → phase pull plan built backward from milestones with the trades in the room → six-week lookahead for constraint removal → weekly commitments → daily plan. The lookahead is filtered from the current update, activity IDs and all; a lookahead that doesn't trace to the master is a parallel universe, and the drift between them is your earliest warning that the field has abandoned the plan.

Read the contract like a scheduler

Before you draw a bar, read the contract for the five clauses that decide money: notice provisions (5–28 day windows; blowing one can waive the claim entirely — you are often the first person positioned to flag a noticeable event); float ownership language (float-sequestration clauses hide deep in scheduling specs); the NTP definition; the definitions of substantial completion / beneficial occupancy (they end liquidated damages — schedule them as milestones exactly as defined); and the schedule spec itself, because an accepted baseline functions as the reference frame for every future negotiation.

Spotting sandbag vs conservatism — and the line you never cross

Reviewing the other side's work, hunt the float-sequestration kit: preferential logic soaking up float, odd durations landing exactly on the contract date, lags that aren't cure, constraints that stop the network flowing, buffers that vanish whenever delay occurs — and in updates: backdated actuals, decreasing percents, activities riding the data date, unexplained calculation-mode switches. The distinction that survives scrutiny: genuine conservatism is visible, explained, and consistent (weather calendars, named margin, resource-limited sequencing); sandbagging is buried, asymmetric, and only ever helps one party.

And on your own side of the table, the line is bright: the schedule must represent the plan you actually intend to execute. Aggressive-but-real sequencing is advocacy; steering the critical path with shaved durations, backdated actuals, or logic that deviates from the real construction approach is falsification — it destroys credibility precisely where schedules matter most, and modern diff analytics surface it anyway. Claims-aware, never claims-driven: keep the record impeccable so any future analysis is easy, but the moment the claim becomes the schedule's purpose, the field ignores it and the tribunal discounts it. You lose both ways.

The habits

• Walk the site on a fixed cadence with the schedule in hand; join the superintendent's end-of-day walk when you can.
• Keep a scheduler's diary — crew counts, areas worked, hindrances. Contemporaneous notes are what notice letters and analyses stand on later.
• Recompute independently before trusting any file, yours or theirs; check calendars before dates; verify settings every cycle.
• Diff every update against the prior period before anyone else can; publish the explanation with the file.
• Know your quantities and production rates by heart — the schedule conversation you win is the one where you know the take-off.
• Never publish a calculation you haven't reviewed. The F9 is not the finish line; it's the starting gun.

The path

Field time → quantities and estimating → CPM mechanics and P6 mastery → delay analysis and contracts → risk and probabilistic methods. Certifications when the experience supports them: PSP (AACE — the construction-career credential, ~4–8 years) and PMI-SP (~2–3.5 years) — certified schedulers earn about 10% more, but the credential follows the competence, not the reverse. Measure your impact in outcomes ("resolved an 8-week delay on the energization path"), never in activity counts.

And the differentiating skill at every stage is communication. The planner is a catalyst on the project team — the one who can express the build plan in plain language to a foreman, a CFO, and a lawyer in the same week. A scheduler who cannot get a superintendent to engage produces schedules nobody follows; a scheduler who can is running the job's nervous system.