the fault is not allowing time to test and fix in the right places not in wanting a schedule.

The schedule also does never work anyway.

Passing a design down and going away doesn't work. Scheduling tasks before you star them doesn't work. Testing only at the end doesn't work.

The one thing civil engineering has that resembles PMBoK is designing things beforehand. And only civil engineering does that, only because they can't prototype.

The benefit of a Gantt chart isn't meeting deadlines, it is organizing work. You have all of the steps and what each of them depends on and a timeline. If something slips you know how to update your estimates for everything downstream. If several things are at risk you can see which ones have more critical time constraints and allocate resources effectively.

> If several things are at risk you can see which ones have more critical time constraints and allocate resources effectively

Hum... Have you used them that way? And have you needed a project design to actually discover risks and estimate that you need to act on them?

Or better, have you found any unexpected risk on a project design, and seen it materialize on practice?

> If something slips you know how to update your estimates for everything downstream.

And then your renewed estimates will be wrong again. No idea if more or less wrong than before your revision though. It can go either way.

>Hum... Have you used them that way? And have you needed a project design to actually discover risks and estimate that you need to act on them?

Yes. These things are all over the place in defense.

One of the most important exercises in doing a Gantt chart is finding the "critical path" which is the set of tasks which can't slip without effecting the final timeline. If step two has two separate tasks that step 3 depends on, the longer task is on the critical path, the shorter is not because the shorter task can be delayed at least some without affecting when step 3 starts.

As the project continues you update the chart with what actually happened vs. your plans. The goal is to minimize changes, sometimes you can, sometimes you can't, but when there are changes you can see how the whole flow is affected and you can easily communicate the change in deadlines, changes in budgets, you can pull people off of one task and put them on another, etc.

In agile you do way less of this planning and the path is usually much more simple so you don't _need_ these tools to be successful.

civial engineerin, is often small variation on every other structrure. as suchiit is easy to estimate as things didn't change. when things are very different is when they overrun schedules.