Gantt Charts are commonly used to visually represent dependencies and progress against milestones and activities. They are often viewed as symptomatic of a top down, plan driven, control environment, and as such, they are looked at despairingly in the agile community. Although being called a GanttHead is an insult to an agile practitioner, I propose that agile initiatives can often benefit from traditional Gantt Charts.
Top Down Plan Etched in Stone
The use of Gantt Charts on software projects is a sorry history of creating a schedule, etching it in stone and then trying to bend reality to match an outdated schedule. No wonder the agile community hates Gantt Charts. But, there are times where a larger project, that includes agile software development as one component, can benefit from the use of Gantt Charts.
Example A: Developing and Delivering Training for a Large Call Center
Let’s assume your team is developing software for use by a large contact center (historically known as call centers). The call center uses your software to respond to prospect and customer questions on IRA’s and other personally funded retirement accounts. The contact center is incredibly busy from late January to late April (e.g. during the US Tax Season). During this time the staff works 60+ hour weeks.
Your team is doing the software development, but you are also going to be training the call center staff. There are a 150 of them, and you need to plan the training, several months in advance, to coincide with off-peak season, when most of the staff is working part time. The manuals need to be printed and delivered, the training rooms must be arranged, and the staff must be available during the heavy vacation period of the summer.
Common sense tells us that a traditional Gantt Chart, with clearly defined dependencies and dates, works well as a way to communicate among the various parties involved, track progress, and address changes in plan.
Example B: Rolling out new Laptops to a Distributed Sales Force on Your CRM Initiative
As another example, perhaps you are on a team delivering a new CRM Platform to your sales force. This sales force is distributed, but members of the sales team generally come into one of 12 regional offices once every couple of weeks. As part of the rollout you are upgrading the laptops for all 325 members of the sales force. There are some complexities, so you need to first choose a hardware / software platform that supports a handful of legacy applications that are in use, while meeting security standards, and then roll them out to the sales team.
Once again a traditional Gantt Chart, with clearly defined dependencies and dates, works well as a way to communicate among the various parties involved to track progress, and address changes in plan for this example.
In Closing: GanttCharts can be Beautiful
Gantt Charts make sense when you have to schedule date driven events, with true finish to start relationships (such as finishing training material before printing it).
I don’t propose that you use Gantt Charts to replace your card wall or your agile lifecycle management tool, I do propose that some of your work can benefit from a traditional approach of laying out dependencies and time lines visually to support planning, communication and making adjustments to schedules.
So, in closing, perhaps GanttHeads can be beautiful, and right!
