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.
MicrosoftProject 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... --PhlIp
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.
Because VisualBasic 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.
MicrosoftProject 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 ProgramManagers 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. ..." -- from "Painless Software Schedules" by Joel Spolsky http://www.joelonsoftware.com/articles/fog0000000245.html
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.