When I first started managing a small software team, I was expected to use MS Project and its Gantt charts as the primary means of planning the team’s work. For a while now, I’ve believed that this is a terrible idea. Today I’m just going to focus on why I don’t like the Gantt chart itself.
For starters, it’s a gigantic waste of space. Suppose for the sake of argument that I’m managing a team of 5 engineers, that a typical task (in terms of the planning granularity) takes them about 2-3 days, and I want to look at their next month’s work. Here’s what I get in Gantt form:
It’s an unbelievably bad use of the space on the page, from the point of view of density of information. Nearly the entire chart is blank, information-less space. If the project grows much at all, this turns into a crippling problem, where you can’t see what’s going on without lots of scrolling. It seems obvious that the same information would be better displayed with a row per person, not per task:
Now you can see a fair bit of work at a glance. You can fit at least 10 people on the screen in this view, and you can make full use of the time axis for each person – unlike the Gantt chart, where looking further into the future uses up more vertical space and reduces the number of people that can be visualised. I was initially very disappointed that Project didn’t support this view and allow reordering and reassigning tasks with simple drag and drop operations (maybe it’s because of it’s super-general resource data model which means it can’t just view a resource as a person that does a list of tasks in order?)
The second problem with the Gantt chart is more subtle, and applies to the “swim-lane” chart too. The question is whether plotting the underlying information is a good thing to do in the first place. A couple of comments on this (incredibly long) Edward Tufte forum thread are worth pulling out.
Firstly, the misleading sense of accuracy they give:
One thing that always fascinates me about these process diagrams is that they reflect a rather poignant human desire to predict the future, to capture the chaos of the unknown and render it in a coherent, logical framework as way to assuage fear. In this way they are almost more talismanic than practical. Unlike statistical charts, they try to project what might be as opposed to what has already transpired.
Looking at a schedule, it’s tempting to be tricked into thinking that the future will play out according to this nice plan. The Gantt chart does not begin to show the consequences of a task slipping, work being completed out of order, an employee being off sick, or new requirements being added. All of these things will happen on a normal project.
Secondly, there’s the unhelpful notion that it’s useful for one central person to map out exactly what everyone does, in what order:
Many problems in project management (PM), including PM graphics, are the result of blending — and thereby confusing — planned outcomes with planned actions. Planned outcomes are the desired ends, including interim results expected along the way. The purpose of defining planned outcomes is to provide direction, stability and control. Planned actions are far more chaotic and more detailed, but they are the only way to provide forward motion. Planned outcomes are the best way to describe and organize project scope and they can remain relatively unchanged. Outcomes are the rudder and actions are the oars. Blending outcomes and actions is an error that causes miscommunication — the most common cause of project failure.
[Garry L. Booker]
It’s very hard for a project manager to plan out all the actions involved. Personally, I think they’re much better off focussing on outcomes, on higher-level views, and leaving the low-level stuff to be done in an organic, distributed, bottom-up fashion. There’s simply no way one person can know all the details of the project and their interactions. That’s why as a programmer I always used to hate those conversations with my producer where he was “updating my schedule”:
Producer: “How much time have you spent on ‘AI behaviour second pass’?”
Me: “Could you be more specific about what that means?”
Producer: “It’s what’s written in your schedule!”
Me (thinking): “It’s only there because you mangle, mis-spell, and randomly re-interpret what I tell you I’ll do, which is itself simplified and dumbed-down for your sake”
Me (aloud): “I’ve been adding a representation of an NPC’s perception of world state. It means the AI can be fooled, surprised and disappointed.”
Producer: “Shall I just say the second pass is complete?”
Me (thinking): “Whatever keeps you happy”
Me (aloud): “Why don’t we just delete it and create some tasks that describe what I’m actually working on?”
Producer: “We can’t delete it, it’s part of the milestone!”
Next time, I’ll get more into talking about some things I like.