Question

My manager knows how to read a Gantt chart and can make sense of them. Why doesn't FogBugz have them?

Answer 1

Gantt charts were introduced 99 years ago to help manufacturing managers supervise complex, repetitive manufacturing projects like making steam locomotives. There's a lot of complexity, but not a lot of risk or variability in making the 205th iteration of a particular locomotive. Gantt charts helped non-assembly-line manufacturing operations to make their operations more efficient, making sure that the axle-makers were done with their batch of axles right about the time the wheelwrights were done with the wheels. That way, no one sat idle and the project moved along at maximum efficiency.

Gantt charts are great for managing projects where risk is low or measurable (5% chance that the drywall guy won't show up for work), or where variability is low (the drywall guy can finish 200-250 linear feet of wall in a shift).

The temptation is to use the same tool to represent complex software projects, but software projects are fraught with risk (turns out the libraries you rely on have a bug) and variability (the customer called again). On a construction project, if the drywall guy gets the flu, that part of the chart might come in at 110% of its initial projected time. In software, a total unknown can triple the time it takes to do a portion of the project.

Over the years, most software managers have found that using Gantt charts might provide them with an overall sense of control, though at great expense. But the chart actually hides more important information than it shows. It hides the risks and variability inherent in the development process. On the plus side, they're very easy to understand at a glance. On the downside, the understanding that they convey can be, and often is, deeply flawed.

Representing software projects with Gantt charts does have one thing to recommend it: people almost immediately grok the Gantt chart, no matter who they are. Going forward, we're hoping to work on a way of representing an information-rich chart that will capitalize on people's visceral understanding of the Gantt chart without sacrificing information-richness.

For now, the developer timelines give a good visceral impression of where you are in a project and where the risks might lie.

Answer 2

Actually, it would be useful to have gantt chart drawing capabilities, at least to have overview for all tracked projects. Just use not individual tasks for charting, but milestones. That way we can use all the benefits of fogbugz and keep management happy at the same time.

Answer 3

A Gantt chart shows milestones, a hierarchical list of tasks with estimates and dependencies between tasks - in what way do these things not apply to software development? The Developer Timelines, which is valuable in different ways, tells me none of these things (and I don't expect it to).

The problem is when the chart becomes the work product instead of a view into the project, or when the contraints of the chart constrain the management of the project.

The Gantt chart is not tied to a development methodology, so don't hold it responsible for shortcomings of those systems.

There's no single chart or report that meets all needs for software project management - FB would be improved with the addition of the Gantt chart to its toolbox.