Most of the Gantt charts are analytically thin, too simple, and lack substantive detail. The charts should be more intense. At a minimum, the charts should be annotated--for example, with to-do lists at particular points on the grid. About half the charts show their thin data in heavy grid prisons. For these charts the main visual statement is the administrative grid prison, not the actual tasks contained by the grid.
See the discussion at Tufte http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0...
I do mine using LaTeXe!
and this http://www.martin-kumm.de/tex_gantt_package.php
for those interested in Latex Gantt charts.
The pgf/TikZ package is the best graphics package I have used. Just the fact that it exists is a monument to TeX, Knuth and Lamport.
My experience in two recent projects using Gantt charts as part of timelining has left me with a bitter taste for how they relate to actual concrete programming tasks.
A key failure a number of our developers identified is code doesn't translate well to a linear scale. It's nearly meaningless for me to tell my software lead that a component is 80% "done" after a week, when the 80-90% gap could take a month, and 90%-100% might not even be attainable. (I have a nearly impossible time ever considering something 100% "done".)
Coupled with dependencies and "Waiting For" or "Requires", it feels entirely like it's not an appropriate or truly representative model. This has led to intense frustration and tensions. Most of the developers on my current project dread the weekly Gantt chart update.
I most often find myself simply saying, "whatever I said component A was at last week, add 1%". It leads to a massive disjoint as one moves further up the management chain.
I realize this is a mini-railing against something you might not even be intending to use them for. I also realize that our software company may not be getting maximum utility out of the style of project management we use. I only speak from a developer's perspective who has been frustrated time and again when faced with something so horribly artificial-feeling.
edit For what it's worth, we use Microsoft Project. I've also used dotproject for non-work related coding I've done, but never learned it fully enough to speak to its capabilities or strengths and weakenesses.
I'd say you have a hard time being a programmer then. At the end of the day your code needs to get into production, and this should be after the point your job is "100% done" so the people having to do work after yours (qa, release etc.) can do their job. Bug fixing etc. aside it all depends on finding a satisfactory "definition of done". We call it exactly like this and it is an important part of our project management early on in every project.
On the above Project (a high-rise Tower) we came up with a graphic that had little squares representing activities. The graphic looked similar to the Tower:
---------
| | | | |
---------
| | | | |
---------
Using color, green for done and white for not done, you could have a snap of progress at a glance. You set them side by side and you can see weekly Progress.I have been trying to refine the idea and make a start-up out of it:)
(You can think of software as a Tower as well!)
dotProject: http://www.dotproject.net/
Redmine: http://www.redmine.org/
qdPM: http://qdpm.net/
I ended up pointing to Project Management software, but they all do Gantts...
The system is text-based with an editor built into the GUI. The downside is that installing it means pulling a number of KDE dependencies as well...
Do you have anything to do with it?
www.tomsplanner.com