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:
Tufte’s sketch of a “project management interface,” aka project chart. The entire chart is 8 panels (shown in tiny insets at the top), and the first panel is blown up to show detail. From http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=000076
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?
