Schedules that stay on the project record.
Working calendars, versioned schedules, network logic, and approved baselines — wired to the same packages you execute and cost-control against. Not a sidecar Gantt file.
Primary schedule
v12
Baseline
Approved
Slip
+4d net
A chart is not a system of record.
Standalone planners optimize for pretty timelines. Delivery orgs need versioned schedules, real calendars, and baselines that survive contact with progress and cost.
Plan as a sidecar file
The Gantt lives in one tool. Packages, cost, and documents live elsewhere. By week three nobody knows which date is authoritative.
Baselines that forget
Teams redraw the chart instead of freezing a promise. Variance becomes storytelling. Sponsors lose the original commitment.
Calendar fiction
Working days, holidays, and shifts never enter the schedule engine — so every “critical path” is optimistic by construction.
Working time is part of the plan.
Schedules that ignore calendars lie. Projects planning keeps working calendars as versioned records — the same ones schedule calculation reads.
- Primary working calendar per project
- Versioned calendar drafts → publish
- Holiday and non-working exceptions
- Schedule calculations respect the calendar
Version. Calculate. Publish.
Primary schedules with draft → publish versions, activity networks, dependency links, and calculation runs you can accept — not silent rewrites of the live plan.
Draft version
Planner
CompleteDependencies set
Network logic
CompleteCalculate
Schedule engine
CompletePublish
Pending approval
Active
A promise you can still measure.
Baselines submit, approve, reject, and revoke as records. Variance is a query — not a meeting where someone redraws the chart.
- 1
Submit baseline
Freeze the schedule promise — submit for governance, not a silent overwrite.
- 2
Approve or reject
Sponsors and controllers approve. Rejected baselines stay in history with reasons.
- 3
Compare forever
Live plan vs baseline variance stays readable as progress and cost move.
Activities live on the same record.
Outline, reparent, reorder, and retire activities against a schedule version. The cockpit is not a separate planning product — it is the project’s work structure.
| WBS | Activity | Type | Start | Finish | % |
|---|---|---|---|---|---|
| 1.2.1 | Foundation pour | Task | Apr 6 | Apr 18 | 70% |
| 1.2.2 | Structural steel | Task | Apr 20 | May 12 | 35% |
| 1.3 | MEP coordination | Summary | May 1 | Jun 10 | 22% |
| 1.3.1 | Duct routing review | Milestone | May 14 | — | 0% |
Releases and iterations on the plan.
Beyond the network: structure how work is released and iterated without forking into another tool’s language.
Releases
Package delivery into releases that sponsors recognize — linked to the schedule, not a slide title.
Iterations
Time-box planning cycles when delivery needs short loops without abandoning the master schedule.
Delivery control
Baselines, releases, and iterations sit together so governance is not a separate spreadsheet.
Plan on the same records you deliver against
Working calendars, versioned schedules, baselines, and the activity cockpit — part of Projects, not a sidecar planner.