Well, maybe not all of them. Some are so pretty, that uniform cascading of well ordered tasks trickling downhill to perfectly coincide with the deadline. Get color prints made, frame them, and hang them as abstract art. Don’t use them to manage your software development.
Balance is an important part of life, so I plan to add some perspective to the inflammatory opening remarks (so I can keep my PMP certification). First though, let's bludgeon the hot air out of the Gantt chart culture that inflicts many software organizations. Included in this category are the so called “activity network” models (primarily Gantt and PERT) and the tools that propagate their widespread use. Unfortunately this is pretty much every project/work management tool out there from Microsoft Project and other scheduling tools to the many group-ware collaboration websites. No matter how many pretty pictures are created, relying on these techniques to manage software work just isn't very effective.
Where does this hostility come from? Was I abused by project managers as a child? No, that came later. And then the cycle of violence continued for a time as I inflicted Gantt charts on others. Eventually it became apparent that the model of work created in the scheduling tool, with its ubiquitous Gantt chart view, usually lacked ground truth. Energy would be invested by all creating, reviewing, presenting, updating, and wringing hands over the Microsoft Project file. Then people would go and get the work done without any regard to the Gantt chart. What to do to avoid this waste?
A valid approach is to adopt task-driven methodologies such as Scrum. I’ve never been a fan of adopting methodologies though. Although there are benefits in being told exactly how to do something, customizing a simple set of principles and practices often leads to a better optimized solution.
What is the purpose of Gantt charts? They provide visibility, predictability, coordination, and control of work. These seem like important things, at least to the pointy-haired managers. Why do scheduling tools often fail to provide good visibility, predictability, coordination, and control of software work? Because they focus on time-based management of the “critical path”, i.e., dependencies and ordering of work. Most software work runs into trouble not because the critical path was mismanaged, but because EFFORT was underestimated. If you do not have high confidence in your estimates, building elaborate Gantt charts based on those estimates will not increase your ability to manage work effectively.
What are some basic principles you can incorporate into your planning and management of work? Regardless of lifecycle and methodology all software work boils down to deliverables people need to create. Focus on these deliverables. Have individuals and teams define the deliverables for a release (sprint, milestone, whatever). Have them estimate effort ranges (not time or dates) for the deliverables. Use a simple spreadsheet to track effort expended on and completion of deliverables (and/or use work queues and burn-down charts). Let the team work out the fine-grain details and dependencies of the work on their own, whether formally with a methodology like Scrum or informally. Look at the big picture on a regular basis and see where adjustments may need to made.
Gantt chart views are important for managing a complex series of work, for instance, a team with lots of dependencies on other teams. They work best when focused on deliverable milestones rather than task details. Just as different views of a design (e.g., physical and logical decomposition, database, UI screens) increase the understanding of the software to be built, multiple views into software work increase the understanding of how that work is going.
Thus you may not need to throw your Gantt charts out, but you should only rely on them for what they are good at. And that is not for planning what task Tom and Susie will be working on at 2:30 pm this Wednesday.