Learning Center
Why Your Gantt Chart Isn’t a Schedule
A Gantt chart is a picture: a row of bars sitting on a timeline. A CPM (Critical Path Method) schedule is the thing the picture is drawn from -- a network of activities connected by dependencies, with calculated dates and float. Most of the time nobody notices the difference. The moment it matters is exactly when you need the picture to tell you something the bars alone can’t.
Two Different Things, One Familiar Picture
A Gantt chart is a visualization. Every bar’s position comes from somewhere -- a start date, a duration, a finish date -- and the chart’s only job is to draw that information as a rectangle on a timeline. It doesn’t matter whether those dates were typed in by hand or calculated by a scheduling engine; the bar looks the same either way.
A CPM schedule is the logic underneath. Each activity is connected to others by dependencies -- finish-to-start, start-to-start, and so on -- and from that network of connections, plus each activity’s duration, a CPM engine calculates early and late dates and total float for every activity, and identifies the critical path -- the chain of zero-float activities that controls the project finish date. A Gantt chart is one way to display the result of that calculation. It could just as easily be shown as a network diagram, or a plain table of dates -- the bars are a rendering choice, not the schedule itself.
A Worked Example: Six Bars, Two Very Different Readings
Here’s a small, fictional six-activity sequence for an interior fit-out package. Below is its Gantt chart, drawn with each bar in exactly the position its calculated start and finish put it -- and nothing else.
Read left to right, this looks like a normal, if slightly busy, schedule. Design coordination and site preparation sit end-to-end at the front, material procurement runs long in parallel, and rough-in, finishes, and closeout march across the back half. Nothing about the picture tells you which bar is actually driving the day-41 finish, which two have room to slip without consequence, or that two bars that appear to connect (A finishing right where C starts) have nothing to do with the activity that’s actually critical.
Now here’s the same six activities as a logic network -- the dependencies that actually produced those bar positions, plus each activity’s calculated float.
The network reveals what the Gantt chart couldn’t. Rough-in doesn’t start when it does because site preparation finished on day 10 -- it starts on day 20 because it also needs material procurement finished, and that’s the later of the two. Design coordination and site preparation, despite sitting right at the front of the visual timeline, have ten days of float each: they could slip by more than a week and the project would still finish on day 41. Material procurement, which never looks connected to anything in the bar chart, is the entire critical path from day zero.
Why This Matters for Delay Analysis
A schedule that renders as a clean, plausible-looking Gantt chart can still have logic that’s missing, wrong, or simply undocumented -- an activity with no predecessor at all, a dependency that should exist but doesn’t, or a link pointed at the wrong successor. None of that shows up as a visual defect in the bars. It only shows up in the calculated dates and float, and only if something forces you to check the logic rather than the picture.
Delay analysis lives entirely in that logic. Tracing why the finish date moved -- which activity’s slip actually consumed float versus pushed the finish, and which activities had room to absorb a delay without consequence -- requires the real network, not a rendering of it. A Gantt chart that looks fine is not evidence that the schedule behind it is sound; it’s only evidence that someone drew the bars where the dates said to.
Claims Digger reads the schedule file itself, not just the picture. When you upload a .xer, it works from the actual CPM network stored in the file -- every activity’s dependencies, calculated float, and the critical path -- rather than inferring anything from how bars happen to line up on a timeline. See how it works.
Frequently Asked Questions
- If a Gantt chart's bars run in a sensible left-to-right order, doesn't that already reflect the logic?
- No. The bars sit at whatever dates a scheduling engine (or a person) calculated or typed in -- but the bar itself doesn't show why an activity starts when it does. Two activities can sit end-to-end and look connected while having no dependency at all, and two activities with a real dependency can sit with a visible gap between them for reasons the bars never explain.
- Can two Gantt charts for the same project look almost identical but have different critical paths?
- Yes, and it doesn't take much: change which of two parallel activities actually drives a downstream start, and every bar can stay in nearly the same place while the activity carrying zero float -- the one that actually controls the finish date -- switches entirely.
- Do the dependency lines some Gantt views draw solve this?
- They help -- a visible line at least confirms a link exists. But most Gantt views still don't show computed float or which of several incoming links is the one actually driving a successor's start date. You need the underlying network data, not just a picture of it, to answer either question.
- Why does this matter for a delay claim specifically?
- A delay analysis has to trace cause and effect through the network -- which activity's slip actually pushed the finish date, and which had float to absorb it. If the logic feeding that network is missing or wrong, the Gantt chart drawn from it can still look perfectly reasonable while the conclusion built on it is not.
Part of the Claims Digger Learning Center. Related reading: What Total Float Tells You About Risk · Full glossary