Posted on

The Gantt Chart

The Management Pocketbooks Pocket Correspondence Course

This is part of an extended management course. You can dip into it, or follow the course from the start. If you do that, you may want a course notebook, for the exercises and any notes you want to make.


We are working through a series of blogs, looking at some of the essential models that a project manager will need. We will cover:

Once the dates are passed, these links will work.


The Gantt Chart is like a non-identical twin of the Network Chart which we saw last week. It contains all of the same information, but displays it in a different way.

The Gantt Chart is named after Henry Gantt, who did not invent it. As far as I can find (Wikipedia seems clear on this), it was invented some twenty years before Gantt re-invented it by Polish engineer and economist, Karol Adamiecki. Writing in Polish, of course, and calling it a harmonogram , would never endear it to Anglophone engineers and managers, who, if they had heard of it, would probably have thought Harmonogram too effete and musical-sounding a term. Gantt Chart has an air of brutality to its sound and Gantt was a thoroughgoing American.

Building a Gantt Chart

Anyway, let’s convert last week’s network chart into a Gantt Chart.

First, we draw two axes:

  • on one, put a time scale
  • on the other, list all of the tasks

Now, starting with the first task, represent each one by a bar. Make the length of the bar represent the duration of the task, and place it to represent its scheduling, as driven by the sequencing and dependencies of your network chart: voila!

First, here is our Network Chart

Critical Path on a Network Diagram

Now, let’s translate this into Gantt Chart format…

Gantt Chart

And it really is as simple as that… until your project gets large and complex.

Further Reading 

From the Management Pocketbooks series:

  1. Project Management Pocketbook

 

Share this:
Posted on

The Critical Path

The Management Pocketbooks Pocket Correspondence Course

This is part of an extended management course. You can dip into it, or follow the course from the start. If you do that, you may want a course notebook, for the exercises and any notes you want to make.


We are working through a series of blogs, looking at some of the essential models that a project manager will need. We will cover:

Once the dates are passed, these links will work.


One of the pieces of project jargon that causes most confusion is ‘Critical Path’ and ‘Critical Path Analysis’, the process of calculating the critical path. The concept is actually quite simple, providing you start at the beginning.

Tasks, Duration and Sequence

The first step in preparing a project plan is to identify all of the tasks you will need to complete. When you have done this, for each task, you must estimate how long it will take. The third key step is to figure out how the tasks connect up, logically, into a sequence. For most of them, one task will be followed by another, which will be followed by another. In project management jargon, this is a series of ’finish-to-start dependencies’. This sequence creates what is known as a ‘work stream’. The complications arise when some tasks can run in parallel to one-another, when some tasks can trigger the start of more than one task, and when some tasks can only start when more than one task has finished. There are more complications than this, but that’s enough and covers most small to medium sized projects! The best way to make sense of all of this is to draw yourself a flow chart; what is known as a ‘network diagram’. Network Diagram

Calculate the Critical Path

Once you have the logic of your network drawn out, you can add your estimates of the durations of each task. These will allow you to calculate how long each path through the network will take. The longest path is called the ‘Critical Path’. It is critical because any delay (or ‘slippage’) to a task on that path will cause a delay in the completion of your project. Critical Path on a Network Diagram There you have it – simple in concept. Of course, like much that is simple, in the real world it is seldom easy. Calculating (and optimising) the critical path for a large, complex project with very many interdependent tasks is a big computation. When the methodology was invented in the 1950s, it was a big job to undertake. Nowadays, all but the very the biggest projects can be planned, optimised and monitored with the help of software running on a standard personal computer. I will never forget having the chance to look through the network diagram of the project to build and launch the first NASA Space Shuttle. Hundreds of pages of large paper and small print. ‘But’ said the project manager who showed me it, ‘when they planned the Mercury and Gemini missions in the 1950s, every time an engineer or project manager wanted to change the logical sequence, the network (or a chunk of it) had to be re-drawn by hand.’ How would that affect our attitude to getting it right the first time?
Further Reading  From the Management Pocketbooks series:

  1. Project Management Pocketbook
Share this: