✨ Registered readers browse ad-free. Always free. Create your free account →
Schedule Baseline Example — Website Launch Project
Version
Download 22
File Size 59.04 KB
File Count 1
Create Date March 14, 2026
Last Updated March 15, 2026
Download
or download free
[free_download_btn]

Description

Get Your Free Filled-In Example

Enter your name and email below to download the Project Phoenix example instantly. No payment required.

What Is a Schedule Baseline?

A Schedule Baseline is the approved version of the project schedule — a snapshot of the planned schedule at a specific point in time, used as the reference point for measuring schedule performance throughout the project. In PMBOK 8, the Schedule Baseline is formally approved by the project sponsor and can only be changed through formal change control. It is distinct from the working schedule (which is updated continuously) because it preserves the original plan, enabling the team to calculate Schedule Variance (SV) and Schedule Performance Index (SPI) by comparing actual progress to the baseline. Without a frozen baseline, there is no objective measure of schedule performance — only the illusion of current-state planning masquerading as schedule control.

What's Inside This Schedule Baseline Example

This Schedule Baseline example covers Project Phoenix — MCG's $72,250 website launch, March 17 to June 13, 2025. The spreadsheet contains the frozen baseline approved by Riley Park on March 14:

  • Baseline Gantt tab: Locked Gantt chart showing all 87 activities with baseline start and finish dates, as approved at project initiation
  • Milestone Baseline tab: 12 key milestone dates frozen — Project Kickoff March 17, Design Approved April 11, Development Complete May 23, UAT Sign-Off June 9, Launch June 13
  • Baseline vs. Actual tab: Side-by-side comparison of baseline dates vs. actual dates, updated weekly during execution
  • SPI Trend tab: Weekly Schedule Performance Index chart showing baseline (1.0) vs. actual SPI from March through June
  • Baseline Change Log: One entry — CR-001 (blog module addition) prompted a Baseline Amendment on April 7, creating Baseline v1.1. The blog module added 12 days of development work that was inserted without extending the overall project end date by absorbing a schedule buffer.

How Alex Morgan Used This Schedule Baseline

Alex Morgan loaded the Schedule Baseline into the project scheduling tool on March 14 and locked it from editing. Every subsequent schedule update was made to the working schedule only — the baseline remained frozen for comparison. This discipline produced meaningful SPI metrics from Week 1 rather than a perpetually "on schedule" illusion created by baseline re-setting.

Schedule performance against the baseline told a clear story:

  • Weeks 1–4: SPI 1.00–1.02. The project tracked exactly to baseline through the design phase.
  • Week 5–6: SPI dipped to 0.97 as the content migration scope issue (CR-002) caused planning delays. Alex's CR-002 scope reduction in Week 6 restored SPI to 1.01 by Week 7.
  • Weeks 7–12: SPI 1.01–1.05. The project ran consistently ahead of baseline through the second half.
  • Final: Launch occurred June 11, two days before the June 13 baseline date. Final SPI: 1.02.

Download and Customize

This Schedule Baseline example is available as a free download. Use it as a reference to build your own schedule baseline, or start with the blank template and apply it after your schedule is approved.

Schedule Baseline Example: Key Takeaways

The most important discipline demonstrated in Project Phoenix's Schedule Baseline management was the refusal to re-baseline when the Week 5–6 SPI dipped. The team solved the performance problem (via CR-002 scope reduction) rather than adjusting the baseline to make the metrics look good. That discipline meant the final SPI of 1.02 was an honest measure of performance against the original plan — not a number engineered by moving the goalposts. The Schedule Baseline has no value if it is re-set every time performance degrades. Its value is precisely that it does not move — which is what makes an SPI greater than 1.0 at project close genuinely meaningful.

Want to go deeper? The PMBOK Guide 8th Edition is the definitive reference for modern project management. Get your copy and use it alongside these examples to build a solid, practical understanding of every performance domain.

[changelog]

Categories & Tags

Similar Downloads

No related download found!
Eduardo Montes

Leave a Reply