What a Baseline Actually Is (and What It Isn't)
A schedule baseline is a snapshot of the plan everyone agreed to before the first shovel hit dirt. It's the frozen "this is what we said we'd do" that every later version of the schedule gets measured against. Without one, "we're behind" is just a feeling. With one, "we're behind" becomes "we're eleven days late finishing the podium deck, and here's the day it slipped and why."
That distinction matters more than it sounds. On a job with no baseline, every schedule conversation turns into an argument about memory. The framer swears he was always going to start the third floor in week nine. The GC remembers week seven. Nobody can prove it, so the loudest voice wins. A baseline ends that argument because the answer is written down and signed.
Here's what a baseline is not: it is not the schedule you work off of every day. That's a common rookie mistake. The baseline is the fixed reference. The current or working schedule is the living document that reflects reality as it changes. You compare the two. If you're editing your baseline every time a delivery slips, you don't have a baseline — you have a moving target that will always tell you you're perfectly on schedule right up until the day you hand over a building three months late.
Build the Baseline Before You Freeze It
A baseline is only as honest as the plan behind it, and a shocking number of baselines are garbage the day they're approved. They get built to satisfy a contract requirement, padded to protect the GC, or copied from the last job with the names swapped out. Then everyone's genuinely confused when actuals don't track.
Before you lock anything, pressure-test the plan against a few hard questions:
- Are the durations real, or are they wishes? If your steel erection duration assumes a perfect crane pick every day with no weather, it's fiction. Pull actual production rates from a comparable job if you have them.
- Do the logic ties reflect how trades actually flow? A baseline that shows drywall starting the day rough-in inspection passes, with zero gap, has never met an inspector. Real sequences have buffers baked in.
- Who touched it? A baseline built by a scheduler in an office who has never walked the site is worth less than one the supers and key subs argued over for two hours in a trailer. Buy-in comes from involvement.
- Is the critical path defensible? Trace it end to end. If the software's calculated critical path runs through activities nobody thinks are actually driving the job, your logic is wrong somewhere and the whole baseline inherits that error.
Put realistic buffer where the job needs it. Frame-to-rough-in usually wants a day or two for cleanup and the inspection to clear. Concrete needs cure time before you load it, and no amount of schedule pressure changes chemistry. Underground work in a wet region needs weather float. Build those in on purpose, at the baseline stage, and label them so nobody "finds" your float later and spends it for you.
When to Set It, and When to Reset It
The right moment to baseline is when the plan is complete enough to commit to but before work has drifted from it. For most jobs that's right after the schedule clears its review with the owner and major subs — early enough that it still describes the plan, late enough that it's not built on guesses about a design that isn't finished.
On long or phased projects, you'll often want more than one baseline. A single baseline set at notice-to-proceed for a two-year project becomes archaeology by month eight. Common approaches:
- Original baseline: the contract plan, frozen and never touched. This is your claims and reference anchor.
- Rebaseline after a major change: when a design change, a big change order, or a recovery plan makes the original plan genuinely obsolete, set a new approved baseline and keep the old one archived.
- Phase baselines: on multi-building or multi-phase work, baseline each phase as its design and logic firm up, rather than pretending you knew building four's plan on day one.
The temptation to rebaseline is a trap worth naming. Rebaselining because the plan legitimately changed is discipline. Rebaselining because you're behind and want the variance to disappear is fraud with extra steps. The difference is whether the original is preserved and whether the reset went through formal approval — which is the whole reason approval exists.
Approval Is What Makes It Binding
A baseline nobody approved is just your opinion in a nicer format. The approval step — owner, GC, and ideally the subs whose scopes drive the critical path signing off — is what converts a schedule into a commitment. It creates the shared accountability that makes the baseline useful when things go sideways.
Keep the approval formal and keep the record. Note who approved it, on what date, and against what set of assumptions and drawings. When a claim shows up eighteen months later, that paper trail is the difference between "here's the approved plan and here's exactly where the owner's late RFI response blew it up" and a he-said-she-said you'll lose.
Protect It — Software Discipline Matters Here
Once a baseline is set, it needs to be locked. This is where good scheduling tools earn their keep: the baseline should be stored separately from the working schedule so you can't casually overwrite it, and any reset should be a deliberate, logged action rather than a stray keystroke. If your tool lets anyone drag a bar and silently move the baseline with it, you don't have a baseline, you have a suggestion.
Practically, that means the working schedule is where daily reality lives and the baseline sits behind glass. When you update progress — actual starts, actual finishes, percent complete — you're updating the working schedule, and the software shows you the gap against the frozen baseline bars. That gap is the whole point.
Reading the Variance Without Fooling Yourself
Comparison is where a baseline pays off, and it's also where people lie to themselves. A few things to watch:
- Percent complete is not percent of time elapsed. An activity can be 60% of the way through its planned days and 20% done. Status against physical progress on site, not against the calendar.
- A green summary can hide a red critical path. The job overall might look 3% behind while the one activity that actually drives handover is two weeks late. Always look at variance on the critical path specifically, not just the rolled-up number.
- Float erosion is an early warning. Watch activities that had ten days of float quietly drop to two. Nothing's "late" yet, but the cushion is gone and the next hiccup goes straight to the finish date. This is the signal that separates supers who see problems coming from ones who get surprised.
Variance reporting — the current-versus-baseline bars, the slippage on key milestones — is what you take into the owner meeting. It turns "we think we're okay" into a specific, defensible status that everyone can see at once.
Where the Baseline Meets the Weekly Plan
Here's the part most articles about baselines skip, and it's the part that actually runs a job. The baseline is the six-thousand-foot view. The work that keeps you on it happens in the two-to-six-week window, in your look-ahead and your weekly work plan.
The baseline says "drywall on level three finishes March 14." It does not tell the drywall foreman which rooms to hang Tuesday, or that the electrician still owes you three rooms of rough-in on the north wing, or that the material hoist is booked for the curtain wall crew until Thursday. Short-interval scheduling is where those collisions get caught before they become slippage. You break the baseline's monthly commitments down into what each crew will physically accomplish this week and next, in which locations, in what order — and you check that the trade flow works: that the trade ahead has actually cleared the area, that inspections are scheduled, that materials are staged.
That's the loop that keeps a baseline honest. The baseline sets the target; the weekly look-ahead is how you hit it or catch the miss early. Tools like LookAheadWall live in that weekly layer — location-based work plans, trade-flow sequences, and a schedule your subs can actually see on their phones — precisely because that's where a baseline is defended or lost. A beautiful baseline with no short-interval discipline behind it is a plan you'll watch slip in real time and be powerless to stop.
Baselines, Claims, and the History You'll Be Glad You Kept
Sooner or later a job goes bad enough that money is on the line, and the baseline stops being a management tool and becomes evidence. This is why you never delete an old baseline. Archive every one — original, each rebaseline, each recovery plan — with its approval date and the assumptions behind it.
When a delay claim lands, the analysis usually compares what the approved plan showed against what actually happened, isolating who caused which slip and when. That comparison is only possible if the baselines still exist and the actuals were recorded honestly along the way. A contractor who kept a clean original baseline, logged real progress weekly, and preserved every reset walks into that conversation with a story. A contractor who rebaselined away every problem and can't produce the original walks in with nothing — and often ends up eating delays that weren't even their fault, because they destroyed the proof.
Some baselines carry direct contractual weight — the approved schedule may itself define milestone obligations and liquidated-damages triggers. Treat those with extra care. Know which milestones in your baseline are contractual and which are internal, because the consequences of blowing them are not the same, and you want that clarity before you're negotiating over it.
The Short Version
A baseline is a promise you wrote down and everyone signed. Build it honestly, with real durations and buffers and the people who'll live under it in the room. Freeze it, approve it formally, and protect it from casual edits. Measure the working schedule against it every cycle, watching the critical path and float erosion, not just the feel-good summary number. Defend it week to week in your look-ahead, because that's where the job is actually won or lost. And keep every version forever — the day you need it for a claim, it'll be worth more than the whole software license.
Do that, and your schedule stops being a wall decoration and starts being what it's supposed to be: the tool you use to control the job instead of the record of how you lost control of it.