EXPERT RESPONSE
Gantt charts always make me groan a little. I don't use them for detailed planning -- I think they are ill-suited for the task. Check out this article by Tate Stuntz describing why the Gantt chart isn't all it's cracked up to be. I find that a detailed Gantt chart doesn't make a good project plan because the overhead of keeping it up to date quickly exceeds the value it provides. Generally speaking, they are also poor predictors of when the project will end because the dependencies rarely work out the way you think they will.
I prefer to use Gantt charts at a higher level for release scheduling. In this situation, less is more. Most of the time, I create these Gantt charts in Microsoft Excel. I lay out my timeline as columns (usually one month per column) and my iterations (or sprints or releases or whatever you call your chunks of work) as rows. In the first column I describe the scope, and then I color in the months in which I think the work will occur. Sometimes I enter the number of people involved in each month cell. When I do this, the second column is a total cost column.
For predicting when something will end, I use burn-down charts. Here's how wikipedia.org describes the burn-down chart:
"A burn down-chart is graphical representation of work left to do vs. time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. It is useful for predicting when all of the work will be completed. It is often used in Agile software development methodologies such as Scrum."
Burn-down charts are better at predicting end dates than Gantt charts because they take into account the actual pace of the project (velocity, in Agile speak). The velocity is simply the slope of the burn-down chart, and the end date is the point at which it crosses the x-axis.
Some project managers use PERT networks to calculate the critical path of a project as well as to predict when it will complete. The critical path is the set of tasks that, if not completed as scheduled, will cause the overall project to slip. Although this technique is widely evangelized by project management training organizations, I believe the complexity of the approach and the inherent difficulty in predicting dependencies in software projects significantly impact the usefulness of this approach. Instead, I prefer to structure my projects in small, easily manageable chunks that don't have complex dependencies, thus eliminating the need for this type of analysis.
I'm not familiar with burn-up charts, unless it is a document used to plan what you will do with all those overly complex Gantt charts most project managers carry around!
|
