Gantt Charts are impressive artifacts conveying a huge deal of information intended to send out a perception of control to everyone involved with the project including the people who sign the pay-checks; sometimes technically refereed to as the 'stake-holders' . As a Project Manager, you typically make a Gantt Chart to flaunt this false illusion of control by documenting it in the form of a very technical-looking artifact.
After years of building Gantt charts, a few years ago, I came to one conclusion: Like most project artifacts of the traditional days, Gantt carts are useless, built to impress and pamper false egos of Project Managers who build them and the stake-holders who ask for them. In most cases, an elaborate project plan in a Microsoft Project file is a symbolic representation of a non-technical-and-traditional project manager screaming at the top of his voice, in a desperate attempt to make a statement that even he contributes 'something' to the project.
Jeff Atwood compares the picture of the Gantt Chart above to the Traditional Waterfall Model. After all the above picture does seem to have striking similarities to something we all recognize.
Besides the fact that Gantt Charts look and act like the planning strategies deployed in traditional waterfall and other Big Design Up Front methodologies; Gantt Charts and Microsoft Project are considered useless by Agile practitioners around the world for multiple reasons:
Reason #1: Microsoft Project Plan And Gantt Charts end up sounding like a Know-All-Document
Ever worked with a Microsoft Project File? By It's very nature Microsoft Project expects that you would know every single task involved in the project, every single sub task in the task, the start date for the sub-tasks and the end dates of the sub-tasks. If you don't type them in, Microsoft Project inserts question-marks making the document look incomplete.
Reason #2: Microsoft Project Plan And Gantt Charts encourage Micro-Management
When you have every single task and sub-task, itemized with an end date attached to it, it's easy to sit in your management-ivory-tower, find out who isn't meeting his deadlines and act like a Prick in a desperate attempt to make the project move faster by speeding things up.
Reason #3: Microsoft Project Plan And Gantt Charts Encourage Status Reporting In Percentage Complete
The Percentage Complete field sits boldly on your project plan sheet tempting you to update the value on a regular basis. Everyone likes to report that they are ninety percent done where Agile clearly pushes for a mutually agreed definition of done.
Reason #4: Microsoft Project Plan And Gantt Charts glamorize the idea of dependencies and concurrencies
While kick-ass programmers are always scratching their heads on how to reduce dependencies Gantt charts clearly seem to suggest that everything can be classified as having a dependency on something else or being an activity which can be executed in parallel. Everyone knows the perils of multitasking. Besides, agile practices like Extreme Programming have always pushed the idea of developing and testing in isolation using mock objects followed by continuous integration rather than integrating in the end.
Reason #5: Microsoft Project Plan And Gantt Charts propose and push the idea of 'resources' and gives you a tool for Policing
When you have every single task broken down at a micro level and you have twenty individuals at your disposal, it's tempting to assign a task to an individual who is idle just because he is idle. Gantt charts, to some extent, tempt managers to see their teams as isolated resources which can replace each other The idea of not considering strengths and weaknesses of individuals is one of the biggest mistake you can make as a manager. It is the kick-ass programmers who get the projects successful; not the Gantt Charts.
Besides having an 'end date' associated with every single sub-task encourages the traditional project managers police their team.
Simply put, for managers who have nothing to contribute in a project, Gantt charts make them feel good about their existence by convincing themselves, that they are, in some way, contributing and adding 'some' value to the project.
Even as I type this, I can literally visualize a young and budding Project Manager, who has been recently told how awesome Gantt Charts are and how they are this amazing and cool time proven way to represent their project. I can visualize this young and budding project manager reading this post and going:
|
Hey Pops, are you telling me that Gantt charts are inherently evil and that Microsoft Project is a crappy piece of software that no project manager on this planet should be using? Are you trying to tell me that Microsoft Project and Gantt charts are evil tools developed to satisfy the ego of project managers and they cannot be put to any good use what-so-ever? |
No, not really. That's not what I'm saying here. To be fair to Microsoft Project and Gantt charts, they aren't essentially evil if you keep your project plans at a very high level and assign them to individual team leads.
Having said that, when you keep you Gantt charts at a level that is this high most Agile practitioners don't see the purpose of having the Gantt chart in the first place.
Just like the double-click-and-write-code model of Visual Basic 6.0 and even the current code behind model of ASP.NET, Microsoft Project and Gantt charts provide you with an constant temptation of taking the wrong path and give out the I-know-all-signal to your clients instead of making them your allies and admitting up-front how little you actually know. Microsoft Project and Gantt charts in particular, gently nudge you to micro manage every single task item, introducing more problems then the ones they claim to fix.
The problem with Microsoft Project and Gantt chart, dear reader, is not that these tools are anti-agile; the real problem with Microsoft Project and Gantt charts is the approach and the thought process these tools seem to take aren't inherently the best approach and philosophies who want to run your agile projects on.
In his class post on 'The demise of the Gantt Chart in Agile Software Projects' the author David Christiansen believes that the approach and philosophy of the Gantt Chart can negatively impact Agility. David explains:
|
So, perhaps building software in a certain order isn’t really required, but surely it is more efficient to do it a particular way, right? I’m not one to favor the idea that there is always one best way, but it does seem intuitive that it would be more efficient for 5 different developers to be working in parallel on 5 different features if they were all building the features into a clear and complete application architecture. That way they could, for example, take advantage of existing persistence and security mechanisms instead of inventing those wheels themselves in their feature code. Recognizing that, the good PM will develop a project plan that has the architect building the architecture first and then the developers showing up to build the features next. Of course the architect will need to know the requirements of all the features in order to build the architecture correctly, so the analysts will have to show up first to get the requirements right… Before you know it, you have a project plan with the standard set of phases all lined up into one gigantic critical path - which looks really cool on a Gantt chart. Let’s go back to the roots of the scenario though. It assumes that the persistence and security mechanisms correctly support the needs of all 5 feature areas being developed. That, in turn, assumes that the requirements of those feature areas were captured accurately AND that they won’t change notably, which assumes that the users can articulate the requirements properly to begin with. Those are all assumptions that research (citations) has shown to be, well, problematic at best. |
Of course, some kick-ass developers and managers around the world might be capable of resisting the temptation and getting the Gantt charts to become Agile; for the rest of us mere mortals, survey results show that the trick is to throw your Gantt Charts out of the window and move to simple collaboration, high level planning, a kick-ass team that likes working with each other and iterating faster.
Comments are closed.