Is It Time To Dump The Gantt Chart?

The most common project scheduling format is the Gantt Chart format.  It is easy to understand.  It is great for visualizing a project plan.  It clearly communicates what activities the project team should be working on each day of the project.  So what is the problem?  There are several.  The Gantt Chart relies on two demonstrably false assumptions with respect to development projects.  Added to that, once a Gantt Chart is in place, it often creates an environment of frustration, obfuscation, and team dysfunction.

Actually the correct title is the Bar Chart.  This chart is in the form of a calendar across the horizontal axis.  The project tasks are placed on the calendar with each task represented by a bar that begins on the task start date and ends on the task completion date.  The length of the bar then represents the length of the task.

Henry Gantt’s Chart

The chart became popular following the publication of a book, “Organizing for Work,” by Henry Gantt in 1919.  Gantt had worked for Fredrick Taylor before becoming an independent consultant and was an advocate of Taylor’s scientific management principles.  The Gantt Chart was developed for use in a manufacturing setting as a means to communicate to the factory supervisor what they should have the men working on next.

This leads to the inappropriate assumptions for a typical project application of the Gantt Chart.  The first assumption is that every activity that is in the project is identified and included on the chart.  This is a valid assumption for a manufacturing environment with defined process steps, well-defined tools and equipment, and the experience of having already done the activity numerous times.  The second assumption in the Gantt Chart is that the estimate for each activity is precisely accurate with little or no uncertainty.  Again, this was a valid assumption for a manufacturing operation that had embraced Taylor’s scientific management philosophy.  An operations manager would be measuring everything, collecting data, and monitoring performance.

Assumption #1: Every Task Is On The Gantt Chart

The assumption that every project task is on the Gantt Chart is invalid for most development projects.  Whether it is product development, system development, software development, or process development, the development environment is a discovery environment.  While experienced stakeholders and team members can forecast the likely chain of events there will inevitably be some activities that are discovered along the way.  These will not be in the Gantt Chart.

Further, a best practice touted by Cooperand Edgett is to use spiral development.  I have used the approach and I love it.  But it cannot be accurately represented on a Gantt Chart.  First, we don’t know how many spirals it will take to get the desired performance.  Even if we do guess right on the number of spirals, the activities in each spiral will change based upon the results of the test and analysis done on the previous spiral.  So the project management has two options.  He or she can guess what activities might be required in each spiral and probably guess some right and some wrong.  Or they just show the spiral with high level summary tasks that provide no useful information on what the team should actually be doing.

Assumption #2: Every Estimate Is Precisely Accurate

The second demonstrably false assumption is that every task duration estimate is precisely accurate.  The task will start precisely on the designated day and end precisely on the designated day.  This assumption is probably valid for some project tasks, but it is definitely not valid for many of the development tasks which have uncertainty embedded in them.  There is uncertainty with respect to the performance of the new technology.  Often there is uncertainty in the duration of the task because of the experience of new team members.  They must learn while doing, which depending upon their learning capacity and the level of instruction available to them, create more uncertainty in task duration. 

Add to this that many of the tasks are linked together either through task completion artifacts or project personnel availability.  As one task is delayed, it creates delays in other tasks and the impact can snowball through the project resulting in a Gantt Chart that is totally inaccurate.

Environment of Frustration, Denial, and Team Dysfunction

The impact of the two invalid assumptions is that a development project  Gantt Chart quickly becomes wrong.   The project manager may try to correct the chart but before he or she is able to incorporate the revisions and update the rest of the project management information, the Gantt Chart has changed again.  Eventually the project manager becomes so frustrated trying to keep it current that they just stop processing the day –to-day changes and wait to do a massive update at a major milestone or gate review.

But this now leads to a problem for team communication and progress reporting.  The team is tracking progress on a Gantt Chart that everyone knows is wrong.  Some of the team members will use the erroneous Gantt Chart as an excuse to ignore or avoid all project management activities and reports.  Others will try to twist what they are actually doing into the context of the erroneous Gantt Chart.  This leads to confusion and obfuscation of what is actually happening.

Finally the team ends up in a situation where the project manager is asking for status against a plan that the whole team knows is wrong.  This undermines the project manager’s credibility with the team.  Some team members refuse to even participate in a schedule status meeting.  They are now viewed as not being team players.  Others are twisting what they are doing into something to fit the erroneous Gantt Chart, but everyone knows that what they are reporting is not what they are doing.  Soon the other team members begin to suspect they may be lying about other aspects of the project.  By this time the team is totally dysfunctional.

The Alternative

So what should we do?  I recommend either switching to Milestone Charts and Network Diagrams or PERT Charts for large system development projects or using a Kanban chart with Milestone Reliease planning for smaller projects.   Milestone Charts can be used for tracking against calendar dates.  The Network Diagram or PERT Chart can be used for tracking activity sequence and monitoring  progress.  Kanban simplifies the project planning and tracking tasks for projects with low project management complexity.