Case Studies | By Linda Russell | minute read
Gantt charts and PERT charts are useful tools for visualising and communicating information about projects, but they have a number of limitations. In addition, the ease with which they can be created using software applications makes them open to misuse and misinterpretation.
Part of the problem is that there isn't a clear understanding of how to break the project down in the first place, and using Gantt chart software to do this isn't necessarily the best way of going about it.
A common method of breaking a project down is using a Work Breakdown Structure (WBS). This concentrates on analysing the scope of the project according to its outcomes or deliverables. This method of breakdown does not necessarily imply any dependencies (logic) or sequence, hence neither the Gantt chart nor the PERT chart are suitable tools for carrying out this analysis.
Project Management Methodologies such as PRINCE2 also seek to analyse the project in terms of deliverables, "Products," although there is more of a sequence involved in the definition of the stages: in particular, there is a process of sign-off for each stage, sometimes called "Gateways", before the project is allowed to move on to the next.
Using the Charts
Having defined the breakdown, you should have a list of tasks which need to be completed in order to produce the desired outcomes. These tasks will have dependencies and durations and hence can be scheduled. Now's the time for the PERT or network chart software to be used. You can concentrate on the logic of the task relationships: the software should do the scheduling for you, including calculating the critical path.
Once the logic has been defined and the schedule has been calculated, the result can be displayed on the Gantt chart. It's often best not to show the dependencies (links) on this chart, especially if there are a large number of tasks and complex dependencies between them. It's also helpful if you can produce separate Gantt Charts for different WBS levels or stages/products, as they will have fewer tasks in them. Summary Gantt charts showing higher levels in the WBS may also be useful.
Charts should be seen as snapshots of the current project situation: they should be dynamic and change as circumstances change, particularly as work is carried out on the tasks.
I've seen a number of cases where the project manager creates a beautiful Gantt chart showing the project being completed on time, with nice neat task relationships, sends it out to all the people involved - and then they sit back and leave it at that. When asked how the project is going, they say "fine" because the chart looks fine. What they fail to do is update it with what's actually happening and re-schedule it according to real progress.
If some tasks are taking longer than expected, are they going to continue at the same pace and if so, what impact will this have on the rest of the plan? Remaining effort needs to be estimated and the project rescheduled.
What will be the effect if some tasks are ahead of schedule? The impact on resources will not be apparent from just looking at the charts: other tools are needed, such as resource histograms, to identify peaks and troughs in resource utilisation.
Charts and schedules are only tools to help you manage better - they won't give you the answers - and you must keep them up to date.
Linda Russell has an M.A. (with Distinction) in Technical Authorship, and over 25 years' experience in software implementation and consultancy.