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.

In our line of work, we see a lot of project charts. We get them from customers, from potential customers, and yes, we make our own. Some look fantastic and tell stakeholders the story of a project. Others, unfortunately, fall short of their potential — unfortunate because million-dollar decisions can be made on the basis of these charts, and if they aren’t communicating effectively, those decisions may not be the right ones. Consider the infamous remark of General Stanley McChrystal when he saw the chart below on a PowerPoint slide: “When we understand that slide, we’ll have won the war.”

What makes an effective project chart? What makes a mediocre one? Of course there are many factors, but one of those most often overlooked is the chart-maker’s adherence to the theoretical principles of data visualization. Yes, they exist, and in this three-part series we’ll explore them.

Even though many project managers feel that making charts is a slapdash task, there really is both an art and a science to visualizing project data. A master of both the art and the science is Edward Tufte, Emeritus Professor of Political Science, Statistics, and Computer Science at Yale University, and exhibitor at the ET Modern gallery in Manhattan. Since 1983, Tufte has written six major books and dozens of articles in search of the principle of graphical excellence.

“Graphical excellence,” Tufte wrote, “is that which gives to the viewer the greatest number of ideas in the shortest time with the least ink in the smallest space.” Central to this principle is the concept of the data-ink ratio. Let’s say you have a 500 x 800  project chart, which means it has 400,000 pixels. Perhaps 320,000 pixels are related to the display of start dates, finish dates, baselines, percent complete, etc. — the actual project data you are trying to communicate to your audience in visual form. Another 80,000 pixels are related to borders, gridlines, background colors, legal disclaimers, and so-forth — stuff not related to your data, but that has to be there for your audience to look at your screen and say, “Oh, OK, it’s a chart.” That gives your chart a data-ink ratio of 0.8 (pretty good). A graphically excellent chart has the highest data-ink ratio possible.

Let’s look at an example. Below, we start with a chart that has a lot of gridlines. The chart is technically readable, but there are a lot of lines competing with the data for the viewer’s attention.

Notice, also, the repetition of the Category datum — it is used both as the row label and as the color in the legend. Sorting and color are two separate pieces of visual information, so there’s no reason they should be telling the viewer the exact same thing. Instead, in the revised version, we’ll remove the row labels (keeping the legend), while suppressing gridlines:

To the naked eye, this chart just “looks better.” But Tufte’s theory tells us there’s more to it than that. We’ve cut out non-data-related ink (also known as chartjunk), thereby increasing the data-ink ratio of the chart.

We don’t agree with Tufte on everything — in previous blog posts, we’ve clashed with him over whether legends are valuable, and over whether wall charts are useful project management tools. Nevertheless, Tufte is the undisputed giant in data visualization theory, and no good chart creator should be ignorant of his ideas.

Next week, we’ll explore what Tufte has to say about project charts, also known as Gantt charts, specifically. The following week, we’ll put on our critic hats and sketch out in a little more detail where we think Tufte is wrong.  In the meantime, if you want to learn more about Tufte’s ideas on your own, here’s a link to his website.