Knowing your PERT’s from your Gantt’s

Someone said to me recently that they always only use Gantt charts to manage projects. And certainly there are many projects for which a detailed Gantt chart would be sufficient – projects that are simple and straightforward, or similar to other projects previously completed successfully. But when the project is highly complex or involving new technology with many dependencies and many tasks running in parallel then only using a Gantt chart is unnecessarily running the risk of the project failing.

There are a whole range of techniques that you can use as a project manager for planning a project both in the initial stages and right through to managing risks, dependencies, change and day-to-day progress. Some of them were developed as long ago as 1910 but one of the advantages of this is that these are techniques for which a software tool is not actually necessary. Of course, I don’t mean to say that a software tool is not useful but the diagrams and charts associated with these techniques can all be drawn by hand (if you’re really keen). This means you can gain an understanding of the basic techniques without the influence of a particular software package. 

I have spent most of my career working in IT and have used many, many different software tools and packages but I’m always slightly bugged by the assumption that an ability to use a software tool equates to an understanding of the principle behind the tool. A software tool is simply something that makes it easier to do the job. But that’s my personal gripe over – it just happens to be one of the reasons I’m a fan of powerful project management techniques such as Gantt Charts and PERT (Program Evaluation and Review Technique). 

PERT charts are a form of Critical Path Analysis and are ideal for identifying dependencies – those individual tasks on which other tasks, and indeed the whole project, depend in order to be completed successfully. Because PERT charts can also indicate relative priorities they are also useful in identifying those activities that can be scrapped if the schedule starts to slip.

As with Gantt charts, the underlying concept behind the PERT chart is ordering tasks; in parallel, where possible, to reduce the overall project completion time but sequentially, where necessary because of dependencies that mean one or more tasks must be completed satisfactorily before another can be started.  

Gantt charts and PERT charts can both be used to establish the initial project schedule, allocate resources and monitor progress. But the most common form of the project plan that you will use to communicate the schedule, progress and problems to the stakeholders of a project is, of course, the Gantt chart. It shows information in a clear and easy to understand way but is less useful for showing dependencies, the relative priorities of individual tasks and the resources expended on a task. For example, they can clearly and simply show the elapsed time of a task but cannot so easily communicate how many people may have to be involved in completing the task. This is where a PERT chart becomes useful but it is also very effective at highlighting where problems are likely to occur.

One of the reasons I particularly like using PERT charts is that they essentially take a pessimistic view of how long a project will take to complete. One common cause of schedule slippage in a project is the tendency to under-estimate how long individual tasks will take. This tendency is due to a number of factors – pressure from senior management to complete a project by a pre-defined deadline, and a desire to win a contract are just a couple of them. The great advantage of a PERT chart is that it counteracts this optimistic tendency to give a more realistic view of the project. 

This is done by producing three estimates for the most optimistic, the most likely and the most pessimistic time that any one task is likely to take to complete and using all three figures to produce a reliable estimate. But PERT is also an effective means of determining and communicating which tasks can be performed in parallel, what the relative priorities of each task are and hence which tasks can be dropped if time pressures make this necessary.