Data date first: how to read any schedule in the right order

You don't have to be a planner to interrogate a programme. A schedule tells its story in a fixed order, and once you know the order you can read almost any P6 or MS Project file — or even a printed Gantt PDF — in a couple of minutes. Start at the data date, then the completion milestone's float, then the driving path, the constraints, the baseline, and finally the numbers. Six moves, and you'll see the picture before anyone spins it for you.

A project director, a QS and a package manager get sent the same monthly programme. All three open it, all three nod, and all three walk away with a different impression — usually the one the sender intended. That's not because the schedule is dishonest. It's because most people read a Gantt the way they'd skim a menu: left to right, top to bottom, absorbing bar lengths and colours and stopping when the milestone at the bottom looks roughly where it was last month.

The bars are the least reliable thing in the file. A planner who wants a programme to look healthy has a dozen levers — a soft constraint here, a stretched remaining duration there, a baseline quietly re-saved last week — and every one of them is invisible if you only look at bar lengths. Reading a schedule properly means checking the plumbing in a set order, each check building on the last. Here's the order, why it matters, and what "bad" looks like at each step.

Step 1 — Find the data date before anything else

The data date (P6) or status date (MS Project) is the single most important mark on the page, and most Gantts show it as a thin vertical line. It's the "as of" moment: everything to its left is claimed history — work reported as done — and everything to its right is forecast, a promise not yet kept. Until you've found it, you can't tell which bars are facts and which are hopes.

Two things go wrong here, both common. First, the data date is stale — the file says "as of last month" and someone is presenting it as this month's position, so a month of slippage is hiding in plain sight. Check the date against the reporting period; if they don't match, the programme hasn't been updated, it's been re-dated. Second, work sits to the right of the line with no progress against it but bars that look reassuringly advanced. That's forecast dressed up as achievement. Find the line first, and read the rest of the schedule relative to it.

Step 2 — Check the completion milestone's float

Now jump to the bottom: the milestone that matters — practical completion, handover, the contractual sectional date. Don't look at where its bar sits. Look at its total float: how many days it can slip before the end date moves. That one number is the health of the whole programme in a nutshell.

Positive float on the completion milestone means slack — the programme has room. Zero float means it's on the knife-edge; any delay on the driving chain pushes the date. Negative float is the alarm: the schedule is already telling you the current logic can't hit the date, and the size of the negative number is how many days late. A director who learns to ask one question — "what's the float on completion?" — is ahead of most rooms. And beware the opposite tell: a completion milestone showing hundreds of days of float usually means it's dangling, not driven by the network at all, which brings us to the next two checks.

Step 3 — Trace the driving (critical) path

The critical path is the chain of activities with the least float — the sequence that actually controls the end date. Most tools will highlight it (usually red). This is where you find out what the programme is really waiting on. It's frequently not what the headline says: the story is "we're held up by steel", but the driving path runs through a permit, or a long-lead procurement, or a single approval nobody's chasing.

What bad looks like: no critical path shows at all (the logic is too broken to compute one), or the "critical" chain is implausibly short and skips the obvious long-lead items — a sign of missing links or open ends. If the driving path doesn't route through the things you know are hard, don't trust the finish date; trust the gaps in the logic instead.

Step 4 — Interrogate the constraints

A constraint is a hard date pinned onto an activity — "must finish on", "start no later than", "finish on". Constraints override the logic: a "finish on" date can manufacture float that the network never earned, and a "must finish by" can create negative float out of nowhere. Planners use them legitimately for real fixed dates, but they're also the easiest way to make a programme lie without touching a single link.

What bad looks like: constraints scattered across dozens of activities, especially soft ones that should be driven by predecessors. Every constraint you find is a question — "why is this date pinned, and what happens to the finish if I release it?" A schedule held together by constraints rather than logic will look calm right up until it isn't. If the completion float from step 2 looked suspiciously comfortable, this is usually where the comfort came from.

Step 5 — Compare against the baseline

The baseline is the approved plan, frozen. Turn it on and each activity shows a ghost bar — where the work was meant to sit — under the current bar. The gap between them is the slip (or the gain). Without a baseline you can only see where the programme is; with one you see whether that's better or worse than promised.

What bad looks like: no baseline at all (you're being asked to judge progress against nothing), or a baseline that's suspiciously close to the current dates — a sign it was re-saved recently to erase the slip. A legitimate baseline is set once, before the first update, and never moves. If the ghost bars hug the current bars while everyone agrees the job is behind, the plan has been quietly rewritten to match reality. That's not a programme that's on track; it's a photograph of the delay.

Step 6 — Reconcile % complete with remaining duration

The last check is arithmetic the schedule should pass and often fails. An activity claims 80% complete — so its remaining duration should be roughly 20% of its original. When those two disagree, someone typed a percentage that isn't backed by the work. "90% complete, six weeks remaining on an eight-week task" is the classic tell of the 90%-done-forever activity that never closes out.

What bad looks like: high % complete with large remaining durations, or activities showing progress that started to the right of the data date. This is the ground truth that either confirms or dismantles everything above. If the numbers don't reconcile, the forecast dates aren't trustworthy no matter how tidy the bars look — because the bars are drawn from durations, and the durations have been overridden by optimism.

The order is the whole trick

None of these checks is hard on its own. The value is in the sequence: the data date tells you where "now" is, so the float means something; the float sends you to the driving path; the driving path exposes which constraints matter; the constraints and the baseline explain why the float looked the way it did; and the % vs remaining is the ground-truth that either confirms the story or blows it up. Read them out of order and each one misleads you. Read them in order and a schedule you've never seen gives up its secrets fast — no planning qualification required.

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 4 is a faithful redraw of a Gantt-anatomy view built in the app.