Why Baselines Exist
Every project plan changes after work begins. Tasks take longer than expected. New scope is added. Resources shift. The schedule that looked perfect on day one looks different on day thirty.
This is normal. The problem isn't that the plan changes but that without a fixed reference point, you can't measure how much it changed or where it changed.
That's what a baseline is: a snapshot of your approved plan at a specific point in time. Budget, dates, scope, and dependencies, all frozen. As the project progresses and reality diverges from the plan, you compare current data against the baseline to measure variance.
Without a baseline, you're flying without instruments. The numbers look fine because you have nothing to compare them to.
What Goes Into a Baseline
A complete project baseline captures:
Schedule baseline captures planned start and finish dates for every task and milestone. When Task A was supposed to start March 1 and actually started March 8, that's a 7-day schedule variance.
Cost baseline captures budgeted costs at every level (deliverable, task, milestone, project). When a deliverable was budgeted at $5,000 and actual cost is $6,200, that's a $1,200 cost variance.
Scope baseline captures the work breakdown structure (milestones, tasks, deliverables) as approved. When scope changes add new deliverables, the baseline shows what was originally planned versus what exists now.
All three must be captured together. A schedule baseline without cost data tells you if you're late but not if you're over budget. A cost baseline without schedule data tells you if you're overspending but not if you're behind.
When to Set a Baseline
At project approval. The moment the plan is signed off and work is authorized, take the first baseline. This is your "Baseline 0" - the original plan against which everything is measured.
After major scope changes. If a change order significantly alters the project scope, you may re-baseline to reflect the new approved plan. The old baseline still exists for reference, but variance tracking shifts to the new one.
At key phase gates. Some teams re-baseline at milestone completions - the original baseline stays for overall tracking, but a new baseline captures the approved plan for the next phase based on lessons from the previous one.
Don't re-baseline to hide problems. If you re-baseline every time the schedule slips, you're erasing variance instead of tracking it. Re-baselining should be a deliberate, documented decision, not a way to make red numbers turn green.
How Variance Tracking Works
Once you have a baseline, variance is simple subtraction:
Schedule Variance = Current dates − Baseline dates. If a task's current finish is April 20 and the baseline finish was April 15, that's a +5 day schedule variance (late).
Cost Variance = Actual cost − Baseline cost. If actual cost is $48,000 against a baseline of $45,000, that's a +$3,000 cost variance (over budget).
At the project level, these variances aggregate. Total schedule variance tells you how late the project is running overall. Total cost variance tells you how far over or under budget you are.
Making Variance Actionable
Raw variance numbers are necessary but not sufficient. To act on them, you need context:
Which variances are on the critical path? A 5-day delay on a non-critical task with 15 days of float doesn't affect the project end date. The same delay on a critical task pushes delivery.
Are variances trending or one-time? A task that's 2 days behind because of a one-time equipment failure is different from a task that's drifting 1 day per week due to understaffing. The first is an event; the second is a trend.
Are cost variances driven by price or quantity? If materials cost more per unit than planned, that's a price variance. If you used more material than planned, that's a quantity variance. Different root causes require different responses.
Baseline Comparison in Practice
The most useful view for project managers is a side-by-side comparison: baseline plan on one side, current plan on the other, with variances highlighted.
On a Gantt chart, this appears as the baseline bars behind the current bars. When a current bar extends past its baseline, you can see the slippage visually. When it's shorter, you're ahead.
On a cost report, it appears as budget (baseline) vs actual, with variance columns that flag overruns in red and underruns in green.
The key is that this comparison is always available, always current, and requires no manual effort to produce. If generating a variance report takes an analyst half a day, it won't be done weekly. If it's automatic and always visible, it's part of the daily workflow.
How Milesto Handles Baselines
Milesto lets you save baselines at any point - a snapshot of all dates, costs, and scope. The baseline comparison is always visible on the dashboard, showing variance at the project, milestone, and task level.
Baselines are stored as immutable snapshots in the database. You can save multiple baselines and compare against any of them. The change log tracks exactly what changed between the baseline and the current state, attributed to who made each change and when.
S-curve charts overlay planned value (from the baseline) against earned value (from actual progress), giving you a visual indicator of schedule and cost performance over time.
Key Takeaways
- Set your first baseline at project approval because you can't measure variance without a reference point
- Don't re-baseline to hide slippage and re-baseline only for formally approved scope changes
- Track schedule and cost variance together because one without the other gives an incomplete picture
- Focus on critical path variances because not all delays affect the project end date
- Automate the comparison because if it requires manual effort, it won't happen consistently
Want baselines that track themselves? Start free on Milesto.io. Snapshot your plan, track every variance, and see the drift before it becomes a crisis.