Projects Are About Humans. We Help You Deal With That.

A Gantt chart groups human resources with specific tasks. Further, it allows the project manager to identify dependencies between tasks, laying out the entire project in a timeline fashion. People championing the Gantt chart will tell you that it can be difficult or impossible for the project manager to correctly identify the critical path without one. They say it can help a project manager decide which employees to put on which teams.

Photography by JCardinal.

Many people voice the concern that the format of the Gantt chart is too limiting. Edward Tufte notes how most Gantt charts for larger projects can easily turn into grid prisons, where important data is easily lost in a sea of sparse task descriptions. No real actionable To-Do lists. No substance. Just a grid prison that does more to demotivate a team than inspire it.

That’s not the kind of information you want your team to be staring at from day-to-day. That’s not in your face information! We live in a time where development teams use Continuous Integration systems to communicate Build Status Using Lava Lamps.

There are two main problems I have with the Gantt chart. Mainly, it assumes that details of the project (at some level) are known from start to finish. It also has the annoying side effect of requiring a project manager to sit and attempt to piece together this plan — usually before any real details about the project are known. This leads to an incomplete plan driving an inadequate development process.

The real problem with the Gantt chart is that it’s so married to the Waterfall development methodology of yesteryear. The practice of software engineering has evolved. Agile development calls for agile project management, and Gantt isn’t it. Adopters of Agile processes realize that the details of the project are not known from the start. They embrace the fact.

Part of the beauty of this methodology is its flexibility. Where Waterfall locks you in, Agile sets you free. The development roadmap can change rapidly from day to day with customer feedback.

You start to see new processes replacing old ones. In the case of the Gantt chart’s ability to assist the project manager with estimating a project schedule, one notable practice is Planning Poker. Where developers on the team estimate how long it would take them to complete a project by writing the ETA on the back of a card, then everyone compares cards, and drastic differences are talked out.

In other industries outside of software development, perhaps the development pipeline is so rigid that the full scope of the project from beginning to end is obvious. In those types of projects, the Gantt chart has much utility.

In Don’t Give Up on Gantt Charts the argument is made that ultimately Gantt charts are a useful tool to communicate. A person can pick up a Gantt chart and come away with some level of understanding of the project status without any need for specialized training. Surely this is the case.

Tufte presents a design for a project management interface that addresses some of the problems with rendering large Gantt Charts. He advocates splitting the chart into two views. At the top of the chart, you see the project timeline laid out in phases, with the current phase denoted with a unique color. On the bottom half of the chart, the local view basically zooms in on the current phase to display more detail. The cells of the grid are thought to be too distracting and are removed completely. Details such as cost and itemized to-do lists can be added to the local view.

As the practice of project management continues to evolve with new technology, new systems replace existing ones. The Gantt chart must also evolve. If the Gantt chart has a place in modern software engineering, it is more likely to serve as just one potential view of a project’s status rather than a central repository for information on tasks and resources.