Is the GANTT Chart Dead?

Projects usually require a schedule for people to understand the phases and inputs required to complete the overall task. GANTT charts were created by Henry Gannt, an engineer and social scientist around 1910. They have had a good run too, being used on projects such as the Hoover Dam.

Typically, a GANT/GANTT chart is mainly used in industries such as marketing, construction, manufacturing, HR, software development, event planning, banking, and management consultancy projects.

Since the GANNT/GANTT chart is very versatile and can be used in many contexts, it is an important asset to project managers, and was described in 1999 as one of the most widely used management tools for project scheduling and control.

GANTT (or also called GANT) Charts visualise schedules by using horizontal bars that last from the start date of a piece of work, until an end date. These outline each stage of a project, or bucket or work. All of these buckets of work are listed on the vertical axis of the chart. This helps workers to communicate the status of a project as well as the fact that the project will remain on track until the end date.

What a GANTT Chart can, and can’t do.

The GANNT/GANTT Chart is all about the ‘big picture’, meaning that the smaller details of each specific task only contribute to the GANTT/GANNT chart if it works within the context of the larger task itself. GANNT/GANTT charts show what resources for tasks needed at a which date.

By displaying the layout of a project, the GANNT/GANTT chart shows stakeholders a way to monitor progress. Identifying specific milestones that are achieved or should be achieved within a certain timeframe.

While the use of a GANNT/GANTT chart may provide valuable insight for the project at a strategic level before it is executed. it cannot provide any information on the difficulties that may be experienced when the project is carried out. Issues which may in turn impact the timing of other tasks.

People love a GANTT chart because of accountability.

Stakeholders and managers love them for this reason. It is a great way to hold out a bunch of tasks that should be done within a timeframe. It creates accountability easily because everything has a start and end date. Miss the end date, you miss the deadline. Sounds simple right?

At an individual level team member can easily process details of which task they are allocated to. The visual layout of the GANTT chart is more helpful for a team to quickly determine where a project is and where it should be at any one time.

Okay. So is all of this sounds great? Why is a GANTT chart dead?

The truth is, no matter how you run a project, a GANTT chart is probably going to be used in some form. Projects do need some form of GANNT chart or overview of how the project is going to unfold. However, in our experience, the classic approach to documenting even the minor level of activity in a GANTT chart simply isn’t the right way of using them. You could say that the classic approach to using a GANTT chart is dead. Not the actual use of them as a tool in general.

Projects are constantly evolving and moving. I have seen first-hand a two-year software implementation project (not one I was involved with running; I hasten to add) being run completely off a GANTT chart. When the project fell behind, and it did. The GANTT was the single source of the truth, right down to which business area was doing user testing on which day. A year in advance. You can imagine the level of fatigue within that business and frustration when the project kept getting delayed. It took just as long to update the GANTT chart and re-communicate as it did to correct the delays.

So where does a GANTT chart fit now and what alternatives are there?

The concept of a GANTT chart still holds out, but modern-day users really utilise it as a project roadmap. The roadmap outlines the various activities that are happening within the project, leaving the detail to be run by individual teams. In most projects there is an order of events, so this roadmap details that. Do not get caught up into the detail on a project roadmap. It should just be signposts to activities. Let the breakout groups determine the requirements. A project roadmap can support in determining sprints for example in an overall project, but we will get on to the use of AGILE another day.

So, when considering using some form of planner to determine your overall project, try and utilise it as a tool for determining the general direction as opposed to the nuts and bolts of activities. Set targets for activities to be finished sure. However, getting right down into the detail can, and invariably does, lead to people kicking themselves over elements that were not foreseen and scrambling to adjust. A laissez faire approach to the detail but focus on the outcomes and decentralised management of elements, can yield much stronger results.