In my experience, there are some projects where using Gantt can be useful, but there are others where a Gantt becomes only a burden. What features of projects should I consider (beyond the basis of my own experience) to determine when Gantt diagrams are not useful?
I have considered the following:
...when the consumers of the report or graphic find it not useful....
I do not mean to be trite but we tend to forget that a report or table or graph is for the benefit of the consumers of that data, not the benefit of the producers of that data. Instead of trying to understand when to use Gantt chart, or any other type of tool, by way of type of project or method or industry, we should understand based on what the consumers of this report need to understand and make decisions.
One factor, on which the likely utility of Gantt could be predicted, is the length of time over which work is planned. The longer the period of time over which work is planned ahead, the more useful a Gantt diagram is likely to be. (Of course, one doesn't usually assess something based on a single factor, so this might seem simplistic.)
Consider, for example, a two-week Scrum sprint. While you do maintain a prioritized product backlog (all of which will take a longer time), you only plan the actual work one sprint at a time. To me Gantt diagrams would not seem as useful with Scrum as with waterfall. (This is not an absolute, but rather a relative, thing.)
Consider the project phase prior to choosing a Gantt chart as a primary project management tool. Gantt Charts are of limited value during project planning. Gantt Charts are intended to be used as status reports and communication tools (see this Wikipedia page and click through to reference item six, "The Gantt chart, a working tool of management").
When planning a project, it is appropriate to use either an activity-on-arrow or activity-on-node network diagram in conjunction with a set of resource availability plans. Since Microsoft Project defaults to the Gantt chart view, many people make the mistake of using that view for project planning. Microsoft Project also makes an activity-on-node view available and that view is useful for planning. The network diagram should be used in conjunction with resource information sheets for each of the project's critical resources in order to stagger work based on both logical sequence and resource availability.
What Gantt charts do well is they highlight dependencies. This is particularly useful when there are many parties involved in a development and there is a lot of intergration work to be done.
What they do badly is adapt to continuous change. The agile approach is to do a bit of work, get feedback and then adapt. A Gantt chart would need to be continually updated to keep up with this approach, which would be a challenge.
There is also the problem of how Gantt charts are interpreted. It can be tempting to view a Gantt chart as a prediction of the course of events on a project. This can lead to people making assumptions based on the chart and also treating milestones as deadlines rather than target dates.
Gantt charts don't work well if there is not a commitment (and the commensurate time to meet that commitment) to maintain it - often daily. However, that's not the fault of the technique - that's a resourcing/bandwidth issue. But if there's not a commitment to build a good plan and continually refine it, there's no sense it wasting any amount of time building a half-baked one that will quickly become useless for decision making.
Speaking from an IT perspective, what they do very well is provide an excellent management and communication tool for large, long-running projects - esp. those with significant non-development-related aspects that have "real world" implications. While software development may be undertaken in an agile manner, things like hardware purchases, marketing campaigns, installation/deployment resource contracting, compliance deadlines, and the like often cannot. And a Gantt chart provides a way to effectively understand how those interact with one another and the ramifications when something is falling behind.
Gantts tend to be useful when the audience reading the Gantt is more interested in tasks and dependencies than outcomes. Most of the space on a Gantt chart is taken up by the tasks whereas only a small amount of space is used for outcomes (milestones).
In knowledge work, research, creative, operational support and software development work for example, the tasks and milestones may be very dynamic, technical and unpredictable, so a Gantt chart can be quite misleading to many stakeholders.
Gantts don't show effort, cost, risk or measure success of a piece of work but they are an attractive visual that can sometimes distract attention from those things.
I think gantt chart is no longer readable beyond 15 tasks. That was why I transpose the chart, i.e. make vertical axis as time axis. It makes the chart more compact and readable. Much less horizontal scrolling needed.
I would also add that Gantt charts are NOT useful if you have little idea how the project may progress, which is particularly true for pure research projects, PhDs etc. Often the team may be small anyway which would also further limit usefulness of Gantt chart. If you are forced to use Gantt chart by your manager/supervisor then you will end up updating the chart quite often, moving milestones etc., having unrealistic timescales etc. I would add that in this case, even if the Gantt chart would not be useful for managing day-to-day tasks in the project it still may be a helpful exercise in the planning stage as it forces you to outline the steps needed for the project to complete, or if you have any hard deadlines, limited resources such as lab space, equipment booked on specific dates etc.
