Are You A Gantt Chart Slave?
charts - love them or loathe them?
They are a fundamental tool in a project manager's toolkit. However, an unseasoned project manager can find that
they can take over the project and result in reduced control. How so? In this article we will look at their
potential pitfalls and provide some tips and strategies for ensuring successful project management. Gantt charts
are, after all, just one of many ways of presenting the project planning and actual data that has been input.
Firstly, let us be clear that we are not going to talk about repetitive implementation/rollout
projects where a template project plan has been refined over a series of projects and becomes a standard checklist
for project management (for example for commercial off-the-shelf software). This paper is about those one off (or
initial template try-out) projects. These projects may be within organisations large or small.
Large organisations which have mature and well run 'IT' departments may well have formal project offices with
established project plan standards, dedicated project office staff and probably automated plan-quality checking
systems (for example seeking orphan tasks/missing dependencies and measuring other metrics to provide an overall
'plan quality' assessment). Smaller organisations - for example, 'solutions houses' - may lack this level of
sophistication but will almost certainly require detailed project plans.
Fine, so what is good about Gantt charts?
Gantt charts are an excellent format for presenting dependency and proress data, but as with most things in life,
the returns will be dependent on the investment. So, the more care that goes into the project plan data set-up,
then the better will be the feedback. However, there is a danger that the level of detail that can be built into
the typical project plan can itself require a disproportionate amount of project management maintenance. We will
not go into great detail here, but dependency and critical path management are of major importance. So, 'sweating
the detail' in the plan is critical at the outset.
Then, the actual project management overhead can get out of kilter with the budget. What suffers then? An
overloaded project management team, under-maintained plan / actual data or both even together. The result is Gantt
So, how do we avoid this paradox (aside from unlimited budgets)?
The approach I recommend is based on an initial comprehensive Risk Assessment of a project. The areas to be
considered will certainly include:
- organisational readiness and politics
- organisational technology literacy
- organisational staff skills level
- technology proposal
- business risk (eg market issues/competitive pressure and degree of process change required)
- timescale - rate of business change
- resource including $ availability
- sponsorship weight
This will result in categorising the proposed project as Low, Moderate or High Complexity. Note that a Moderate
Complexity project may have a High Complexity phase (and this links back to Contingent Project Management - dynamic
tuning of the project management processes).
These levels of Complexity would require differing levels of project management effort set in the resource budget.
'Rule of Thumb' would be:
Low Complexity - project management effort 7-11% of overall resource budget
Moderate Complexity - project management effort 12-17% of overall resource budget
High Complexity - project management effort 18-22% or more, of overall resource budget
Now these figures may seem to be inordinately high to some people, but more than 30% of projects are deemed
failures - and failure is always the result of inadequate project management (which includes Risk Assessment and
Management). So, the 'buck stops' at the quality or quantity of project management.
What has all this got to do with Gantt charts?
- the plan structure should reflect the prioritised risk analysis with simple milestones / gateways
- the degree of detail built into project plan database should be proportional to the project complexity
- the management reporting requirement should be proportional to the project complexity, thus only requiring
Then, the maintenance requirement is focused on what really matters. The Gantt charts reflect that, with the degree
of detail proportional to the phase risk.
This means that a project manager comes to the office every day thinking 'How do I move the project forward today
towards that milestone'? and not 'another 4 hours collecting data and 2 hours inputting it before I can get any
real work done'.
Then, the project manager's role is mainly one of pro-action and not one of administration.
Phil Marks, May 2010
More than 20 years successfully resuscitating and successfully delivering projects in banking,
manufacturing and distribution, commerce and government. Find out more at => www.projectpdq.com
Phil Marks, MSc, MBA, MBCS, Chartered IT Professional.