07/08/2009 08:45:03 AM EST

When you say, "Using a Gantt chart to estimate a software project is like designing a rocket ship by snapping together Lego blocks," I would most certainly agree. Gantt charts aren't an "estimating tool" at all. If that is being done in anyone's organization, it's wrong. "it fails to capture the complexity and variables of that which it is modeling" -- as it should. There's nothing "modeling" about a Gantt. It is a vast over simplification intended to represent a time line and nothing more. It is not a model. The real problem with any kind of project representation is when we, project managers, analyst, or whatever we're called today, "sell" it to executives and stakeholders as a baseline road map and agree to perform according the (very tentative) time line. We shoot ourselves in the foot by giving in to that kind of pressure on projects where nothing is really known up front. In the Agile world and especially Scrum-world, a Gantt is particularly valueless. When the project is timeboxed, end dates and milestones don't slip... features and stories do. When the team is known (x number of people) and the project is timeboxed (for y number of weeks), the project is also fixed cost. Where's the cost estimation in this scenario? There isn't any... it's all about how many stories or features can be incrementally deployed in the allotted time with the allotted people. In cases where Agile is feasible (practice what's possible), the value of Gantt charts is debatable at best. In cases where Agile is not feasible, their value may be more. But never is a Gantt chart an "estimation tool" or "modeling" of a project. It is a graphical way to represent time lines especially in a way that is easy to understand by non-technical people. That's all. Nothing more. Don't confuse a Gantt chart with the Holy Grail of anything.

United StatesWoody Williams