Hating the Gantt Chart

"Can you get me a plan for doing that".  How often have people said that.  More often than not they are looking for some sort of Gantt Chart that shows a list of tasks, completion dates, and dependencies.  Gantt charts are very pretty…I’ve made plenty of them.

But they suck.  And they suck because they convey a level of certainty that is completely unfounded.  It’s pretty rare that we put a plan together where it turns out we actually understood:

  • What needed to be done
  • How long each task would take
  • What other distractions (vacation, crucial issues, etc.) would distract resources from full concentration on the project.

My hatred of Gantt charts stems from the way they make the schedule seem black and white.  So what I want is a way to create a project plan that shows the levels of gray in the timing.  So a task would not take 3 days, it would perhaps have the highest probability of being complete in 3 days, but there are non-zero probabilities that it would take 4, 5, 6 days to complete.  I’d also say that the more tasks in the project and the more resources involved the higher the likelihood of missing tasks, pushing out the schedule even more.

The closest I have found to this is FogBugz‘s Evidence Based Scheduling that shows a probability of a release shipping.  I like that it is based on data from developers, but I want to find a generalized way to represent this schedule outside of entering every task into Fogbugz. 

Maybe there’s a product development idea in here somewhere…

22 thoughts on “Hating the Gantt Chart


  1. Scrum, an Agile methodology, discusses this. Scrumworks, a tool that supports the Scrum methodology, has a burndown chart that sounds similar to the FogBugz feature you’ve described. (I use Scrumworks but do not work for Danube.)

    Going one level up, I would suggest that even if you find such a magical tool, i.e. something where you don’t have to enter and track every task but which still gives you a reliable estimate of velocity, and you get a “plan” that shows gray areas, then your bosses will hate it. No tool or chart can replace the hard work of educating your boss or manager about the difficulties of tracking velocity and estimating the difficulty of a set of tasks. Once you do that, I suspect you could present three Gantt charts, best/worst/average case, note probabilities, and they’d be happy.

    [ Apologies if this is all old news to your and/or your blog. 🙂 ]


  2. Burndown charts are a move in the right direction and can work very well. I do think they work better, but they still don’t really reflect the uncertainty in the estimates, they just effectively show what’s been accomplished and the estimate for the sprints.

    My fundamental issue is that we put too high a precision on estimates. An estimate for how long something should be take should be represented by a probability distribution not a number not unlike how you represent position for quantum particles.


  3. Really what you’re talking about is that there is no built-in safety factor to the time estimates. That is that there is zero-tolerance for a failure that impacts the time projects take. In most other engineering, the rule of thumb is to design for a safety factor of 2. However, design itself, is a batch process, rather than a continuous process, so there is always the push to reduce the safety factor.


  4. The golden rule of project management is that things will not go exactly as planned.
    Estimating tasks is a very challenging thing. The first thing to realize is that the duration of a task is different from the work hours it will take to complete the task.
    For example – a task might take 16 hours to complete, but it may take two weeks to complete those hours of work due to other projects, meetings, vacation, etc.
    This is where it is up to the resource to determine what they can commit to doing on a task. One of my clients will only schedule 6 hours of resource work on any given day because of the other things resources need to do.
    Many PM tools take this into account. MS Project allows the separation of work and duration on tasks.
    What we recommend is that an original estimate has both work hours and duration components. On each status update, there should be three components – how many hours have you performed on a given task, how many hours do you have left to complete the task, and how long will it take (duration) to complete the said hours? Over time the estimates will become more accurate.
    Another tool is PERT estimating – this takes into account optimistic estimate, pessimistic estimate and a most likely estimate. You can use MS Project to create three versions of your schedule, O-P-ML. Or you can use the PERT formula to take into account the PERT estimate which is O+P+(4xML)/6
    hope this helps!


  5. I totally agree with you. I’m a developer over at LiquidPlanner.com, and your observation is actually one of the core principles of our app. We figure that you never know exactly how long a task is going to take, so everything in LiquidPlanner is a ranged estimate.

    Take something like building email integration into an application. Well… you need to set up the server, that could be 1 to 2 days. Meanwhile your need to build your database schema for handling the new data, say 3 hours to a day, who knows it might be more complicated than you expect. Now you need to write the integration code, 1 day to 3 days, we want to make sure we have proper unit tests and all. At the end of that you need your tester to run over the whole thing, say 1 to 4 days, oh yeah and lets say 4 hours to 2 days of bug fixing based on what your tester finds. So yeah, when is that going to get done?

    When you get a lot of ranged estimates in a project, we do a probabilistic rollup and tell you when the earliest, latest, and the most likely completion date for a project. It’s really pretty neat, and I think it fits the real world a lot better than most gantt charts. Regardless, you might want to look up Steve McConnell’s book, and specifically ranged estimates.


  6. You really should look at critical chain project management (basics at http://en.wikipedia.org/wiki/Critical_chain). The basic idea is to get rid of bad multitasking and concentrate on one task at a time so that the next person can start and complete the task at the earliest time period.

    The tendency of people is to say, “well it will take 1 to 2 days, so I will take 2”. And then everyone does that, so that a project that should take X days really takes 2x days because the scheduling is so unreliable.

    Critical Chain would make estimates very tight, then allow buffers on the whole project instead of building it in to each element.


  7. Sure, if you or anyone else have any questions feel free to email me. My local-part is adam, the domain is liquidplanner.com


  8. This is a great post. As a former consultant who used to have to put together huge workplans and gannt charts, then “manage” them every week, I’m right there with you that this method is largely broken. Have you thought of using something like a prediction market to have people involved in the project AND outside the project “trade” in the probability of milestones being met? That way everyone has ANONYMOUS and quantitative input in to what they think about when will stuff get done and you get an accurate representation not just from the project manager who may be fed bullshit by people around them, but from the teams itself…


  9. Regarding PERT, it is not recommended because of :

    1) Merge Bias issues
    2) Overall under estimation of risk in the schedule

    You can read a quick, but accurate summary here: http://wiki.answers.com/Q/Are_there_any_drawback_to_using_PERT

    I would recommend moving to a probability method. Three point estimates are still good to use, but plug them into a program like Pert Master (disregard the PERT part), which can run a 10s of thousands of simulations based on a number of different distributions. Experimentation is key when using this approach , but this requires time and in my experience, most sponsors want the ‘quick and dirty’ Gantt and don’t care about its accuracy until the project is nearing disaster.

    Just my two cents.

    FYI- PERT Master is owned by Primavera now.


  10. i’ve worked on some critical chain projects and the theory is quite sound, but the projects are an utter b*tch to work on, especially larger ones. in essence, there’s nowhere to hide and if you are “holding the baton”, the stress can become unmanageable. if you work with people you like and, more importantly, trust, then it’s a great way to get things done quickly, but if there’s a lack of trust in the room, watch out.


  11. The main problem I see with Gantt charts is that people use them as a starting point for a project when they should actually come along fairly late in the scheduling process. In formal PM methodology, there are a lot of other steps that occur first (Work Breakdown Structures, Network Diagrams, etc.) that allow the work to be more fully understood before a baseline Gantt is developed. If someone just sits down in front of a blank MS Project/Primavera document to create a schedule without the appropriate planning, the resulting schedule will be hopelessly unrealistic.


  12. I see a Gnatt chart as less about showing the time individual tasks should take, and more about how changes in the schedule of tasks effect other tasks.

    It’s not about showing task A taking 3 days, it’s about showing that if task A is now going to take 5 days, this is going to effect task B,C,D,E,F in various ways.
    Eg. task A taking 2 extra days means that task B going in to fred’s vacation time, thus a 2 day delay in task A might mean a 10 day delay in the project.

    Gnatt charts should be updated constantly to show how a project is progressing.


  13. I think Steve and Jesse bring up a good point. A lot of times a gantt chart is just used up front to plan something, but then people assume everything will just roll along those lines.

    Of course everyone knows that the minute you print out a gantt chart, and tack it up on the wall like some kind of big game planning trophy, it’s almost guaranteed to be out of date.

    Things come up, I think that’s a really compelling reason to use something like LiquidPlanner, or other online collaborative planning apps. We really try to keep our plans up to date, so we always know where everyone stands. It makes it a lot easy to know who’s slipping, or who needs some help.


  14. Most scheduling is done using a deterministic (exact estimates for durations). There are several tools (I do not know of a web application) that use Monte Carlo simulation to create probabilistic schedules. Monte Carlo methods have been used for many decision tree based processes, including options pricing. So short answer, there are methods and tools to achieve the goal you are describing.

    In my experience the issue with CPM schedules and Gantt charts is that they are mis-applied. Project plans are just that, frankly know different than a business plan. Anyone who has been involved in the joy of starting a new company will tell you their first business plan was WRONG- but having it as a basis of measruement allowed them to identify risks and monitor progress and variance from plan. The problem with schedules as typically used is people are asked to justify missed dates and explain what are simply normal deviations from plans. Optimal value in scheduling comes from updating the schedule regularly and talking about your best estimate of the future NOT justifying what happened in the past. But good luck making a client or manager understand this.


  15. My experience with Gantt charts is that usually the crux lies in the planner, not the Gantt chart. Good planning involves taking all those things, such as vacations, overtime, weekends, and other resources into account. All of these things can be accounted for in the Gantt chart and in the Microsoft Project software. Unfortunately, no software package or scheduling format can replace a poor planner or a poor manager (a crux in the American corporate world these days).

    For this reason, Gantt charts are generally overused by management and have very little benefit for projects that can be planned in a simpler format. They are trendy and managers use them more because it is what everyone is familiar with, but few know how to put them to good use when planning projects and project phases. In the right context and the proper application, however, Gantt charts are invaluable.


  16. Gantt started life as a bit of creative misdirection.

    The original Gantt technique came out of the Polaris Missile Project. The project was throwing a lot of money around on a tight schedule in Cold War days. The project heads knew that Congress people would often meddle when lots of money was involved, sometimes out of a desire to ensure that taxpayer money was being well-spent. To protect a tight schedule, project heads needed a way to avoid any meddling. Out of that need, the Gantt technique with its chart was born. The idea was simple: Project enough of an air of scientific management and certainty, and Congress would go away happy. The Polaris Project itself didn’t use Gantt for real work.

    The Polaris Project was successful, and Gantt got undeserved credit. It was, after all, the scientific management technique that helped the a very large, very successful project succeed. Gantt was promptly picked up by consultants who needed a new technique to peddle. Adoption became a cycle of “we’re using it because they’re using it, and it’s scientific!”

    (Source: “Polaris System Development: Bureaucratic and Programmatic Success In Government”, Harvey M. Sapolsky, Harvard University Press, 1972).


  17. Rob if you have these feelings towards Gantt Charts then it is more likely that you do not know how to use them. First as
    Steve and Emily mentioned the planning step is very important. You do not dive into a Gantt without a prior good planning. Second a Gantt should be seen as a detailed plan only at a given moment of time. The rest of time it is only an approximation of the project evolution where all time related data (duration, dates, etc.) are almost meaningless.
    Third you can always use an optimistic and pessimistic estimate.


  18. Yes, Gantt charts are difficult to use with clients who do not understand them.

    That said…
    1) make a best case schedule
    2) copy best case schedule, change durations (maybe some logic, if concurrence is in question) now this is the worst case.
    3) Using ‘worst’ as Target, calculate against ‘best’ to see Total Float and Free Float by Activity.

    This has helped me illustrate the uncertainty in project work, and assign ownership to the stakeholders by using their durations. It won’t solve every problem, but hopefully this will be useful to someone.


  19. Just a comment on the Gannt chart being invented by the Polaris Missile Project by Dave Smith. Google “Henry Gannt,” and you will find in multiple places that he is credited with the invention/popularization of the Gannt chart, and that he died in 1919. The Polaris project may have used Gannt charts, but it was in use well before that time. Further, if Wikipedia is accurate, he also wrote two books and has a prize named in his honor.

    I currently use the very excellent open-source program GanntProject. It helps me to see what I need to do, so from a personal management perspective it is helpful for me. Also, in creating a chart it helps me think of what needs to be done, and clarify the project. Of course, when you have many people and many different tasks, I can see that the complexity would make it meaningless for accurate prediction of completion.

Comments are closed.