Anyone who has done PM work is familiar with a Gantt chart. It is a wonderful combination of text and graphics that lets us see dependencies, durations and start and stop dates. It is a very useful tool for planning and tracking your project – but it has a dark side as well.
First conceived in 1896 by Karol Adamiecki but first popularized by Henry Gantt around 1915, the chart was a labor intensive means of visualizing the flow of a project and the relationships between tasks and milestones. Every time a change was made in any aspect of the schedule, the whole chart would need to be manually re-drawn. Not until the advent of software to take care of updating and changing the chart did the Gantt chart become widely used.
The software I have used often to plan the execution of projects over the years is MS Project. There are other software tools just as capable but my experience has been limited to MS Project. I don’t believe this will invalidate any of the ideas I will be expressing in this post since it addresses the perceptions surrounding Gantt charts and the strategies of their use.
Because of the wide use of this type of software, the past three decades have seen Gantt charts become a common and often an expected document in status reports to management and other stakeholders. In my mind, the Gantt chart is not meant to be a status reporting tool, but rather it is a planning and tracking tool to be used by the PM and his/her team to manage their activities. This misuse as a reporting tool has lead to a couple of perceptions that I find problematic.
The first perception that goes against the grain of those of us who understand the technical details of project management is the idea that the Gantt chart is “The Project Plan“! This is far from the truth, since the Gantt chart represents only one aspect of a total project plan, the schedule.
A project plan is made up of many parts that cover not just the schedule but such things as the communications plan, risk plan, resource plan, scope definition and all the other items that make up a total project plan. Calling the Gantt chart a project plan puts too much focus on the schedule and can lead to misunderstandings and incorrect perceptions of the project.
The second perception that causes problems, is the fact that people perceive the schedule presented in the Gantt chart as immutable and set in stone. Maybe this would be true if we PMs had access to a crystal ball that could tell us all the things that we will encounter in the execution of a project before we started. But since such a thing does not exist, the expectation that a Gantt chart does not change is unrealistic.
The Gantt chart is, as I said earlier, a tool for planning. As such, it is used to project what our current knowledge says should be the schedule. With new knowledge gained – as we uncover things we did not know earlier – we are able to use the tool to see the effects of this new knowledge. Since the Gantt chart depicts the work efforts and dependencies, it allows us to see the impact of changes and thus allows us to adjust our plans to react appropriately to the changes.
Due to the above perceptions, I have a few strategies I use when dealing with Gantt charts.
- First, I make an effort to refer to it as a schedule, not a project plan.
- Second, I try to avoid using the Gantt chart as a part of a status report.
- Third, in those situations where I must provide a Gantt chart style of reporting, I will create a high level chart that excludes specific dates and shows durations over periods of weeks or months.
I would be most interested in hearing from you on how you view the use of Gantt charts. I am sure there are other strategies and views on this subject that I could learn from.