What is the point of a Gantt Chart, and will it help me? [closed]

Question

My (non-technical) colleague has threatened me with a Gantt chart for a new project that we are currently planning. What is this likely to provide for us, and will it be a helpful tool?

Answer 1

As Wikipedia says it Gannt chart is a type of a bar chart (more often a "line type") that helps with project planning. It is often drawn manually on the wall on a big (really big) piece of paper, since it is easily modified in that format.

It is a very simple type of planning tool; you can produce it in Excel or some equivalent; and rather effective, as long as the time required for certain phases of project can be roughly estimated. If there is a delay - no problem - one line get lengtened, the others stay the same and you have a new end-of-project-date.
Overlapping phases (time-wise) are easily seen on it, as easily as dependencies of starting one phase relying on the end of another.

'tis all there is to it really.

Of course, the problem with the Gannt (or the "time chart" as it is usually called in my part of the world) is that, that at the beginning of a project you have it all drawn up nicely on the wall, feeling enthusiastic and happy, ... then one delay occurs, and you change it on the chart, and you're still felling happy ... then another delay occurs, you draw it up again, and you're still feeling pretty good ... 100x delays occur ... you're feeling like _______ (censored).

Meaning, it is only a good project planning tool if you're actually sticking to those little deadlines. So stop wasting time in here and get to work!

Answer 2

A well-produced and maintained Gantt chart can be a great tool. The main benefits are showing which tasks depend on other tasks, predicting how the project can be affected by delays, and highlighting wasted hours because you were waiting on something else.

Answer 3

I have successfully used Gantt charts in the past for software project management. I have also seen people abandon them in frustration.

Any project management tool is useful only if it's answering questions that somebody is actually asking. In my case, I was continually asked two questions, and my Gantt chart could answer it:

• My Manager: When will the software be in a shippable state?
• A Developer: I've finished the task you had assigned me. What task are you assigning me now?

So what factors are required for a Gantt chart to be useful?

Multiple team members

That should be obvious. If there's only one team member, then all you need is a list of tasks in one column. You're only going to do them one after another.

Knowledge of what the tasks are

This seems like another obvious statement, but you'd be surprised how many software projects are not well defined enough to be able to divided into tasks. You'll actually need an upfront specification, and some degree of upfront design. In some of the agile/extreme methodologies you couldn't use a Gantt chart, because you don't know what tasks will be in the subsequent 3-week iteration.

Time and Motivation to Maintain the Chart

Somebody HAS to put the time in to maintain the thing. Too often, somebody spends days making up a detailed Gantt chart, then neglects it. Maybe he'll get it out a month later, laugh nervously, and throw it away, never to talk about it again.

Once you have the tasks and best estimates, you put them on the chart. And when the first task has been completed, you have to mark that on the chart and then jiggle all of the other tasks around to compensate for the fact your estimate was wrong. And two days later you do it again. And then again, another two days later. And of course, when it turns out you forgot something or a defect appears, you have to put the new tasks on the chart.

That might sound like a significant ongoing time commitment, and you're right. Where does the motivation to do this come from?

Somebody actually cares about the results

The times that I have used a Gantt chart successfully was where there were weekly project management meetings. The manager would go around the room asking each team leader to state when their project would be delivered. If a project was running behind then resources would be reallocated. For the first two meetings I would stammer that I didn't really know when it would be delivered, and would come up with a vague "in three months". The embarrassment of this made me change my strategy, and make damn well sure I had a Gantt chart that was up-to-date and accurate before each meeting.

As a side effect, this made my project better organised and more efficient, and my team members more motivated.

Answer 4

No single invention deserves more credit for making project planning as unpopular as it is today than Tracking Gantts. Tracking Gantts should not only be considered harmful - they should be considered evil. Here's why.

Reason #1: Their motivation

Tracking Gantts let you see, for each step of your plan, how long you thought it's going to take and how long it's actually taking. You get to know, every day and in status meeting, that phase X was supposed to start by March, but it's clearly not going to get started until May. Awesome. You already knew, when you did initial planning, that the plan is going to have to change as the project progresses. New information comes to light. People and resources are unpredictable, etc. So why is it important to constantly be reminded, in every status meeting, how poorly your early predictions are fairing in real life?

Reason #2: They force you to stick to the original plan

The very idea of tracking a project's Gantt chart means that instead of focusing on constantly adapting your work plan based on new information, you choose to stick to an outdated plan, just because it lets you point fingers and highlight the mis-predictions that were the inevitable result of the huge amount of uncertainty that the early planning phase of the project entailed. After all, you can't track the Gantt if you allow the plan to change radically, right? It has to have the same general shape and be comprised of the same steps, otherwise there's nothing to track... Boneheaded sticking to plans is the number-one reason why "Waterfall" is actually considered a pejorative term these days. Planning ahead is confused with sticking to the original plan.

Reason #3: They teach you nothing

It's not like the delay in this project is actually going to change the way you plan the next project, unless the projects you're planning are predictably similar and repetitive. After all, that's what Gantts were initially used for - planning work in factory production lines, where tasks are very well defined and their duration is extremely predictable.

The value that tracking adds to a software development Gantt chart is zero. Arguably even less than zero. Not only are past estimations irrelevant for new projects, the illusion that you can actually improve your estimation ability over time by retrospection is dangerous. Sure, a CS student might really not know that integration takes lots of time in real life. But anyone that's been involved in more than two projects in their lifetime is already well aware of the usual suspects for delayed projects. The real reason projects are delayed is not some mathematical error factor that must be applied to estimations in general - it is the inherent uncertainty that comes with doing something for the first time and not knowing exactly how it's going to pan out.

There are actually project management systems out there that try to attack the problem from this misguided angle. They measure your predictions vs. actual performance and try to correct your overall estimation using statistical analysis. As if "Danny always underestimates everything by 14.3%" is ever the case. Danny isn't stupid, and to assume that the error of his predictions is predictable is indeed idiotic. It confuses the primitive "cure" - adding factors to your estimation - with the cause of the problem. Your estimation isn't inaccurate because it wasn't multiplied by the "correct" factor. Your plan is simply incomplete; and every plan is incomplete in its own way.

Reason #4: They focus your attention on the wrong things

Instead of being focused on what needs to get done to deliver on time, you're now focused on justifying your inaccurate predictions. Instead of focusing on planning in more detail and adapting your plan to new information, you're rehashing an outdated plan. Projects are seldom delayed because the work-plan's parts were incorrectly estimated. They're delayed because a crap-load of things were simply left out of the original plan. Tracking Gantts make this even worse, because what sort of motivation do you have to insert more detail into your plan if it's all just going to wind up highlighted as a poor estimations in every status meeting? They make you stick to large, track-able chunks of work in your Gantt chart. Instead of letting you focus on adaptation and getting on the right track, they make you reexamine irrelevant decisions that were made when less information was available.

There's also the problem of not having good enough tools to manage sufficiently elaborate plans. You have a much better chance at constructing a good initial plan (and estimation) if your tools allow you to expose all those frequently neglected steps along the way. Traditional Gantts are low-resolution beasts that are rightfully seen by developers as caricatures of the reality of project management. What's needed is a tool that makes it easy to add as much information as possible to the work plan at the earliest stage, and then make it just as easy to adapt your plan as the fog of uncertainty slowly fades away from over your project. The last thing you need is incessant low-resolution reminders of your inaccurate past predictions. Tracking Gantts are good for pointing fingers and covering asses, not for getting things done.

Answer 5

Gantt chart software allows complex inter dependencies to be analysed and to predict the effects of overruns and delays.

However, for most software projects, there are few inter dependencies and external inputs, so the key to prediction is knowing what the right multiplier to use when the software team say it will take 3 weeks.

Answer 6

As others have said a gantt chart (commonly informally referred to as a project plan) is a way of mapping tasks and the interdependencies between those tasks, the aim being to establish the minimum total elapsed time for a project.

From a management perspective the key output is the identification of the critical path, that is the list of tasks which if they are delayed then the project is delayed.

A very simple example - say two programmers are working on a project with three tasks (code module A taking one programmer 10 days, code module B taking one programmer 5 days, then integrate a and b taking both programmers 2 days). The first two tasks (coding modules A and B) will be worked on in parallel and the aim is to complete all three tasks and thus the project it all in 12 days.

In this case the critical path is coding module A then integration testing. The coding of module B can actually start 5 days late (or over run by five days) with no impact as even if it did finish on time, coding module A is going to take that much longer. On the other hand if coding module A or the integration testing slips by any time at all, the whole project will slip.

Knowing this sort of thing helps you understand how to deploy resources and whether a delay to a particular task is likely to impact the whole project.

Are they useful? Obviously yes, but with one significant caveat: only so long as the information that goes into them is good - that is:

• the task list is complete
• the estimates are accurate
• the dependencies between tasks are comprehensive and
• the resources representative of the team and correctly mapped to the task.

And from there the team has to work to the chart and carry out the tasks in the right order (no doing something that's more interesting that the assigned task as that will potentially delay something / someone else down the line).

If you do all that then yes, then it can really help you but the work does have to be put in up front to ensure it's accurate and realistic.

Answer 7

I LOVE Gantt charts and if there were better software choices for the Mac to create them, I'd use them all the time.

Getting to see the dependencies is huge. "If we don't get the data backfilling part of the project done, then construction on the whatsit enhancements can't start."

Answer 8

If your project is a software development project then a gantt chart won't be very helpful and will mostly be a waste of time. They aren't designed for the fluid nature of software development, ie.

• Tasks aren't usually order dependent. They can be done in any order.
• The order of the tasks can alter the time required to complete the task.
• Tasks can spawn other tasks, eg bugs

The upshot is you will spend more time updating the plan than doing the work.

Just manage your requirements and everything else will take care of itself.

YMMV