When reading the Edward Tufte forum on Project Management Graphics I was surprised (and relieved) that a lot of people seem to have their problems with Gantt charts and their doubtful usefulness for project management.
After some thoughts on the topic I’d like to present my proposal for visualization of project flows. In case it matters: I’m currently part of a half a billion Euro construction project in Austria.
The real world example
The image below shows one Gantt chart of the project I’m currently involved in.
Aside from its professional look it transports surprisingly little content. My main points of criticism are:
- On the one hand, with more than a hundred tasks on the left I get overwhelmed by things I’m not responsible for anyway.
- On the other, my 15 tasks lack important detail.
- Since it’s not possible to combine overview with sub-project specific detail I have to manage my tasks in parallel.
- I easily lose track between tasks and the bars on the far right. Gridlines would be a bad idea as well since they add too much clutter.
- Data is sparse and the chart needs too much space for the presentation thereof.
- In my context of software development the chart’s implicit focus on sequential, waterfall-like project flows does not fit my reality of ever-changing project plans.
- I definitely need to print it out to be able to use it.
What would I need?
First of all: Everybody can read a Gantt chart so let’s stick to some reasonable habits: bars that encode project duration by length and diamond symbols that mean milestones, i.e. important dates.
When I think of project management, the whole story is about one core task: Align your output and handover dates with those of others.
As a member of any project team I simply cannot be interested in the task of each individual. However the Gantt chart’s focus lies on the presentation of single tasks. I state that any visualization for project management should focus on people or teams, i.e. responsibilities, rather than tasks.
My second point revolves around overview and detail: My own tasks should be presented in greater detail than data of other teams. My only concern with them is deliverables when we approach mutual handover dates.
The Redesign
Here’s some example data taken from one of my schedules:
| Responsible | Task | Start | End |
|---|---|---|---|
| Construction | Define location | Sun Jan 01 2012 | Sun Apr 15 2012 |
| Construction | Finish site | Thu Aug 01 2013 | Milestone |
| IT | Develop prototype | Sun Jan 15 2012 | Sat Jun 02 2012 |
| IT | Testing | Sun Jun 03 2012 | Sun Jul 01 2012 |
| Business Process | Give feedback | Sun Jun 03 2012 | Sun Jul 01 2012 |
| Supplier | Deliver parts (prototype) | Thu Mar 01 2012 | Sun Aug 05 2012 |
| IT | Update integration | Sun Jul 01 2012 | Tue Aug 14 2012 |
| IT | Evaluate prototype (hands-on) | Wed Aug 15 2012 | Mon Oct 01 2012 |
| IT | Evaluate prototype (remote monitoring) | Tue Oct 02 2012 | Wed May 01 2013 |
| IT | Production | Mon Aug 19 2013 | Wed Jan 01 2014 |
| Business Process | Launch prototype environment | Wed Aug 15 2012 | Milestone |
| Business Process | Go live | Mon Aug 19 2013 | Milestone |
| Procurement | Procure | Mon Apr 01 2013 | Wed May 01 2013 |
| Supplier | Deliver parts (production) | Wed May 01 2013 | Mon Aug 12 2013 |
Classic Gantt chart
And here goes the corresponding Gantt chart:
My version, aka: Gantt90
My enhanced version is shown below. Instead of single tasks I only show the responsible team. Additionally I rotate by 90 degrees – thus Gantt90 – to shift the attention from process flow to responsibility, from a mechanical point of view to a more social one if you want to put it like this.
While the information conveyed is almost equal, the charts size is halved. Hence even the thumbnail becomes readable.
Adding detail
Since I’m a member of IT, the two blue bars on the right should now convey more information than the others. I do that by highlighting my team and showing the specific tasks along the time axis. Enough detail for the team, and I manage to simultaneously keep track of other teams’ schedules.

Overview and detail combined. The chart could even be made recursive with sub-teams of IT on the right. (…)
Thinking of my big example from the beginning it will be necessary to further divide the detail view on the right. Since projects – tasks as well as teams responsible – fit into hierarchical, tree-like data structures my chart would recursively expand to the right. (IT would then be divided into developers, testers, administrators, etc. and the new chart would resemble its left neighbour – both aligned with the common time axis.)
What about connecting lines?
You may have noticed that I skipped the connecting lines between the taks. I’m convinced that a proper visualization should signalize the project’s inherent structure on its own. Even if the lines are not there, you can see the dependencies between tasks and/or milestones anyway. Your brain does quite a good job at pattern recognition.
tldr: Like spreadsheets, Gantt charts are used to visualize business fiction rather than to manage projects. I’ve proposed a modified Gantt chart to better visualize projects by drawing attention to responsibility rather to single tasks.
Thanks to Elena Reitman’s tweet I stumbled upon the Tufte forum.
Great thread on Gantt charts and project plan visualizations from the @edwardtufte forums bit.ly/ZLx10F #projectmanagement
— Elena Reitman (@ereit) 10. Mai 2013
I highly recommend the book Envisioning information by Edward Tufte. The charts and the source code used can be found here.









































About