Gantt charts - loathe them or love 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.
To start we will be clear that we are not going to deal here with repetitive implementation / rollout projects where a template plan has been refined over a series of projects and becomes a standard checklist for project management. This article is about those one off projects. These projects may be within organisations small, medium and large.
Most larger organisations have well developed and run 'IT' departments. They usually have formal project offices with established plan templates and standards, with project office staff and automated plan analysis systems (for example seeking orphan tasks / missing dependencies and so on to measure overall 'plan quality'). Smaller organisations - for example, 'IT solutions houses' - may lack this level of sophistication but will certainly use detailed project plans.
What is good about Gantt charts?
Gantt charts are an excellent format for presenting dependency and progress 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.
This leads to the actual project management overhead getting out of kilter with the budget allocation. What suffers then? An overloaded project management team, under-maintained plan / actual data or both even together. The result is Gantt chart slavery.
So, how do we avoid this paradox?
The approach should be based on a comprehensive Risk Assessment of a project at or before formal startup. The risk areas to be considered will certainly include:
- organisational politics and readiness
- organisational technology literacy
- organisational staff skills level
- technology proposal
- business risk (eg market / competitive pressure; degree of process change required)
- timescale - rate of business change
- resource including $ availability
- commitment of sponsors
The outcome should be categorisation of the 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 process itself during the project).
These differing levels of Complexity would require differing levels of project management effort allocated in the resource budget. A rough guide 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
Undoubtedly these figures will seem inordinately high to some managers. However, 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.