← Blog
How-to·4 May 2026·6 min read

Baselines, slip bars and the data-date curtain: a variance story in one view

The monthly report shouldn't need a variance table. Set a baseline, switch on slip bars, fill progress to the data date and drop a status line — and the whole story tells itself in one picture: what slipped, by how much, and what's quietly running ahead. Here's how to build it, and how to read it.

Every progress meeting has the same awkward moment. Someone pulls up a grid of columns — baseline start, baseline finish, actual start, actual finish, start variance, finish variance — and the room goes quiet while people try to do arithmetic in their heads. Which activities slipped? By how many days? Is anything actually ahead? The numbers are all there. Nobody can see them.

Variance is a visual idea trapped in a spreadsheet. The fix isn't more columns — it's a picture that puts the plan and the reality on the same row, so the gap between them is the slip. Set that up once and your monthly report answers the two questions a sponsor actually asks — what's late, and what's early — before you've said a word.

Anatomy of a slip bar Wk 1Wk 3Wk 5Wk 7 Excavation ghost = baseline (the plan) solid = current (forecast / actual) slip +10 days late
Fig 1. One row, two bars. The faint ghost underneath is the baseline — where you said the work would happen. The solid bar on top is where it actually is now. The red overhang between the two finishes is the slip. No arithmetic; the distance is the answer.

What each mark means

A slip-bar view has exactly four moving parts, and once you know them the whole picture reads instantly:

Read together, they carry the entire variance narrative. You don't compute finish variance — you see it as the overhang. You don't hunt for what's ahead — an activity whose solid bar has pulled left of its ghost is ahead, and it jumps out because the colour of the gap flips.

The data-date curtain: claimed history vs forecast ← claimed / actual forecast to complete → data date Steelwork progress fill stops exactly at the data date — you can't be "done ahead of now"
Fig 2. The data date is the honest line. Progress fill runs up to it and no further — everything to its right is a forecast, drawn faded. If a bar's fill lags behind the line, that activity is behind on work done, whatever its dates claim.

Set it up in four moves

Take a small, honest example — four activities on an early works package. Two have slipped, one's holding, one is running ahead of plan. Here's how to turn a raw schedule into the report that shows all of that at once.

  1. Set or import a baseline. Freeze the current dates as the baseline (or bring in an approved baseline from your P6/MSP export — the as-planned dates ride in with the file). This is the ghost you'll measure everything against; snapshot it before the first update, not after things have moved.
  2. Turn on slip bars. Flip the baseline display on and Sketchedule draws each baseline bar as a faint ghost under the current bar, with the gap between them shaded. Every row now shows plan-vs-actual on one line — no variance column needed (Fig 1).
  3. Set the data date and fill progress. Drop the data date to the reporting cut-off; it appears as a dashed red line across the chart. Enter % complete (or actual start/finish) per activity and the bars fill up to that line — claimed history solid, forecast faded (Fig 2).
  4. Add the status line. Draw the progress/status line — it threads through where each activity has actually reached. Where it bulges left of the data date, that work is behind; where it bows right, it's ahead. One zig-zag line, and the whole package's ahead/behind reads at a glance (Fig 3).
Early works package · baseline vs current — built in Sketchedule Activity Start Finish % JanFebMarAprMayJun ▾ Early works summary data date · 15 Mar Site clearance 05 Jan02 Feb100 −8d ahead Excavation 03 Feb28 Mar62 +12d slip Foundations 10 Mar08 May18 +15d slip Drainage 01 Apr30 Apr0 on plan Package complete handover MS ▬ status line bows right of the data date → work is running behind baseline (ghost) current bar slip status line 2 slipped (Excavation, Foundations) · 1 ahead (Site clearance) · 1 on plan — in one glance.
Fig 3. The app-faithful view: grid on the left, Gantt on the right. Ghost baseline bars sit under the current bars; Excavation's red overhang is the highlighted slip; the dashed line is the data date; the accent zig-zag is the status line. Two activities have slipped, one is eight days ahead — and you read all of it without touching a variance column.
How to read it in five seconds: ghost under solid, right of it and red = slipping; left of it and green = ahead. Fill stops at the data date — that's the line between what you've claimed and what you're forecasting. Where the status line bows away from that line, work is off the plan. Two slips, one on plan, one ahead — no table, no arithmetic.

Where the variance story gets buried

Desktop schedulers can absolutely compute all of this — baseline start, baseline finish, start and finish variance, days late — and they'll happily give it to you as columns. That's the trouble. The variance story ends up scattered across six numeric fields on each row, and a director reading a printout has to reassemble it in their head, one activity at a time. The moment it's a table, it stops being obvious.

The category habit is worse still: export the grid, screenshot it into a slide, and paste a colour-coded variance table under a title. Now the picture is a spreadsheet of a spreadsheet. Nobody looks at a variance column and feels a slip; they feel it when they see the current bar hanging out past the ghost, coloured red, with a status line sagging behind the data date. Same data — one is legible, one is homework.

That legibility is the whole job here: put the plan and the reality on the same row and let the gap speak. One clean picture instead of a wall of columns.

The network still lives upstream. Slip bars present variance; they don't recompute it. The dates, the logic, the critical path and the actuals still come from your P6 or MS Project schedule — that stays the source of truth. Sketchedule reads the baseline and current dates and draws the story; it doesn't re-run the network. Keep the engine where it belongs and stop hand-building the variance slide.

Two ways to get it wrong

Baselining after the horse has bolted

A baseline snapped after the schedule has already moved isn't a plan — it's a photo of the delay. The ghost bars will sit under the current bars and everything looks on track, because you froze reality, not the promise. Baseline the approved plan before the first update, and keep it frozen: the value of a baseline is that it doesn't move when things go wrong.

Progress that outruns the data date

If an activity's % complete implies work finished to the right of the data date, the picture quietly lies — you can't have done work in the future. Bring progress honestly to the cut-off, let the fill stop at the line, and the status line tells the truth. A slip bar is only as honest as the progress you feed it.

You seeIt meansDo next
Solid bar right of the ghost, red gapSlipping — finishing later than plannedCheck the driving logic in P6; is it on the critical path?
Solid bar left of the ghost, green gapAhead — beating the baselineBank it, or reallocate the float downstream
Fill stops short of the data dateBehind on work done, whatever the dates sayRe-check % complete against site reality
Status line bowing right of the data dateThat workstream is running behind nowFocus recovery there before it reaches a milestone

Key takeaways

Turn your next report into one picture

Open Sketchedule in a browser — free, no install, nothing uploaded. Set a baseline, switch on slip bars, and let the variance tell itself.

← BlogAll articles

Primavera and P6 are trademarks of Oracle Corporation; Microsoft Project is a trademark of Microsoft Corporation. Sketchedule is an independent product and is not affiliated with, endorsed by or sponsored by Oracle or Microsoft. Figures are illustrative, drawn in Sketchedule; Fig 3 is a faithful redraw of a baseline-vs-current early-works view built in the app.