Sharing Schedules with Owners and Subcontractors

A schedule nobody sees is just a file. A schedule everyone sees in a different version is worse. Sharing well means giving each audience the slice they need, in a format they'll actually open, with the data date on it, from a single source. This post covers who needs what, which formats work, how often to send, and the version-control habits that keep the owner, the architect, and twenty subcontractors arguing about the work instead of about which PDF is current.

Different people need different views

The full schedule, every activity sorted by WBS, is the scheduler's working view. Almost nobody else wants it. Sending the full 1,400-activity Gantt to a drywall foreman is the same as not sending anything.

Audience	What they need	Typical format	How often
Owner executive	Milestones, forecast completion, trend since last month	One-page milestone summary	Monthly
Owner's rep or PM	Full update, critical path, narrative, variance	Native file plus PDF layouts	Monthly, plus on request
Architect and engineers	Submittal and RFI needs, design-dependent activities, inspections	Filtered submittal and procurement layout	Monthly, or with the submittal log
Subcontractor PM	Their activities and the activities immediately before and after them	Filtered layout by responsible party	Monthly, plus when sequence changes
Foremen and field leads	The next few weeks of work in their area	Three-week lookahead	Weekly
Inspectors and utilities	Dates they're needed on site	Short list or calendar entries	As needed

The common thread: filter, don't dump. Activity codes for area, trade, and responsible party are what make filtering possible. If they aren't in the schedule, that's the first fix. See Activity Codes, Filters, and Layouts That People Use.

Owners

The summary they'll read

Owner executives want three things: when will it be done, is that better or worse than last month, and what's driving it. A one-page summary does this better than any Gantt.

Contract milestones with baseline date, last month's forecast, this month's forecast, and variance.
The critical path in one or two sentences.
Top risks to the forecast, with who owns each.
Decisions the owner needs to make, with dates.

That last item is the most useful thing a contractor can put in front of an owner. "We need the finish selections for the lobby by March 6 to hold the TCO date" gets action. A Gantt bar labeled "Owner selections" does not.

The file the owner's rep needs

The owner's rep, or the owner's scheduling consultant, needs the native file every month, along with the narrative and the layouts the spec requires. They'll run their own checks, compare it to last month, and look for logic changes. Give it to them without making them ask. A contractor who sends native files promptly every month is generally reviewed more reasonably than one who sends PDFs and makes the owner chase the file.

Read-only access

A read-only link to the live or current-update schedule saves a lot of email. The owner can look at the critical path or filter to an area without asking for a new PDF. In schedule.construction, owner share links are read-only and include a print-to-PDF option, so the owner gets a live view and can still produce the document their board wants. Whatever tool you use, be clear about whether the link shows the accepted update or the working schedule. Those differ, and the difference matters when someone screenshots it in a meeting.

Subcontractors

Get their input before you publish

Subs who helped set their durations and sequence will defend the schedule. Subs handed a schedule they've never seen will ignore it, and they'll have a point. Before the baseline, walk each major sub through their activities and the work around them. A pull planning session for each phase does this well.

Show them their neighbors

A sub's filtered view should include their own activities plus the predecessors that release their work and the successors waiting on them. A mechanical sub that only sees its own bars doesn't know the drywall hanger is waiting on its above-ceiling rough-in inspection. Showing the handoffs is what makes a filtered schedule useful instead of just short.

Weekly lookaheads

For the field, the monthly update is too coarse and too far out. A three-week lookahead, pulled from the CPM schedule and refined with the foremen each week, is the working document. See How to Build a Three-Week Lookahead from the CPM Schedule. Print it big for the trailer wall; field people still read paper.

Let them update their own work

The best progress data comes from the people doing the work. If subs can report actual starts, finishes, and remaining durations on their own activities, the update is faster and more accurate than the PM's best recollection on the Tuesday before the pay app. schedule.construction lets subcontractors update their own activities. Whatever the tool, the scheduler should still review sub-reported status before the update is final: subs should report status, not change logic.

Version control

Most schedule confusion is version confusion. A few rules prevent most of it.

One source. The schedule lives in one place. Exports are snapshots of it, never edited separately.
Data date on everything. Every PDF, every layout, every lookahead shows its data date in the header. If it doesn't have a data date, it's not a schedule, it's a picture. See The Data Date, Explained.
Name files predictably. Project, update number, data date. For example: Riverside-MOB_Update-07_DD-2026-09-30.xer. Not schedule final v3 REVISED.pdf.
Mark the status. Draft, submitted, or accepted. A draft update that circulates as if it were accepted causes real damage.
Keep every version. Store each update's native file. You'll need them for variance reports, and possibly for a delay analysis later.

Contractors sometimes keep two schedules: one for the owner and one with the "real" dates. This is a bad habit. It splits the team's attention, it tends to come out in discovery if there's ever a dispute, and the owner's version stops being trusted as soon as it diverges from what's happening on site.

It's reasonable to keep internal working files, such as a scenario you're testing or a recovery option not yet proposed, separate from the shared schedule until they're ready. Use a copy or a what-if scenario rather than editing the live schedule, and share it when it becomes the plan. The line is between drafts and a second set of books.

If your contract allows visible schedule contingency, show it as contingency. Contingency hidden in durations is easier to find than people think.

Use the shared schedule in meetings

Sharing is only half of it. The schedule should be on the screen in the weekly coordination meeting and the monthly OAC meeting, filtered to what's being discussed, so decisions get made against the dates. See Running Weekly Meetings Off the Schedule.

Checklist

Each audience gets a filtered view sized to what they act on.
Owner executives get a one-page milestone summary with decisions needed.
The owner's rep gets the native file, narrative, and layouts every month without asking.
Subs see their activities plus the handoffs before and after.
Foremen get a weekly three-week lookahead.
Every document shows its data date and status.
One source schedule, predictable file names, every version kept.
No second set of books; drafts stay drafts until they're the plan.