Making a Gantt chart that stays true
Most Gantt charts are drawings. A bar moved by hand records where somebody wished the work would happen.
A drawing stops being true immediately
Drag a bar in a drawing tool and nothing downstream moves, no dependency is checked, and the chart quietly stops describing the plan the moment the first date changes.
In a computed chart the bars are output. Change a duration and everything depending on it moves, because the arrangement came from the dependencies rather than from a mouse. If that produces an unpleasant picture, the picture is right and the plan is the problem.
The gaps in a bar are weekends
Durations are working days; charts are drawn on calendar days. A five-day task starting Thursday spans nine days on the page.
That is not an error, and it is exactly what people forget when reading a date off a chart. Shading the non-working days makes it visible — without the shading the same chart is quietly misleading.
Float is the part worth looking at
The bar shows when work is planned. The tail after it shows how far it can slip before the project is affected. Activities with no tail are where a single bad day costs a day of the finish.
A chart where almost nothing has a tail is usually over-constrained rather than tight — dependencies drawn more rigidly than the work requires.
Always publish the table
A bar chart cannot be read by a screen reader, does not survive being printed small, and hides exact dates behind pixel positions.
The table carrying the same numbers is the version to send anyone who has to act on a specific date, and it costs nothing to produce alongside.
Progress shading is not progress
A bar shaded 60% complete records somebody's estimate of how far along the work is. It is the least reliable number on the chart and the one stakeholders look at first.
Where it matters, prefer things that are either done or not done — a milestone passed, a test suite green — over a percentage that can sit at 90% for a month.