Last week, I gave an overview of Edward Tufte’s theory of graphical excellence: in short, that graphics should “give to the viewer the greatest number of ideas in the shortest time with the least ink in the smallest space.” We probably all agree that project charts should be graphically excellent — otherwise, they’re a pain to look at and a chore for stakeholders to understand. But what does Tufte have to say about graphical excellence as it applies to project charts in particular?
As it happens, Tufte has written extensively on his feelings about “project management graphics,” as he calls them, in a 161+-post thread on his website (linked at the bottom of this article). A few general principles can be distilled — we don’t agree with all of them (more on that next week), but they are nevertheless worth knowing about as a serious practitioner of project graphics.
- He hates most Gantt charts, aka project charts. About them, he writes, “The design of project charts appears to have regressed to Microsoft mediocrity: that is, nothing excellent and nothing completely useless.” Most project charts he sees on the Web are too simplistic, too spare, and too full of “chartjunk” (his term — see below). As an alternative, he recommends graphical timetables, such as this example below: the bullet train schedule in Japan, with time across the top and stations down the sides. I’m resisting the urge to editorialize here, since I will be critiquing Tufte next week. Until then, I present, without comment:
- If a Gantt chart must be created, he says, make it a wall chart, not a chart confined to a rectangle the size of your laptop screen or PowerPoint slide. “Computer screens are generally too small for an overview of big serious projects,” he writes. (We’ve debated the usefulness of wall charts on this blog: see a post agreeing with Tufte, and a dissent authored by yours truly.) At the heart of this argument is Tufte’s belief that project charts should convey complexity, not simplicity. He wants to see annotations, cost data, forward- and backward-looking schedule data, and so forth. That kind of detail just won’t fit on a screen, he says.
- At the same time, project charts must avoid chartjunk, or ink used not for the visual representation of data but rather the aesthetics of the chart. A big source of chartjunk is gridlines, which we talked about last week. Most project charts are better off with as few gridlines as possible, so the viewer can focus on the data rather than the grid.
Not all of the hundreds of posts on this project graphics thread were authored by Tufte. Dozens of project managers — and musicians, writers, and other people who care about project charts — have joined the thread (which started 13 years ago!) to weigh in on what makes project graphics excellent. A few ideas from the assembled commenters are worth highlighting:
- Swimlanes make project charts much easier to read. For example, if I have a project with resources Tom, Dick, and Harry, my chart could have three swimlanes, one for each of the tasks assigned to these three gents. See the example below.
- An alternative to cramming every piece of the schedule into one project chart (as Tufte advocates) is management by exception. Some project managers find it more effective to only emphasize tasks that are either behind schedule or over-budget. The project chart below does this — I made this in Microsoft Project and our own tool, OnePager Pro, by making tasks with the status “Late” 10 times taller than on-time tasks:
- Relatedly, audience matters. Some of your individual contributors probably do need to see every task of your 1,000-task project, but your executives certainly do not. Likewise, your engineers probably don’t need to see everything the marketing team is doing, and vice versa. Much frustration was expressed on the thread about walking the line between including enough detail for some audience members and avoiding excessive complexity for others. So the best tools for the job of creating project charts are those which can show a lot of detail to one audience and a high-level view to another.
So what do I make of all this, as someone who has looked at more project charts than I care to recall? I’ll turn a critical eye to Tufte and the other posters next week. In the meantime, here is a link to the full thread for you to read yourself.