What are the benefits of using Gantt charts during the execution phase of a project?

Question

After a decade of managing software projects, I've found Gantt charts to have very limited use after the Planning phase.

What are the perceived benefits of Gantt charts, especially during the Execution phase?

Answer 1

In order to answer your question properly, I had to interview a lot of people, but I'm going to guess instead, because I cannot do it now. I think people love Gantt charts, because they give them a clear view on what is going to happen to them and when. The problem is that they take the chart as something written into stone. The inventor of the Gantt chart (Henry Laurence Gantt) created the tool for visualizing the current status/schedule and show the progress. This was a revolutionary concept at that time.

As usual, there's nothing wrong with the tool, it is the way we use them. If you make sure that the Gantt chart is used and updated as it was designed you'll get a pretty good overview on what is going on in the project. If you don't update it, or set it up having wishful thinking then it will do harm. Again, charts usually don't set themselves up :-)

Answer 2

Gantt charts have value in the execution phase if the work breakdown structure tasks are being updated as things are completed, delayed, or adjusted. The effects of schedule slip and the identification of tasks that were over or under-estimated can be really obvious when shown in a Gantt view.

If you were to ask this exact same question to someone in the construction industry, you are likely get some very odd looks from managers who would question your sanity. Updating and tracking of construction projects using just a Gantt chart is extremely common. Since deliveries to to construction site have to carefully timed and renting certain types of equipment are extremely expensive, a construction site manager wants to see real data on how complete the predecessor steps are.

The trick is keeping the history of the task completion up to date. In my experience in IT companies, the Gantt chart is built and then discarded which greatly reduces the value of the tool. And, unfortunately, few time tracking systems or issue tracking/ticketing systems feed directly into planning tools that people use to generate Gantt charts so that "real time" link is often missing.

Answer 3

The value depends on how the Gantt is being used and maintained. The perception of limited value is usually due to a poor implementation, and lack of proper usage.

The Gantt Chart is intended to be a visual representation of the project schedule. It gives you (and your team) a quick way to see how things are interrelated, how they are sequenced, dependencies, proposed dates, and ultimately, progress.

The problem comes when it's not updated regularly to reflect actual progress. You said the chart is useful in planning, but no plan ever survives actual implementation. As soon as you start the project things change. Unless you update the chart to reflect that reality, it will have no value after that first day.

As SBWorks said, the construction industry lives and dies by the Gantt Chart, but in that domain those using it update it on a regular basis. In most const contracts, the sub-contractors are even required (as a condition of progress payment) to provide an updated schedule every month, which is reviewed and integrated into the master schedule.

So what are the benefits? There are many. But only if used correctly.

Answer 4

We synthesize and display data in order to analyze it and to report it. We do not create the Gantt chart so we have a cool looking thing. We do so in order to help us understand what is going on with our schedule, draw findings and conclusions, and then make decisions. Not only with our schedule, but we have those same choices for other data we are analyzing and reporting. We can build tables or graphs and modify them in countless way to help us analyze it and report it. We can make trend graphs using lines or bars, we can make histograms, pie charts, scatter grams, Paretto charts, and we can design our tables any way we want, and we can build dashboards with red, yellow, and green fancy indicators. The point is, we synthesize and display so we can analyze. Most, I find, stop at the display part, which is what it sounds like you are doing.

The schedule by itself is a table and you can expose the data attributes of interest to you and arrive at the same conclusion as if you were looking at your tracking gantt, viewing pictorally your actual progress against baseline. So, it is a choice of the PM and how (s)he interprets data and how (s)he best thinks (s)he can report it for easy understanding with key stakeholders.

Personally, I like pictures and graphs. I find them easier to intepret and far easier to report. I can see the inter- and intra-relationships between the work packages--the horizontal and vertical logic-- throughout the schedule whereas with the table I'd have to line by line see the relationships. Much easier to look at a connector. And, if I want to make changes in the schedule, e.g., fast track or crash, I can almost visually see what that would do the schedule in my mind, versus plugging in the new datum and watch the values change in the table cells to see what happened to my new finish variance.

Answer 5

I'd say from my personal experience that Gantt charts quickly become useless if they contain too much detail. While it's OK to have a Gantt chart showing individual tasks up to, say, 16 man-hrs for a 4 week-long iteration, doing the same on a chart at the yearly scale would simply render the chart unreadable.

So my advice would be: always maintain a proper scale! If you track the progress of a whole large project, it probably makes sense to do so at the work package level. If you track a progress of a 3-month long release, it probably makes sense to do so at the feature / use case level and so on.

Answer 6

From having seen Gantt charts being used in various environments (such as project management, production scheduling, service management and logistics scheduling), I would say that there are two prerequisites for a Gantt chart to provide value in the execution phase. One had been mentioned earlier in this thread: the Gantt chart has to get updated regularly. Second, I would suggest that these updates happen in an interactive way so that all task owners of a project can interactively communicate with the schedule data, simulate them and change them so that execution and scheduling (which to me is the day-to-day granular planning) go hand in hand.

If this is achieved, I can see the following benefits of using a Gantt chart in the execution phase:

1. Intuitive: Jump-start for everybody.
2. Clarity: eases manager/employee communication.
3. Reducing a burden: making reporting straight-forward.
4. Increasing efficiency: documenting best practices.
5. Providing insight: making dependencies transparent.
6. Management relief: closing the “excuse department”.
7. Cutting a Gordian knot: from detail to high-level and back.

I recently elaborated these in my Gantt software blog and I hope that this provides some new food for thought: http://blog.netronic.com/8-fundamental-reasons-gantt-chart-scheduling

Answer 7

I agree with some of the other benefits listed. One additional one is to analyze the effect of changes. Many projects experience scope changes (for example, "we need to include this other feature into this software release"). That should entail another planning step which, if you are using Gantt charts, should result in an updated Gantt chart. This helps to see the impact of the change to the original project schedule.

Answer 8

There are many Gantt Chart views: 1、Gantt chart shows the dependency relationship between tasks 2、multiple baseline Gantt shows the variance between the baseline and current plan. 3、Tracking Gantt shows progress etc