What is a Project Baseline?
Project Baseline
A project baseline is the original approved plan, its scope, schedule, and cost, locked in at a point in time so actual progress can be measured against it later.
A project baseline is the original approved version of a project's scope, schedule, and cost, captured at one point in time, usually right after planning ends and work begins. Once set, the baseline doesn't move. Everything that happens afterward, every completed task, every dollar spent, every day that passes, gets measured against that fixed reference point rather than against whatever the plan happens to look like today.
The purpose is comparison, not prediction. A timeline tells you when things are scheduled to happen; a budget tells you how much is approved to spend. A baseline takes a snapshot of both, and the scope they were built for, and holds it still, so that three weeks in, a team can answer a specific question: are we ahead, behind, or on track compared to what was agreed at the start, not compared to a plan that's quietly been redrawn to match reality.
Without a baseline, "on schedule" and "on budget" become moving targets. A project that's two weeks behind its original plan can look fine if the timeline gets informally pushed back each time a delay happens and nobody keeps the original dates on record.
The Three Parts of a Baseline
A complete baseline locks in three things together, not only one. Tracking schedule variance without cost variance, or the reverse, misses half the picture.
- Scope baseline: the approved deliverables and what's explicitly out of scope, the reference point for detecting scope creep
- Schedule baseline: the approved start and end dates for every task and milestone
- Cost baseline: the approved budget, usually broken down by phase or work package
When to Set a Baseline
A baseline gets set once planning is approved and before execution starts, not before, since the plan isn't final yet, and not after work has already begun, since some of what you'd be comparing against would already reflect actual progress rather than the original intent.
For an agency project, the natural trigger point is client sign-off: once the scope, timeline, and budget in the proposal or SOW are signed, that becomes the baseline. For internal projects without a client contract, the equivalent moment is when the project charter or kickoff plan gets final approval from the sponsor.
Measuring Variance Against the Baseline
Variance is the gap between the baseline and where the project stands. Measuring it regularly, not only at the end, is what makes a baseline useful rather than a historical document nobody checks.
| Variance type | Formula | Reads as |
|---|---|---|
| Schedule variance | Baseline finish date vs current forecast finish date | Days ahead or behind the original plan |
| Cost variance | Baseline budget vs actual plus forecast cost | Dollars under or over the original approved amount |
| Scope variance | Baseline deliverable list vs current deliverable list | Items added or dropped since sign-off |
A Worked Example: Baseline vs Actual on a 10-Week Project
A studio baselines a 10-week website project at kickoff: 8 pages, design approved by week 4, launch on week 10, budget of $24,000. Here's how the baseline compares to actuals at the week 5 midpoint.
| Metric | Baseline | Actual at week 5 | Variance |
|---|---|---|---|
| Scope | 8 pages | 9 pages, client added a careers page in week 3 | +1 page, no change order issued |
| Schedule | Design approved week 4 | Design approved week 6 | 2 weeks behind on this milestone |
| Cost | $12,000 spent by week 5 (50% of budget) | $15,200 spent by week 5 | $3,200 over the week-5 baseline figure |
When to Rebaseline (and When Not To)
Rebaselining means replacing the original baseline with a new one that reflects an approved change, rather than continuing to measure against a plan everyone agrees is outdated. It's not something to do casually: rebaselining too often erases the record of how the project drifted, which defeats the reason to keep a baseline in the first place.
- Rebaseline when a formal change order adds or removes significant scope, or a client-approved delay resets the timeline
- Don't rebaseline when the project is running behind and the team wants a baseline it can still hit
- Keep the original baseline archived even after rebaselining, so the full history of how the plan changed stays visible
- Version the baseline (v1, v2) with the date and reason for the change, the same discipline used for updating a project charter
Project Baselines in Melororium
Project History logs every status change, reassignment, and update on a project in one timeline, filterable by action and searchable by person, so the gap between what was planned and what happened stays visible rather than getting overwritten as the project moves. Budget Guardian tracks spend calculated from logged time against the approved budget, with alerts at 80%, 100%, and 120%, giving the cost side of baseline variance without a separate spreadsheet.
Neither feature locks a formal scope or schedule baseline automatically. For agencies, the practical approach is capturing the original scope and dates in the project's Canvas document at kickoff, then checking Project History and Budget Guardian against that record during weekly reviews.
In Melororium
See what changed since project kickoff in Melororium
Common mistakes with project baseline
What teams get wrong most often, and what to do instead.
- 1
Never locking a baseline at all
Letting the plan quietly update every time something slips, so there's no fixed point left to measure against. Every status update looks fine because the bar keeps moving to match it.
- 2
Rebaselining every time the project falls behind
Resetting the baseline whenever the team misses it, instead of only when a real, approved change justifies it. A baseline that moves to match reality stops measuring anything.
- 3
Tracking cost variance but not schedule variance
Watching the budget closely while letting the timeline drift unmeasured, or the reverse. The two are connected; a schedule slip usually shows up as a cost overrun a few weeks later.
- 4
Setting the baseline before the plan is approved
Locking in scope, schedule, and cost before the client or sponsor has signed off. Whatever gets measured against an unapproved plan doesn't hold up when someone disputes the numbers.
Frequently asked questions
Is a baseline the same as the original project plan?
Close, but a plan can keep changing as a working document. A baseline is a frozen snapshot of the plan at one specific moment, usually right after approval, kept unchanged specifically so later versions have something fixed to compare against.
How often should you check variance against the baseline?
Weekly for active projects is a reasonable default, the same cadence most agencies already use for budget-vs-actual reviews. Checking only at the end defeats the purpose, since there's no time left to correct course.
What's an acceptable amount of variance?
There's no universal number, but many teams treat under 10% schedule or cost variance as normal drift and reserve escalation for anything beyond that. What matters more than the exact threshold is having one agreed in advance, so a 15% variance triggers the same response every time instead of a judgment call.
Does every project need a formal baseline?
No. A short project with a fixed 2-week timeline and a single deliverable often doesn't need a documented baseline separate from the plan itself. Baselines earn their keep on longer or more complex projects, where enough time passes for the plan and reality to drift apart unnoticed.
Who's responsible for maintaining the baseline?
Usually the project manager. They lock it at kickoff, check actuals against it during the project, and propose a rebaseline, with sponsor or client approval, if scope or timeline changes enough to warrant one.
