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?
I agree with you. I have heard Tufte speak and have three of his books. I am glad that someone has thought about data visualization excellence but I believe that he is off-base on some of his ideas. Standard Gantt chart formats are great because they allow us to focus on content and not on trying to orient ourselves to ever-changing formats.
Simplicity, consistency and adaptability is key these days. With much of our work force working cross-functionally and globally, it is important for all team members to be able to interpret key messages from visuals quickly and consistently. Most projects are very dynamic nowadays (at least in Biotech), so the simplicity in templates allow complex data sets to be digested and/or adjusted quickly, while still an maintaining a visual output for quick and consistent interpretation.
Another angle on this is analysis vs. reporting. Tufte’s desire for lots of data in one place makes complete sense when you’re trying to analyze the data…recognizing something that you may not otherwise have noticed without looking at everything in one place. However, when the purpose of the communication is to report, a wall chart is ludicrous. When you are communicating upward, generally you are “reporting” and in that case a clear, concise, distilled view of your data/plan is the obvious tool.
Your comments on management requirements align perfectly with my experience. The statement “What is the story here” particularly resonates as I have literally been asked that exact question by an executive on a regular basis.
However, I do agree with Tufte with his disdain for the Gannt chart. I dislike it for a slight variation on what is presented however.
As you state a project is both maddeningly complicated yet it’s status is often simple. I find a Gannt chart does not adequately express the complexities of the project without frustrating the reader. At the same time, the format does not easily lend itself to simplifying a project into a concise story either. For me is sits in purgatory, succeeding at neither conveying complexity, nor effectively summarizing the the project.
This is where I am excited about the approach OnePager is taking. Separating the communication element of the project from the actual data madel maintained in the project schedule is a powerful way of taking back communications from the de-facto tools project management has accepted en-mass.
I am incorporating this approach into my project communications as I move forward.