The project schedule is the document that determines whether your project hits substantial completion on time — or slips by weeks while the GC and subs argue about whose delay caused which milestone to miss. CPM scheduling, baseline vs working schedule, weekly look-aheads, delay attribution, and concurrent delay analysis are the workflows that separate projects that ship on time from projects that ship at all. This is a working guide for mid-market subs and GCs on how project scheduling actually has to work.
If you're a project manager on a commercial project and you've ever stared at a Primavera P6 schedule wondering whether the slip you're looking at is your fault, the architect's fault, or the owner's fault, you know the shape of this problem. The schedule is simultaneously the most important and most contested document on every commercial project. This post is the working overview for how to think about it.
What CPM scheduling actually is
The Critical Path Method (CPM) is a scheduling technique that identifies the longest path of dependent activities through a project. Activities on the critical path have zero float (no slack); a delay to any of them delays substantial completion by the same amount. Activities off the critical path have float and can absorb some delay without affecting the project end date.
CPM was developed in the late 1950s for industrial projects and has been the standard scheduling approach for commercial construction for decades. It's typically implemented in software — Primavera P6 (the enterprise standard), Microsoft Project (more common at smaller firms), Asta Powerproject, Phoenix Project Manager, and several others.
The core constructs:
- Activity: a discrete unit of work with a duration, predecessors, and successors. "Pour slab on grade level 1" is an activity.
- Predecessor / successor relationship: activity B can't start until activity A finishes (or some variation: A must finish before B can finish, A must start before B can start, etc.).
- Duration: the time the activity is expected to take.
- Float: the amount of time an activity can slip without delaying the project end date. Activities on the critical path have zero float.
- Milestone: a zero-duration event that marks a significant project point — substantial completion, certificate of occupancy, sub mobilization, owner pay-app cycle.
- Lag / lead: a wait time (lag) or overlap (lead) between two activities. "Slab pour finishes; wait 7 days for cure; framing starts" uses a 7-day lag.
The output: a schedule that shows when each activity starts and finishes, what's on the critical path, and what the project end date is.
Baseline vs working schedule
One of the most important distinctions in commercial construction scheduling is between the baseline schedule and the working schedule.
The baseline schedule is the schedule agreed to at contract award (or shortly after). It's the contractual commitment to the owner about when things will be built and when substantial completion will occur. The baseline is locked at a point in time and doesn't change unless formally reissued (a "baseline update"), typically triggered by a major change-order package or an owner-approved schedule extension.
The working schedule is the current operational schedule that reflects everything that's actually happened (progress to date) plus the current best forecast of what's still to come. The working schedule changes weekly or biweekly as the project proceeds. By month three of a typical commercial project, the working schedule is materially different from the baseline.
The gap between baseline and working schedule is where delay claims live. If the working schedule shows substantial completion 3 weeks after the baseline date, somebody owes somebody else for those 3 weeks. The contract specifies who: contractor delay (the GC absorbs liquidated damages), owner-caused delay (the GC gets a time extension and sometimes compensable delay damages), force majeure (the GC gets a time extension but no compensation), concurrent delay (a contested middle ground covered below).
The weekly look-ahead
The working schedule is too detailed and too long to operate against day-to-day. Field teams operate against the weekly look-ahead — a 3-week or 4-week extract from the working schedule showing what each crew is doing this week, next week, and the week after.
The look-ahead is built from the working schedule but typically:
- Reorganized by crew or by trade rather than by CPM logic
- Augmented with day-of-week specificity (Monday/Tuesday/Wednesday rather than calendar dates)
- Annotated with constraints not in the master schedule (weather forecasts, material delivery dates, inspection bookings)
- Distributed to foremen and sub PMs as the operational planning document for the week ahead
The weekly look-ahead is where most projects actually get built. The CPM schedule is the contractual reference; the look-ahead is the operational tool.
How schedule slippage actually happens
Across commercial projects, schedule slippage traces to a handful of recurring patterns:
1. Owner-caused delays. Owner-directed scope changes that aren't accompanied by time extensions. Owner approval delays on submittals or change orders. Late delivery of owner-supplied equipment. Site access restrictions imposed mid-project. These delays generally entitle the contractor to time extensions and sometimes compensable delay.
2. Design-related delays. Late or incomplete design documents at award. Design changes during construction. Slow RFI responses (covered in our RFI management post) or slow submittal reviews (covered in our submittal management post). Coordination issues between design disciplines that surface during construction.
3. Contractor-caused delays. Sub mobilization later than scheduled. Productivity lower than baseline assumed. Quality issues requiring rework. Equipment breakdowns. Subcontractor financial trouble causing slowdown.
4. Force majeure. Weather (covered by the schedule's weather assumptions; days beyond the assumed allotment may entitle the contractor to extension). Pandemic disruptions. Material shortages from causes outside the contractor's control. Strikes or labor disruptions.
5. Concurrent delay. Two or more delays happening simultaneously, each of which would have delayed the project independently. The legal treatment is complex and contract-dependent: in some jurisdictions, the contractor gets a time extension but no compensable damages; in others, the contractor gets both; in some, neither. The "but-for" analysis (would the project have been delayed but for this specific delay) is what gets litigated.
The contractual mechanism for handling all of these is the time-extension request, supported by a schedule analysis (typically a Time Impact Analysis or TIA) showing how the specific delay affected the critical path. Time-extension requests denied at the GC or owner level are the seeds of most schedule-related litigation in commercial construction.
What the sub side needs to track
For subcontractors, scheduling responsibilities are typically more focused but still substantial:
- Their scope's activities within the GC's master CPM schedule (the sub doesn't usually own the master schedule but owns the segment representing their work)
- Their internal crew scheduling against their scope — which crew does which activity on which day
- Their material delivery schedule, particularly for long-lead items
- Their dependencies on other subs (their work can't start until the prior trade finishes; the next trade can't start until they finish)
- Their schedule of values cycle (covered in our AIA G702/G703 guide) which generally tracks the work's completion against schedule
When a sub's segment is on the critical path and the sub is slipping, it's the GC's problem (because the project ends late) and the sub's problem (because they may owe back-charges for delay). When the slip is caused by upstream issues (late design, RFI lag, prior-trade delay), the sub needs documentation to support their time-extension request.
The recurring scheduling failure modes
1. Baseline never properly developed. The contract is awarded with a tentative schedule that nobody really vetted. Within weeks, the working schedule has diverged. There's no real baseline to attribute slip against.
2. Working schedule updated weekly but nobody reads it. The scheduler updates the working schedule diligently. The GC PM, the sub PMs, and the owner's CM all look at the look-ahead. Nobody actually reviews the working schedule changes against baseline. By month four, the schedule reflects reality but nobody knows what changed.
3. Delay events not documented in real time. The owner is slow on an RFI. The architect re-issues a drawing set with substantive changes. A change-order package adds 60 days of work without a time extension. None of these get formally documented as delay events at the time. At closeout, when the GC tries to claim 90 days of cumulative time extensions, there's no contemporaneous record to support the claim.
4. Critical path analysis stale. The schedule was set up correctly at award; the critical path was identified. Six months in, the critical path has shifted (often multiple times) because of completed work and emerging delays. The team is still managing against the original critical path.
5. Sub schedule integration weak. Subs provide their own schedules for their scope, but the GC's master schedule doesn't actually integrate them — or integrates them once at award and not as they update. Sub-side slips don't propagate into the master schedule.
6. Time-impact analysis treated as a closeout exercise. TIAs are produced at closeout to support the GC's delay-claim package against the owner. By then, the events are 6-12 months stale, the documentation is incomplete, and the analysis is contested. TIAs done in real time as delays occur are far more defensible.
7. The look-ahead disconnected from the master schedule. Foremen build the weekly look-ahead from what they think is happening, not from what the master schedule says should happen. Reality and contractual schedule drift apart without anyone noticing.
What good scheduling workflow looks like
The principles:
Baseline locked properly at award. The baseline schedule reflects realistic durations, valid logic, sub-supplied data, and is signed off by all major subs as feasible. Owner-approved schedule = baseline schedule.
Working schedule updated on a published cadence. Weekly or biweekly, with documented changes from prior update. Stakeholders review actual changes, not just the latest snapshot.
Delay events documented in real time. Every event that potentially impacts the schedule — owner directive, RFI lag, change-order package, weather day exceeding assumption, material delay — gets a real-time event record. The record carries the supporting documentation and the analysis of impact.
Critical path refreshed every update. Each working-schedule update identifies the current critical path. Stakeholders know what's actually driving the project end date this week, not what was driving it three months ago.
Sub schedules integrated as live data. Subs' own schedules feed into the master schedule via integration, not by re-typing at update time. Sub-side slips propagate immediately.
Time-impact analyses produced as events happen. Major delay events trigger a TIA within days, not at closeout. The TIA documents the impact, attaches the supporting record, and supports any time-extension request.
Look-ahead derived from the master schedule. The weekly look-ahead is a generated view of the master, not a hand-built parallel document. What the field is working from matches what the contract is being measured against.
How AOS handles project scheduling cross-tenant
AOS doesn't replace Primavera P6 or Microsoft Project for full CPM scheduling — the dedicated scheduling tools are mature and most commercial GCs have them. AOS provides the integration layer that makes scheduling actually work operationally, cross-tenant:
- Master schedule import. The GC's P6 / MS Project schedule imports into AOS, with critical path identified and activities mapped to project records.
- Sub-segment surfacing. Each sub on the project sees their segment of the master schedule in their own dashboard, with their activities and dependencies on other subs visible.
- Weekly look-ahead generated from master. The 3-week look-ahead is a derived view, not a separate document. Foremen and sub PMs work against the same data the master schedule reflects.
- Progress updates from the field flow into the schedule. Daily-log entries, percent-complete updates, and milestone completions automatically update the working schedule. The scheduler updates the master based on actual progress, not by interviewing the PM.
- Delay event log. Every potential schedule-impact event — owner directive, RFI lag, change order, weather day, material delay — gets a structured event record at the moment it occurs. Supporting documentation attaches at logging.
- Time-impact analysis triggered on event log. Major delay events trigger a TIA workflow; the analysis incorporates the master schedule, the delay event, and the supporting record; output is a defensible time-extension request package.
- Cross-tenant when subs and architects are on AOS. Sub schedule updates flow into the master cross-tenant. Architect delays on submittal reviews surface in the schedule integration. The delay-attribution conversation has live data on both sides.
The project management product page covers the broader workflow. For related operational guides, see change orders (the most common schedule-impact event), RFI management (the second most common), and both sides on one record (what changes when sub and GC schedules integrate cross-tenant).
The scheduling readiness checklist
- Is your project baseline schedule properly developed and signed off by all major subs, or was it a placeholder that diverged within weeks?
- Is your working schedule updated on a published cadence with documented changes, or just snapshotted with no change history?
- Are delay events documented in real time, or only at closeout when the delay-claim package is assembled?
- Does each weekly update refresh the critical path, or are you still managing against the original critical path from month one?
- Are sub schedules integrated into the master, or do they exist as parallel documents that nobody reconciles?
- Are time-impact analyses produced as delay events occur, or only at closeout?
- Is the weekly look-ahead derived from the master schedule, or hand-built by the field team?
If most answers are "informally, with workarounds," that's the gap a connected platform closes — on top of your CPM tool, not replacing it.
One important caveat
Construction scheduling, like prevailing-wage compliance and lien-waiver law, is a domain where the cost of being wrong is high and the analysis is detailed. This post is informational; it's not a substitute for a qualified scheduler or a construction attorney on contested delay claims. If your firm does projects above $10M, hiring or contracting with an experienced construction scheduler usually pays for itself within the first delay claim it helps you defend or pursue.
If you'd like to see it
We're in private-beta design-partner mode for commercial subs and GCs. If you want to walk through how AOS integrates with your scheduling workflow on a real project — particularly one with active delay events or contested time extensions — apply to the beta. The GC overview and subcontractor overview walk through the broader platform.