3.3Baseline Planning
The essentials in 30 seconds
- The baseline is a snapshot of the planned project: dates, durations, work and costs frozen.
- It is set at the right time — schedule validated, before the start — via Project > Set Baseline, and is not overwritten lightly.
- Without a reference, no measurable variance: you do not know whether you are ahead or behind; several baselines can be kept (up to 11).
Running mini-case — Meriem freezes the validated schedule
Meriem, a BTP project manager in Algiers, has just finalised and validated the schedule of a new site: tasks, links, resources and costs are ready. Before the start, she saves a baseline via Project > Set Baseline. From now on, the planned values are frozen in 'baseline' fields, distinct from the current values that will evolve with actuals. Meriem knows that without this snapshot, she could neither measure a delay nor detect an overrun. She notes the reflex: set the baseline on a validated schedule, and do not overwrite it at every adjustment.
Standalone case for this section: it comes back in the lesson, the diagram, the script and the 48h challenge of section 3.3.
1. The snapshot of the planned
Once the schedule is finalised and validated, you save a baseline: a snapshot of the project 'as planned' — dates, durations, work and costs. It is the pivotal step that moves from planning to tracking. Without it, Meriem has nothing to compare actuals against.
2. Saving it at the right time
You save it via Project > Set Baseline. Project freezes the planned values in 'baseline' fields, separate from the current values that will evolve. You can keep several baselines (up to 11) to trace major revisions. Meriem sets it at the right time: schedule validated, before the start.
3. Planned vs actual
The baseline is the contract that you will follow. The current/actual evolves with each update; the baseline remains immutable. Tracking compares the two and produces the variances (delay, overrun). Not setting a baseline or overwriting it amounts to losing the memory of the planned.
🔎 Concrete example — 🔎 Concrete example — Planned vs actual
Meriem watches two sets of values coexist after the baseline:
Baseline : the planned frozen on launch day (immutable).
Current/actual: what happens, evolves with each update.
-> tracking compares the two and produces variances (delay, overrun).Reading: the baseline does not move; it is the actual that evolves.
Lesson: without a frozen reference, no variance is measurable.
Section vocabulary
- Baseline
- Snapshot of the planned project (dates, durations, work, costs) serving as the comparison basis for tracking.
Simple example: Meriem saves it on the validated schedule of a site.
What it is not: an improvised schedule with no baseline value.
Reflex: compare actuals → a baseline.
- Baseline fields
- Values frozen at the baseline (Baseline Start/Finish/Work/Cost), distinct from current values.
Simple example: The baseline finish date stays intact while the actual finish slips.
What it is not: the current value that changes at each update.
Reflex: frozen planned value → baseline field.
- Current value
- Current value of a field, which evolves with actuals.
Simple example: The current finish date lengthens after a contingency.
What it is not: the baseline value frozen at launch.
Reflex: what lives → current value.
- Variance
- Difference between the current/actual value and the baseline (delay, cost overrun…).
Simple example: Meriem observes a 5-day delay against the baseline.
What it is not: a comparison impossible for lack of a reference.
Reflex: measure the drift → the variance.
- Multiple baselines
- Ability to save several baselines (up to 11) to trace successive revisions.
Simple example: Meriem adds a baseline after a major amendment.
What it is not: overwriting the single baseline at every adjustment.
Reflex: trace a revision → a new baseline.
In practice — In practice — Saving a baseline
- Finalise and validate your schedule (tasks, links, resources, costs) — the baseline freezes this state, as Meriem does.
- Save the baseline: Project > Set Baseline (for the whole project).
- Display a tracking table or Gantt showing the baseline bars under the current bars.
- Note that you can keep several baselines to trace major revisions.
Step-by-step script — setting the baseline like Meriem (3 min)
1) Check that the schedule is finalised and validated. 2) Choose Project > Set Baseline. 3) Save it for the whole project, before the start. 4) Display a tracking table or Gantt showing the baseline under the current. 5) In the event of a major re-planning, save a new baseline without overwriting the old one.
Keep this marker: the baseline is the frozen 'planned' — you do not overwrite it at every small adjustment.
Copy-paste template — my baseline sheet
Baseline : snapshot of the planned (dates, durations, work, costs)
Baseline flds: frozen, distinct from current values
When : schedule finalised and validated, BEFORE the start
Variance : current/actual - baseline (delay, overrun)
Rule : do not overwrite the baseline at every adjustmentA validated schedule
Meriem saves a baseline just before the start: the planned is frozen.
A small adjustment
Meriem does not overwrite the baseline: she lets the variance be measured normally.
A major amendment
Meriem saves a new baseline while keeping the old one to trace the revision.
Tracking with no reference
Without a baseline, Meriem can neither measure a delay nor detect an overrun: she sets one.
✓ Best practices
- Set the baseline on a validated schedule, before the start.
- Keep the reference: the planned must not move.
- Save a new baseline (without overwriting) in the event of a major re-planning.
✗ Common pitfalls
- Not setting a baseline (no measurable variance).
- Defining it too early (unreliable planned) or too late.
- Overwriting the baseline at every small adjustment.
Key takeaways
- The baseline is a snapshot of the planned project (dates, durations, work, costs).
- It freezes 'baseline' fields distinct from current values.
- It is set at the right time and is not overwritten lightly.
- Without a reference, no variance tracking is possible.
48h challenge — apply it tomorrow
Like Meriem, take a validated schedule and save a baseline for it (Project > Set Baseline). Then display a table or a tracking Gantt showing the baseline under the current. Write in one sentence why you will not overwrite this baseline at every adjustment, and what it will let you measure.
- I can explain what a baseline is.
- I know when and how to save it.
- I understand that it makes it possible to measure variances (delay, overrun).
Frequently asked questions
When should the baseline be saved?
At the moment the schedule is finalised and validated, just before the start. Too early, you freeze an unreliable planned; too late, you lose the first weeks of tracking. Once set, you keep it: in the event of a major re-planning, you add a new baseline without overwriting the old one.
What is the difference between the baseline and the actual schedule?
The baseline is the frozen planned (what you committed to do, frozen at launch). The actual, or current, evolves with each update. Project keeps both in parallel, and tracking compares the two to produce the variances that steer the project.
What is the baseline used for?