Gantt charts are great when you need to clearly communicate your project schedule, progress to business owners/stakeholders/team members as well as external stakeholders. Visually the Gantt chart is unsurpassed; it is immediately comprehensible for people with little or no knowledge of your project. Usually, you can define your project on a single sheet of paper, then you can describe to the attendees what you expect to happen and provide justification to allocate your resources accordingly. They are simple to read, update, monitor progress, monitor schedule and have the ability to monitor resources for the entire development project.
If they are so easy do they have any limitations? Yes they do: (see below)
1. Not easily reveal a project's critical path.
2. Not clearly identify a behind schedule condition.
3. Present a challenge for recording progress.
4. No widely accepted standards for Gantt charts.
5. Require a great deal of updating and posting.
6. Are difficult to use to respond to customer requests for accelerated project delivery.
So in the final analysis, how should Gantt charts be used? I have used them in conjunction with burn-down charts. These charts (burn-down) are usually associated with agile frameworks (XP, Scrum,) but can be used as a quick and easy way to communicate with management the progress of the development project.