You've built the plan. You've mapped out every task, estimated durations, assigned the team, and set a finish date. Everyone's aligned. It looks great.
Then reality hits.
A vendor is late. Someone gets sick. Scope quietly expands. Before long, your carefully crafted schedule starts drifting — and without a record of where you started, it's nearly impossible to tell how far you've gone off track, or why.
That's exactly what a project baseline is for.
What Is a Project Baseline?
A project baseline is a snapshot of your original plan — the approved, agreed-upon version of your schedule, scope, and budget taken at the moment work begins. It's a fixed reference point. Once set, it doesn't change (unless there's a formal change request that updates it).
There are three main types of baselines in project management:
- Schedule baseline — your original planned start and end dates for tasks and the overall project
- Cost baseline — your original budget, including expected spending over time
- Scope baseline — the approved deliverables and requirements (often captured in a WBS)
Together, they form your performance measurement baseline — the standard you'll use to evaluate how the project is actually going versus how you said it would go.
Why Baselines Matter: The "Compared to What?" Problem
Without a baseline, all your status updates are floating. A task that's "running a little late" — but late compared to what? The original plan? Last week's revised plan? What you told the client three weeks ago?
This ambiguity is one of the most common sources of confusion and conflict in project teams. People have different mental models of what "on track" means, and without a shared reference, debates about status become unproductive.
A baseline solves this by giving everyone the same answer to "compared to what?"
With a saved baseline, you can see at a glance: which tasks started or finished later than originally planned, how much the overall schedule has slipped, whether the current forecast finish date has moved relative to the original, and which parts of the project are ahead of plan.
A Practical Example
Let's say you're managing a product launch. Your baseline says the design phase finishes on June 5th, development starts June 6th, and the product ships July 15th.
It's now June 10th. Design just wrapped up — five days late. Development is starting today instead of June 6th.
Without a baseline, your Gantt chart just shows "Development: starts June 10th" — which looks fine in isolation. With a baseline, you can see the red: design was planned for June 5th, it finished June 10th, the deviation is 5 days, and if nothing changes, the launch slips to July 20th.
Now you can act on that. Maybe you add a resource to development to claw back two of those days. Maybe you flag it to stakeholders now, before it's a bigger surprise later. Either way, you're managing with information rather than guessing.
When to Set a Baseline
The right time to set a baseline is after the project plan has been approved and before any actual work begins. If you set it too early (while the plan is still being negotiated), you'll capture a plan that wasn't really final. If you set it after work starts, you'll miss the chance to record the true starting point.
In practice, baseline-setting is often part of the formal project kickoff process. Once the sponsor or stakeholders sign off on the schedule, you lock it in.
Some teams also set interim baselines at major milestones — for example, re-baselining at the start of Phase 2 if Phase 1 ended significantly differently than planned. This is acceptable, but it should be a deliberate decision, not a way to cover up accumulated delays. Every time you re-baseline, you're essentially resetting what "on track" means, which can mask real performance problems.
Schedule Variance and Performance
Once you have a baseline, two metrics become particularly useful for tracking progress.
Schedule Variance (SV) tells you how far ahead or behind schedule you are in terms of work completed. A negative SV means you're behind — less work has been done than the baseline planned at this point in time.
Schedule Performance Index (SPI) tells you your efficiency ratio — how much planned work you're completing per unit of time. An SPI below 1.0 means you're completing less work than planned per day; an SPI above 1.0 means you're running ahead.
These metrics come from Earned Value Management (EVM). But you don't need to go full EVM to benefit from baselines. Even a simple Gantt comparison — original bars shown in grey alongside current bars in colour — gives you powerful visual feedback on project health.
Baselines and Stakeholder Communication
Baselines aren't just an internal project management tool. They're also a communication asset.
When a client asks "why is this taking longer than expected?", you can pull up the baseline and walk through what changed: the discovery phase uncovered three additional integrations that weren't in scope, which added 10 days to the development timeline. Here's where we were, here's where we are, here's the delta.
That kind of clear, documented explanation builds trust — far more than a vague "things came up." It also protects you. If scope was added and the timeline was adjusted with sign-off, the baseline captures that decision point.
For recurring stakeholder reports, showing baseline vs. actual on a Gantt chart is one of the clearest ways to communicate project status without lengthy written explanations.
Common Mistakes Teams Make with Baselines
Not setting one at all. Surprisingly common, especially on smaller projects where teams think they'll "just remember" the original plan. They don't.
Re-baselining too frequently. If you re-baseline every time the schedule slips, you lose the ability to track cumulative drift. The baseline becomes meaningless because it always matches the current plan.
Treating the baseline as the target rather than the reference. The baseline records your original plan. Circumstances change — that's normal. The goal isn't to always match the baseline; it's to understand and document the reasons when you don't.
Setting the baseline before the plan is stable. Lock it in when the plan is actually agreed upon, not while it's still being negotiated.
How LoopGantt Handles Baselines
In LoopGantt, you can save a baseline at any point once your project schedule is set. The baseline gets stored alongside your live schedule, and you can toggle a visual overlay that shows your original planned bars in a muted colour behind your current task bars.
This makes it immediately obvious which tasks are running ahead or behind plan, and by how much. When you're in a stakeholder review or a team standup, that visual comparison often tells the story faster than any written report.
LoopGantt is available at $5.99/month per user (or $49.99/year per user), which includes baseline tracking, Gantt scheduling, dependencies, milestones, and the portfolio dashboard.
The Bottom Line
A project baseline is your project's original plan, preserved in amber. It's not a constraint or a rigid target — it's a reference point that makes everything else measurable.
Without one, "on track" is just an opinion. With one, it's a fact you can point to, explain, and act on.
If your team has been managing projects without baselines, the fix is simple: next time you kick off a project, take one minute to save the baseline before the first task starts. That one minute will save you hours of confusion and debate down the road.