How to Track Schedule Slip With a Baseline

Compare the plan against what actually happened

A baseline is a snapshot. Record a task's dates once, keep working, and GanttFlow will show you exactly how far reality has drifted from that first plan.

This solves a specific and very common credibility problem. Without a baseline, a project plan silently rewrites its own history — every time you drag a bar, the old date is gone, and the chart always shows a project that is exactly on schedule for the schedule it currently has. Everyone in the room knows this is not true, which is why an unbaselined chart tends to be treated as decoration rather than evidence.

When to set the baseline

This is the decision that determines whether baselines are useful or annoying, and the instinct to baseline immediately is usually wrong.

Baseline when the plan becomes a commitment, not when it becomes a chart. Those are different moments. A plan you are still shaping will move a dozen times in its first week, and baselining it produces variance labels that measure your own drafting rather than any real slip.

Concretely, that usually means:

• On a funded programme, baseline at budget approval. Before that the dates are a proposal.
• On a software release, baseline after the architecture review, when the estimates are grounded in something.
• On a construction project, baseline at contract signature, so the comparison is against the contractual programme.
• On a campaign, baseline at creative lock, the point after which changes cost money.

The common thread: baseline at the moment someone else starts relying on your dates.

Reading variance honestly

A variance label is a number, and numbers invite over-interpretation. A few things worth holding in mind when you present one.

Early is not automatically good. A task finishing two weeks early usually means it was overestimated, that scope quietly left it, or that it was not the thing blocking anyone. All three are worth knowing, and none of them are a win to celebrate in a status meeting.

Small variance on a long task is noise. Three days of drift on a fourteen-week bar is inside the estimating error. Three days on a one-week bar is a forty per cent overrun. Read the label as a proportion, not an absolute.

Variance on the critical path is the only variance that moves the end date. A task with slack can slip a fortnight and change nothing about delivery. Tracing which links are actually binding — see the dependencies guide — tells you which of your variance labels deserve attention.

Accumulated small slips are the real pattern. One task at plus four days is a task. Nine tasks at plus four days is a systematic estimating problem, and it is visible only because the baseline kept the original numbers.

Baselines and dependencies together

These two features interact in a way worth understanding before your first status meeting.

When you drag a task on a linked chart, everything downstream moves with it. If those downstream tasks are baselined, they will all immediately show variance — even though nobody did anything wrong on any of them. This is correct behaviour and it is genuinely informative: it shows the blast radius of a single delay rather than just the delay itself.

It does mean a chart can go from all-green to mostly-red after one drag, which is worth explaining when you present it. The useful framing is that one task slipped and eight tasks inherited it, not that nine things went wrong.

What a baseline will not tell you

Why something slipped. The chart records that a date moved, never the reason. Keep that in the written commentary beside the export; six months later it is the only thing anyone actually wants to know.

Whether the original estimate was any good. A task that finished exactly on baseline might have been well estimated or generously padded. Variance measures adherence to a plan, not the quality of the plan.

Scope changes. If a task grew because someone added work to it, the variance label shows a delay with no indication that the task is now a different task. This is the single biggest limitation to be aware of, and the reason a baselined chart should always travel with a note about what changed.

Common mistakes with baselines

Baselining the first draft. Produces variance labels that measure your own planning process. Wait until the plan is agreed.

Re-baselining after every slip. This resets the comparison and destroys exactly the history that made the baseline worth having. A plan that has been re-baselined three times is a plan that has never been late, which nobody believes. Re-baseline only after a formally approved change of scope or dates — and say so when you do.

Baselining some tasks and not others. Variance labels appear only where a baseline exists, so a partially baselined chart looks like a mostly on-time project. Baseline the whole plan or none of it.

Hiding the baselines before a difficult meeting. Tempting, and it is the fastest way to lose the credibility the feature exists to build. A chart that visibly slipped twice for stated reasons is far more trustworthy than one that has always been perfect.

Using it in a status update

The rhythm that works: drag the bars to match reality, glance at the variance labels, note the two or three that sit on the critical path, and export a PNG with baselines showing. The chart then makes the argument for you — here is what we agreed, here is where we are, here is the gap — and the conversation moves to what to do about it rather than to whether there is a problem.

One further habit worth forming: keep the previous week's export. A single baselined chart shows where you are against the plan, but two consecutive exports show the direction — whether the gap is widening, holding, or closing. That trend is usually the thing a sponsor actually wants to know, and it costs nothing beyond not deleting last week's image.