This guide covers everything you need to know about the schedule baseline in PMBOK 8. The schedule baseline is the approved version of the project schedule — the fixed reference point against which all actual schedule performance is measured. Without it, schedule control is impossible because there is nothing to compare actuals against.
What Is the Schedule Baseline?
The schedule baseline is the formally approved version of the project schedule, including the start and finish dates for all activities, the critical path, and the project’s planned start and end dates. Once approved by the project sponsor, the schedule baseline is frozen — it can only be changed through the formal change control process.
The schedule baseline is different from the current working schedule. The working schedule is updated regularly with actuals and revised forecasts; the baseline remains fixed as the performance reference. Schedule variances (SV) and schedule performance index (SPI) measure the difference between what was planned (planned value from the baseline) and what was accomplished (earned value from actual work).
A project without a schedule baseline cannot do earned value management, cannot objectively report schedule performance, and cannot make informed decisions about schedule recovery. The baseline is the anchor that gives schedule control its meaning.
Schedule Baseline in PMBOK 8 — Domain and Process
In the PMBOK Guide 8th Edition, the schedule baseline belongs to the Schedule Performance Domain and is produced during the Develop Schedule process. The schedule baseline is the output of an approved project schedule and, once set, becomes the official reference for all schedule performance reporting and control activities.
The schedule baseline feeds into earned value management calculations (planned value is derived from the baseline), work performance reports, and any change requests that propose modifications to the schedule.
Key Elements of the Schedule Baseline
A well-structured schedule baseline typically includes:
- Activity List with Planned Dates — all project activities with their approved start and finish dates
- Critical Path — the sequence of activities determining the minimum project duration
- Project Start and Finish Dates — the approved project-level duration boundaries
- Milestone Dates — approved dates for all key project milestones
- Baseline Approval Record — documentation of sponsor approval with date and signature
- Baseline Version History — record of any subsequent approved baseline changes
Schedule Baseline Example — Project Phoenix
The Project Phoenix schedule baseline was approved by Riley Park on January 20, 2024, establishing a project timeline from January 8 to May 10, 2024 — 20 working weeks. The baseline included 67 activities across six WBS packages, with five major milestone dates: Design Complete (March 8), Development Complete (April 5), UAT Complete (April 17), Go-Live (May 2), and Project Close (May 10).
The schedule baseline was revised once, in connection with CR-001: the approved addition of the mobile-responsive product page redesign added one week to the Design package milestone, shifting Design Complete from March 8 to March 15, and cascading a one-week shift to all downstream milestones. The revised baseline was re-approved by Riley Park on February 28, 2024. At project close, the actual project finish date of May 10 matched the revised baseline exactly — a schedule variance of zero days.
You can download the complete filled-in example below — it shows exactly how the schedule baseline was documented and managed in a real project.
Download Free Schedule Baseline Template and Example
We have prepared two free resources to help you establish a schedule baseline for your own projects:
- Download the Schedule Baseline Template — PMBOK 8 (blank, ready to fill in)
- Download the Schedule Baseline Example — Project Phoenix (filled in for a real $72K website launch)
Both are free downloads — no registration required.
Schedule Baseline — Best Practices and Common Mistakes
Never update the schedule baseline informally to hide variances — this destroys the baseline’s value as a performance reference and is a serious governance failure. When a baseline change is genuinely needed (due to an approved scope change), update it formally through change control with documented rationale and sponsor approval. Save the original baseline as a permanent record even after revisions — project post-mortems often need to compare performance against the original plan.
The schedule baseline is most effective when it is realistically achievable when set (not padded or optimistic) and when baseline changes are managed rigorously through change control. Teams that skip or rush the baselining process often spend the project fighting over whether the schedule is valid.
Want to master project management with PMBOK 8? The PMBOK Guide 8th Edition is the definitive reference. Get your copy and use it alongside these free resources.
Project Management