Thursday, September 28, 2006

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.


tahpot said...

Don't forget that 90% of software projects miss deadlines... especially when using gantt charts- because its just not possible to know how much time something that hasn't been done, will take.
The best way to guestimate how long something will take is experience and various mathematical formulas that use the number of lines of code for previously written code. But then again how much code is written depends on the programmer etc. etc.
In fact it has been shown that the efficiency of programmers can be up to 100 times! ie: 1 person can spend 100th the time to get the same result... Try putting that into a gantt chart.

Unknown said...

Creating gantt chart from bugzilla is a gr8 idea, do you have any clue of how to do this?

Anonymous said...

The "more realistically" Gantt chart is here:

zamroni said...

Many long Gantt chart is difficult to be read.
I created vertically flowing chart to solve large Gantt chart problem.