I've worked on a few projects managed through the use of a Gantt chart. Some of these have has a massive number of tasks and the project manager spends all their time wrestling with MS Project instead of making good choices.
I can see the point if there are a number of separate teams working towards something (e.g. legal, IT, marketing) to manage a project overall.
Has anyone participated in a software development project that has used a Gantt chart with any success?
A Gantt chart is only useful if it has sufficient details for a project manager to see what is the status of the project, and to have dependencies and resources properly accounted for.
You can always stick several sheets together with sticky tape.
The discipline of analyzing the project - breaking it down into phases, steps, deliverables, determining the resource requirements is probably even more important than printing out a pretty chart.
Many of my non-trivial development projects have benefited from the sensible use of project planning tools.
And is a GANNT Chart smaller than a single page ever useful? That little information could easily sit on a whiteboard or postit or whatever you have always in sight. There's not really any reason why you should start to wrestle with any GANNT tool when you can specify the neccesary information in a minute with a pencil on whatever paper you have.
Yes, I have seen it successful. In the cases where it was successful they used a hierarchical approach.
Rather than having a single massive Gannt chart with hundreds of tasks, there was a master chart for the whole project, with top-level goals. Then there were separate charts for the accomplishment of the sub-goals. Although this limits flexibility in one way (you can't automatically balance resources across sub-goal teams), it seems to match better to the way humans operate well: in small or mid-sized teams.
Micromanaging software development projects using MS Project is one of the more stupid things someone can do, especially in an agile environment. Too many things that take 1/10th or 10x the time that you predicted, too many things that overrun, and too many project planning meetings eating up useful work time.
In addition being a slave to the Gantt chart is a very common thing you see, especially with project managers that come from different disciplines.
However they are useful for ensuring that actions (get account with XYZ set up, get compliance to check wording on website, etc) are completed by certain deadlines. Coarse grained deadlines for programming tasks as well are fine.
All in my opinion, I'm certain that there are people who have had successful results from micromanaging programming teeams.
We always use Gannt charts in the project planning. They are always useful - after everything is said and done Gannt chart is one of the best tool to visualize your project.
It is however a tool. If the tool is used properly it is effective. It if it is not it could be counter-effective.
You need to know how to plan your project properly. You need to understand what should be included in the the list of task and how. For example for an IT project it is almost always useless going down to the level of individual assignments (create a table for storing using data). Keep it on the story level (allow users to login), assign the whole team to it and the planning will become much easier.
Later on you could always go down to the individual tasks level and you could create a separate project plan to handle the assignments for an separate task.
I've found Gantt charts to be useful for planning a project's time line and allowing for X days of vacation, slippage, etc. They're also great for making sure all resources are 100% allocated throughout the entire project.
When actually working on the project, as both a developer and team leader, I've found it best to work in short iterations with clear tasks defined for the whole team. As things slip, change, or people are added/removed from the project it's nice to be able to adjust the Gantt chart and see the outcome of the changes on the project.
I've worked on a couple of projects where we used GANTT charts. Yes they were useful, and yes they were larger than a page. What we did was to cut and paste (literally, with scissors and glue) the chart into a single big chart and put it on the wall.
McConnell in his excellent Software Project Survival Guide recommends having something that every member of a team can look at to get a rough idea of whether they are on track, and this was it for us.
I wholeheartedly agree with the comments about GANTT charts not suiting agile development - where we don't have a clear understanding of the details of the implementation at the outset.
On the other hand, I can't help but fondly remember a painful weekend I spent putting together a GANTT chart for a project I was managing where the technology and requirements were very well-understood and the schedule was critical.
We had the entrance wall to our cubicle section partially covered with this GANTT chart (5 A4 pages wide), and having it was extremely useful to making sure we were working to the critical path - getting the things done that needed to be done right now - and also made it possible for me to report to the project board with detailed reports on how the project is progressing against the schedule.
The usefulness of GANTT charts definitely depends on the context, but I'd say that if you know your requirements, and particularly if you have a lot of importance attached to your schedule, they can be incredibly useful.
Yes, I have seen it successful. In the cases where it was successful they used a hierarchical approach.
...
Absolutely. I would also suggest it works best when the hierarchy also maps to the team hierarchy, eg Project Manager creates the high level chart, Team Leads manage the middle level charts, with Developers maybe managing their own Gantt charts, but more likely using something like JIRA, as this provides a single point of focus from the developer's perspective, and is usually more paletable (ie it doesn't look like a plan, so doesn't scare them ;) )
The best use I have had from Gantt charts in MSProject is for capacity planning in the embryonic stages of a project. You can do broad brush scheduling and what-ifs, moving stuff around, moving people, add in various milestones etc. This can give you confidence that you are developing a reasonable plan.
But then using it on day to day tracking of the myriad little tasks that people actually have to do is, as has been mentioned, asking for trouble. What I have used to great effect for managing timescales at this micro level is Fogbugz's EBS stuff. You have to work at it, but it really does help in keeping a handle on things.
To summarise by repetition - Gantt is great for developing a software plan, but not for the day to day detailed update of it.
As to the page question, most of the plans I've done that have worked best (i.e. communicated the plan to people at an understandable level of detail) can be made to fit into an A3 printout. Occasionally a couple of A3 pages. But A4 is simply too small in most cases in my experience.
I have worked on one project where a Gantt chart/MS Project file was used to successfully manage the project. The project information was maintained by a non-developer manager who met with the team individually to obtain status updates. This system seemed to work fairly well and the Gantt chart provided a quick look for the entire team for status. And in talking with a friend of mine who works at a company that uses this approach, it seems to work very well for their teams.
On other projects I have worked on where the development lead is expected to maintain the chart, it has not been successful. The lead usually spends extra time trying to wrestle with MS Project. And if the culture focuses on punishing schedule delays and not on resolving the problems, then the Gantt chart can easily be manipulated to show a project on schedule until the delivery date. In those cases the Gantt chart becomes an extra piece of work that provides no value to the project.
I think the key point is to have a person outside of the development team who updates the MS Project file. And the Gantt chart should be viewed as a tool to use for communication about project status, possible problems for schedule delays and planning for resource needs. With these items in place, the Gantt chart can be helpful.
I'm not a big fan of Gantt charts, especially ones created in MS Project - so much page space is taken for so little information and at most (like most graphs) information is distorted or hidden. If a Gantt chart helps the team review what is required, who is assigned to what task, what tasks are slipping, where the risks are - then it's useful - however - most Gantt charts are developed at the start of the project and then never seen or used again. So, back to the original question - does size matter???? to quote from a recent book - if it's stupid and works, then it's not stupid
I am not a Project Manager Professional, but I run development projects for complex program analysis tools.
I drew Gantt charts of page size back in the late 70s. They never had enough detail, so I gave it up. Gantt charts with 5 tasks are useless.
Starting in the 90s, I have used MS project on some 10 real projects of 6-12 months in length with tasks of roughly 1 week size, and anywhere between 50-250 tasks organized into heirarchies related to software architecture elements, with teams of 5-10 people. Such plans print out as a grid of 3 by 5 full pages and we tended to stick this to a wall where it could be seen.
These are wonderful for planning purposes, because they force you to detail out the major activities on a project, write down descriptions, sequence and prioritize. The team can see the tasks, and see which ones are theirs, and you can review it with the team members so that everyone can provide useful feedback about durations and task ordering.
What they were NOT useful for was tracking project progress seriously. Sun Tzu tells us no plan survives the battlefield intact, and Gantt charts are no exception. It is true that with care, one could revise the plan carefully every few weeks and mark progress made. A "real Project Manager" might have done that. We were careful enough so that the original plan tasks held up pretty well through about half the project, and by that time people pretty well understood the problem and additonal re-planning occured but informally rather than with MS project.
I have also used MS Project to plan many similar tasks for serious time and estimation purposes. This has the unfortunate side effect of producing realistic estimates with most of the costs visible. Its amazing how realistic estimates kill project proposals. Industry seems to want bad underestimates to start projects; its no wonder so many overrun time and budget.
I have a love-hate relationship with MS project itself. It takes task descriptions, task precedence, and resource assignments. But I cannot say, "I prefer this task to complete first over that task" which would ask as an optional task-precdence, and I cannot assign a resource partly to one task an partly to another and get any sensible schedule.
But for complex project estimation, I don't see how you can live without this. The agile people will tell you you can't plan; I don't know who they have as customers. I've never found a customer that was willing to let me work without a plan or a dollar/time budget he would hold me to.