Gantt charts have been widely used for a hundred years. Like all tools they have their sweet spot. Gantt charts are great for visualizing projects with immutable dependencies. That is dependencies that fundamentally cannot be changed. Like; do step A and then step B, where step B cannot start until step A is finished. The common example is building a house, you cannot start the walls until the floor is completed. Likewise the roof cannot be constructed until the walls are completed. This approach has been, successfully, used by software development teams for decades. The UI can be built after the middle ware.
It is a question of what can you can do and efficiencies. If your team works best with a big design up front (BDUF) then this is probably your sweet spot, that is, you optimal. But if your team is more adaptable (dare I say agile) then this is a solution but not the optimal and may be a much slower way to completion. A question of potential and achievable.
Try managing a project using a Gantt chart in Microsoft Project where the developers, to reduce time to delivery, develop the house's roof before the floor is done.
Assuming that commercial success is the goal (big assumption), the best option to report to higher management is always the facts. The project is X% completed and its estimated time of completion is XYZ. Management understands that. In fact, that is what they try to extract from a Gantt chart. But, like many approaches, Gantt charts can be used to redefine success with complex presentations that nobody understands.
The real issue is to measure functional completion where functional means 'functional' not just developed. This means accepted (testing) by the real users.
Planning for failure warning signes:
- More reference to "Gantt charts" than project management.
- Releases defined as 'coded' prior to user testing.
- Management repeatedly referring to 'sign off' on specifications.
- Demonizing the customers.
- Focus on department values over company commercial needs.
