3 ms·
Are you using the Gantt charts for anything related to programming tasks (timelines for software completion, deliverables, etc)? My experience in two recent pr
by jat850 16y ago
Are you using the Gantt charts for anything related to programming tasks (timelines for software completion, deliverables, etc)?
My experience in two recent projects using Gantt charts as part of timelining has left me with a bitter taste for how they relate to actual concrete programming tasks.
A key failure a number of our developers identified is code doesn't translate well to a linear scale. It's nearly meaningless for me to tell my software lead that a component is 80% "done" after a week, when the 80-90% gap could take a month, and 90%-100% might not even be attainable. (I have a nearly impossible time ever considering something 100% "done".)
Coupled with dependencies and "Waiting For" or "Requires", it feels entirely like it's not an appropriate or truly representative model. This has led to intense frustration and tensions. Most of the developers on my current project dread the weekly Gantt chart update.
I most often find myself simply saying, "whatever I said component A was at last week, add 1%". It leads to a massive disjoint as one moves further up the management chain.
I realize this is a mini-railing against something you might not even be intending to use them for. I also realize that our software company may not be getting maximum utility out of the style of project management we use. I only speak from a developer's perspective who has been frustrated time and again when faced with something so horribly artificial-feeling.
edit For what it's worth, we use Microsoft Project. I've also used dotproject for non-work related coding I've done, but never learned it fully enough to speak to its capabilities or strengths and weakenesses.
- interesse 16y ago> (I have a nearly impossible time ever considering something 100% "done".) I'd say you have a hard time being a programmer then. At the end of the day your code needs to get into production, and this should be after the point your job is "100% done" so the people having to do work after yours (qa, release etc.) can do their job. Bug fixing etc. aside it all depends on finding a satisfactory "definition of done". We call it exactly like this and it is an important part of our project management early on in every project.
- yannis 16y agoI have been involved with Construction for over twenty years. We recently had a Project with over 22,000 activities. Needless to say it became unmanageable and no-one used it. Real construction is similar in many ways with the development of software. One of the problems is reporting progress, in most cases is like trying to measure microns with a yardstick, the granularity and accuracy of the measuring instrument is not there. On the above Project (a high-rise Tower) we came up with a graphic that had little squares representing activities. The graphic looked similar to the Tower: --------- | | | | | --------- | | | | | --------- Using color, green for done and white for not done, you could have a snap of progress at a glance. You set them side by side and you can see weekly Progress. I have been trying to refine the idea and make a start-up out of it:) (You can think of software as a Tower as well!)
- dmd 16y agoI mostly use them to communicate to clients what parts of a (non-programming) project are their responsibility, what parts are my responsibility, and what the dependencies between these parts are, so everyone gets everything done at the right time to reduce blocking.