Project plans (part 1 of 3): Why I don't like Gantt charts

The first of three posts: this one sets the problem and the next two attempt a solution...

A friend e-mails to say that his team have almost finished their project plan. There is something about the words “project plan” which are like a red flag to this bull... while I’m prepared to admit I may over react sometimes I don’t think I’m completely crazy and I think I can put some logic behind my dislike of “project plans”.

Lets start by defining what I mean. Its not so much a “project plan” - after all I think planning is a great way to explore your problem. As a mental exercise a team planning what they are going to do is good. And I’m all for a bit of critical path analysis to work out what the dependencies are. And I think scenario planning is great. From what I’ve heard war-gaming is another good for of planning.

I should admit to an assumption. When this friend says “project plan” I’m immediately imagining Gantt charts and PERT diagrams. There are many other forms of plan which make a lot of sense. I think product road-mapping is an essential activity. Its specifically Gantt and PERT charts that make me see red - and as layman in the field I don’t see much difference between Gantt and PERT to be honest.

So what is it about Gantt charts? Here’s some:
• The charts are built on estimates and estimates are just that, estimates. They are not commitments, they are not fact, they are not enforceable. Therefore Gantt charts are not an accurate way to plan a project.
• The charts create illusion of control; here is a piece of paper which says the project will be done on 1 May 2010 - or whenever. It won’t. That date is the one date the project will not be ready. It might be ready before, more likely it will be ready after but that one date is fantasy.
• Many - too many - discussions now centre on “why are you deviating from the plan” - “why are the estimates wrong?” - “how can we get back on plan?” - arguments centre over the plan not the thing being produced.
• There is now work to do “correcting” the plan; updating it for what has happened and attempting to re-forecast. This makes work but does not add value.
• The charts are never accurate but they are treated as such.
• The “plan” is taken as a form of commitment.
• The further out the plan the more inaccurate it is: planning for next month is one thing but 5 years out? There is simply not enough information to do it accurately. Plus, things change too much, the further out you look the more things can (and will) change.

Basically, what I’m driving at is: once the plan is in place disucssion moves from what is important (what are we building? when do we need it by?) to the plan. Its goal deferment.

There is a lot more I could say here but I’d be repeating myself. If you are interested read An alternative view of design (and planning) and the section in Changing Software Development.

Fortunately I showed this to my friend and he says they’ve not drawn a Gantt chart, phew! But before he tries I need to give some advice, the next two post will try and do that.

• Project plans (part 1 of 3): Why I don't like Gantt charts
• Project plans (part 2 of 3): Turn the question around
• Project plans (part 3 of 3) - Planning cycles
• Run Scope Creep backwards