The problem with a Gantt chart is...

... you can't eat it.

(Update: This article says it all, but better)

One of the best tests of any software; or product infact; is to dogfood it.

A Gantt chart is an organisation tool for planning the progress of a project. You've probably seen a bunch of them.

They look like (in a perfect world)


or more realistically



How exactly do you eat that?

• It's not dogfood.
• It's a wall poster you have to update every day.
• It's out of date within hours of being printed.
  
• You can only model the highest level items, like "buy a new car" blocks "driving to alice springs".
• I can't describe a chart to you easily over the phone, IRC, or by text only email - it's something I have to send as mail, or something I have to send as one big image.
• If you don't read the chart the same way I do; it's ambiguous.
  
• High level items will have heaps of dependencies; because they are composed of a billion smaller tasks. If two high level items are sufficently close enough and made of enough parts, they both depend on each other.
• The solution to the previous statement is to then divide your high levels tasks into two high levels, and a common mid level task.
• Doing that; however; leads to intricate detail. Intricate detail is a bitch to maintain and changes fastest of all. The only thing that can model the current state of software perfectly is the source code itself.
  
• The whole point of a gantt chart is to deal with things at an abstract level. But you can't sufficiently top-down design a gantt chart; as you have to constantly redesign your chart as new dependencies emerge from your intricate detail.
• The only way to deal with things abstractly is to avoid all but the simplest dependencies: "I can't get inside of my house with a key"; so "I need a house" and "I need a key" BEFORE "I need to buy a tv".
• If you can't really model dependencies, how can you set estimated end dates? How can you estimate how long something takes?
• If you can't reliably get a duration, or end date for an item; and you can't model dependencies properly; what's the point in putting it on a gantt chart - it will move the very next day... and the next, and the next.

If you can't tell, we have someone (more than one someone actually) at work who wants to top-down design projects with gantt charts.

My take:

• A chart should be generated by your bugtracking software if there's anything at all. Bugzilla, for instance has a great way to show dependencies. It should be a URL, not a wall poster.
  
• Subtasks and dependencies (intricate detail) should be managed with your source code control - trac + ticket numbers in SVN commits, changesets on tickets, and trac milestones are a great way of monitoring individual items for completeness.
• You should have several milestones of where you would like to be. You don't set deadlines for those. As soon as dependencies resolve themselves to a suitable level (say, from 10 to 2); you pick up work on that individual milestone again. These are 'targets of opportunity'.
  
• During your dogfooding; if a user can't achieve their goal, X, it goes in as a ticket and stays open until they can.
• Set deadlines only when you are about to do a sprint. Two weeks, or a month at the most is the longest duration of a sprint.