Microsoft Project is a tool that when applied to software development will be able to, with uncanny accuracy, tell you that component X will be finished at precisely 2:35pm on Monday 4th November. You may then, and only then, move on to Component Y. Now can XP do that I ask you? :-) -- MauriceLynch?
Seriously, Project is a software application that manages schedules. You can enter tasks, the number of people working on those tasks, how long each task will take, which tasks require other tasks, etc. It can then output the entire thing as a massive GanttChart
. These charts are notorious for going out of date very quickly.
is normally used in a BigDesignUpFront
project, and really fails to discourage WaterFall
speculation. (see AntiProductivityTool)
MS Project is very useful in at least one scenario: with these resources and this much time how much
can I expect to have done? It's when one of the other variables is (imagined to be) free that the trouble begins...
I found MicrosoftProject to be uncannily accurate, out of a team of 8 engineers, in deducting that
I was on the CriticalPath. Funny how that
always worked out...
- Maybe you were the only one being realistic, planning time for UnitTesting and such. -- io
A big "advantage" with Microsoft is that, if the estimates for all the tasks don't fit within the allotted time, you can just shrink estimates until they fit. What could possibly go wrong?
It's also (outside the enterprise class systems) about the best project management system on the market. It's an example of how MS persists with something, improving it through multiple releases. In the case of Project, it's still got lots of room for improvement, but it's usable. If you choose it to model a project with more definitiveness than actually happens in your software projects, that's hardly the fault of a tool. Not all projects are as fluid as software development, and for many of those, MicrosoftProject
is an excellent tool to assist you in managing the project (PaulHudson
, a bit tired of the cynicism).
What limit does Project impose on the number of activities in the project? Has it been used for, say, a major NASA project?
As I recall from working with MS Project at my last job, there's no hard upper limit on the number of activities, but the application becomes increasingly sluggish as more and more tasks are added. If I remember correctly, MS Project becomes impractical with a project of more than several thousand activities; at that point, the project file is usually manually split up into several smaller projects. -- BrentNewhall
Are there better project management packages? I think all of them can have problems if used inappropriately, and MicrosoftProject is actually one of the better ones...
I worked a project where the TrackerRole
printed out MicrosoftProject
charts on an HP Design Jet printer, 3 by 4 feet, and hung them on the wall every week. The horizontal arrows represented engineer-days on modules, and the vertical arrows were "integration" into new modules.
made daily builds a joke, we integrated infrequently. Because the downward arrows represented IntegrationHell
, they occupied a lot of time. The MicrosoftProject
chart would have predicted the schedule better if we had turned it sideways.
To answer the questions here, it appears the project chart theory and philosophy that MicrosoftProject
embodies was invented in the hardware world, civil engineering subset. --PhlIp
Yes, I think that's true. That doesn't mean it's useless in software engineering, but there's definitely an impedance mismatch, and blind application of the "civil engineering" model to software will cause problems
In fact, HenryGantt?
(one of FrederickWinslowTaylor
's disciples) invented his eponymous chart to aid the management of manufacturing and fabrication projects (so that would be the mechanical engineering subset).
That sounds like bad project planning, and would have been a bad idea regardless of the tool. That behaviour can be encouraged by tools like MicrosoftProject
, though, especially among people who think ProjectManagement
is merely producing and tracking against a project plan.
is not that bad. It's really important not to use all the features, though. As a outliner for the work breakdown, a recorder of dependencies, and a record of who's down to do what, it's okay, and often better than manual planning or spreadsheets. If you let it do the resource levelling, you're on the path to ruin. And I never can get the views to display just the way I want 'em. -- PaulHudson
At my place of employment, whoever on the project is most familiar with MicrosoftProject
is granted the title of "Projectologist". (The word is usually accompanied with the motions of donning a fake elbow-length, latex glove--complete with a snap of the latex against the forearm). Given the things the ProjectManager
frequently must do, this analogy seems rather appropriate...
We also have a long list of tasks for ProgramManager
s to do to "scrub" their schedules--most of which are there only to get around known defects in MicrosoftProject
About 10 years ago, I had the task to compare Timeline 1.0 with MS Project 3.0. At the time, I chose Timeline. I think I would still choose Timeline 1.0 over the current MS Project, mainly because Timeline could level resources in a rational manner.
Are there better project management packages?
"Here's a simple, painless way to make schedules that are actually correct.
1) Use Microsoft Excel. Don't use anything fancy like Microsoft Project. ..."
"Painless Software Schedules" by Joel Spolsky
If you're working for a manager who uses MicrosoftProject
, you may need a MicrosoftProjectViewer
to be able to view it.
There is a new, currently free, tool called OpenProj? (http://www.projity.com) that appears promising in this regard. In fact, it is more than just a viewer; you can actually open, edit, and re-save MS Project files.