For the last two weeks, we’ve been exploring the ideas of data visualization expert Edward Tufte and applying them to project charts, aka Gantt charts. Two weeks ago I introduced Tufte’s theory of graphical excellence; last week, I discussed what Tufte has to say about project charts. This week, I’ll discuss what I have to say about Tufte.

He is, of course, a smart fellow, and has done project managers a tremendous service by coming up with an academic theory with applications to project graphics — the kind of task few of us have time to do (most days, I barely get through my e-mail). I think he’s absolutely right about maximizing data-ink and minimizing chart-junk. In other words, a good project chart has only the graphics it needs to tell the story of the project, and nothing else (no extraneous gridlines, colors, shading, etc.). He’s also a fan of horizontal swimlanes to organize project tasks visually, and so am I:

Where Tufte and I part company is on the value of simplicity. As we saw last week, one of Tufte’s principal objections to Gantt charts is that they are too simplistic. He really likes charts to show complexity — just think of the train schedule from last week’s post, or the project chart above (notice it’s just one of 8 panels meant to be mounted on somebody’s wall!).

Unlike Tufte, I happen to think simplicity of communication has an important role in project management. I’m sure many of the Japanese train engineers learned to make great use of that schedule, but to the uninitiated it is just a puzzling line drawing. Likewise, the chart above is beautiful to look at, but if I was the “Vice President/General Manager” of that company and someone put it in front of me, I would probably go ballistic.

“What’s the story here?” I would snap. “What’s ahead of schedule? What’s behind? What’s an overall percent-complete of this project that I can take to my manager?” Any of this sound familiar?

The point is, as I said last week, audience matters. In most cases, executives at large organizations only need and only want to see high-level details of a project:

Whereas individual contributors — engineers, scientists, testers, and so forth — need to see more detail, but probably only the detail that is relevant to their workstream:

Maybe somebody (besides you) should have to look at the whole gory plan, or maybe it should be trotted out in a quarterly meeting so people get a sense of, quite literally, the bigger picture. But the idea of visualizing the whole project plan for everyone at every meeting is, in my view, a waste of everyone’s time. It’s also a waste of your time, since there are software tools that make it easy to show different versions of your project plan to different audiences.

Another objection I have to Tufte’s theory, and its application to project charts, is that he seems to hate Gantt charts for their conformity. Gantt charts have, he said, “regressed to Microsoft mediocrity.” That could mean a lot of things, but one thing he says it means is that they all kind of look the same. They all have time along the top, and tasks/resources down the side.

Sure, but what’s the problem with that? The reality is, the average worker changes jobs 12 times in her career (and for millennials that number will probably be closer to 20). It is perfectly understandable that in many industries, project charts have an agreed-upon format. Otherwise, the new guy or gal doesn’t know what he or she is looking at. How’d you like to be a Japanese train engineer in your first day on the job, and get a chart like the one we saw last week? I would need to go find a secluded conference room to cry.

Like all theories, Tufte’s is imperfect, but better than what we had before (which as far as I can tell was nothing). He’s right that project charts should communicate clearly, without clutter; he’s wrong, in my view, that all project charts should be both complex and uniquely formatted. But that’s just my opinion. What is yours?

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.