Software development: Gantt charts versus PR database

by dj on December 7, 2004

This is a topic that could easily described & discussed in about one hundred pages. I will attempt to offer a condensed version in about two or 3 paragraphs. Perhaps I shall go on longer if I feel inspired.

First off, everybody knows what a Gantt chart is. If not, go to http://www.ganttchart.com/index.html and read up on it a bit. I know basically two things about Gantt charts: One, you have to have one for any project of reasonable complexity, and two, most software engineers hate to see them. Actually in Creoland, where I spent the last seven years of my working life, most everybody hated them, not just the software engineers. Of couse, there was actually one guy at Creo who thought they were the neatest thing, and unfortunately this person was senior to me, and demanded them from me all the time. This wouldn't have bothered me so much, except that one, my team leader thought they were a waste of time, and two, this guy-who-name-will-not-be-mentioned, couldn't be bothered to install Microsoft Project on his laptop, so I had to make a PDF of the Gantt chart and send it to him. Then he would bitch about the size of the fonts. And so it went.

But anyways, back to the mechanics of Gantt charting. In my last year at Creo, I was working on some fabulously complicated, multi-disciplinary project that involved hardware design, software, chemistry, the whole nine yards. And to make things even more interesting, we outsourced a lot of it to a company in Europe where their command of English was good but not great. Our major sponsor/customer was a Six Sigma practitioner and the customer team was headed by their most senior project manager with about 10 years of experience in dealing with Creo development teams. Needless to say, my Microsoft Project skills were considerably enhanced by participating on that project.

At the beginning of the project, my opinion of Gantt charts was pretty much the same as the collective opinion of PWS (Creo's software division) which was: "If somebody is screwing up and screwing you, order them to do a Gantt chart so they know you're pissed off." Personally, I have never seen a Gantt chart of a software development project that completed on time, which maybe says something more about applications development than Gantt-charting. The guys from manufacturing love 'em though: Tell them you are going to run a project without doing a Gantt chart, and they'll look at you like you just proposed to walk naked through reception. In wintertime. But of course, the manufacturing guys always thought us software guys were a little flaky.

My opinion now? I like doing them for complex projects because it's a good way to show external dependencies to the software team. I also like to use them with a twist: I like to assign probabilities to each event happening the allotted period of time (or not at all) and then use the assigned values to calculate each path's probability of success. But then I'm weird that way.

The big secret why most developers hate Gantt charts is that there is a risk of some idiot project manager showing a detailed Gantt chart to somebody outside of the development team. This drives developers nuts. I once worked on a team where the project engineer did a Gantt chart for his team but wouldn't even show the chart to me, no matter how much carrot cake I brought to the development meetings. A poorly constructed Gantt chart can leave the impression that time and/or resources can be tweaked to save... ...money. Also, for some reason, redundancy looks bad on a Gantt chart, but any project manager/engineer knows that the more redundancy, the better. Lastly, most, if not all, non-developers vastly underestimate the ratio of planning (aka sitting in your chair at staring at the ceiling while thinking) to actually writing the code. Software development consists of about 3 parts "planning," one part writing code, and two parts fixing the code. Putting the "planning" bar on the Gantt chart always looks bad, and always will.

Conversely, most experienced software development teams (that I personally know of) use PR databases quite heavily. To see a nice lightweight yet powerful PR database, check out FogBUGZ at http://www.fogcreek.com/FogBUGZ/ When I actually start working on product development at Creo, that's all we used. The most powerful aspect of a PR database is that it allows for sophisticated management of feature requests, which as every product developer knows, is the killer problem that leads to most software projects being late or over budget or both. The Prinergy PR database had thousands of PR entries by the end of version two, offering a level of detail that couldn't possibly be equaled in a Gantt chart. For example, let's say a project manager wanted to see how many PR entries had to be fixed/dealt with before release to beta: he would just put a filter on the database, and then 10 or 20 or 50 entries would come up. Then the PM could look at the person(s) who filed those entries and then assign them to a developer, who would then own the problem.

What of course would be tremendously cool would be for a PR database program that could feed into a Gantt chart-making application. Then you could have Gantt chart that could change on a daily basis to reflect the mulitple real-world inputs that is captured by a good PR database. Of course, the chances of somebody coming up with a nifty little utility like that is close to zero. AFAIK, I'm only the PM in the world who thinks this would be a neat thing.

Comments on this entry are closed.