Data Management

Deploying Microsoft Project 2000

You've read Microsoft's recommendations for deploying Project 2000. Now read a few things that the folks in Redmond didn't tell you.

Project 2000 is out, and if you have any Project 98 users, you will likely begin hearing the drums beating in the distance, saying they cannot live without the upgrade for even another minute.

True, 2000 is a great product, and in many cases it will bring value to your organization. However, you must make sure that the upgrade will not cause any harm. This article will highlight the major points to consider when contemplating an install of Project 2000 in your organization.

System requirements
Microsoft covers basic system requirements for Project 2000 on its Web site. It suggests that you should have a Pentium 75 and 40 MB of RAM. I would suggest that these numbers are way too low! I would not personally deploy Project 2000 on any machine under 200 MHz and with less than 128 MB of RAM.

Project is a RAM-intensive application. When you open a file, Project expands the entire plan into memory and acts upon it there. If a plan is large enough, and the available RAM is low enough, Project will start writing to the Page File—and that's when performance starts to drop. Do your users and your IT help desk a favor and give Project users 128 MB of RAM. If they are managing very large projects or handling multiple projects, you might think about 196 or 256. If your Project users are asking for more RAM, they are not just techno-junkies looking for hotter machines. They really need it!

Migration and backward compatibility issues
Supported file formats. Project 2000 introduces a completely new format for the .mpp file. As with other Project version upgrades, older versions will not be able to open an .mpp file created with the new version. Project 2000 will, however, be able to save to a Project 98 file format. This will save the entire project just as if it were saved with Project 98, except it will strip out any features that are specific to Project 2000. There are several areas where this can lead to issues.

Microsoft's Project 2000 Migration White Paper covers many of these issues in detail. You should take care when transferring plans between the two versions. I would not recommend trying to have multiple planners making edits to a project file in different versions of Project. It is theoretically possible, but I feel that there are too many places for problems in such an arrangement.

Total schema change. Project 2000 also brings a completely changed database schema. The number of tables is cut greatly, and the way the data is stored is improved. What does this mean to you? If your organization saves its plans into database format, this change could mean quite a bit. If your users save to database so that they can create custom reports based on the database tables in Project 98, you could be looking at some serious rework to convert these reports to the new database schema.

This is something that your project managers might be doing without your knowledge. Check with your PMs to make sure that there are no custom reporting tools being used. Your PMs might be yelling for Project 2000 without knowing what the impact will be on this kind of reporting. Be sure and be safe.

If your users save to a SQL Server database, you will also need to have access to a version 7.0 server. Project 2000 requires SQL 7.0 if you will be saving to the SQL Server database format.

Custom applications. Among many project managers, VBA macros are used to perform custom functions that are not supported natively in Project. While the changes to VBA in 2000 should not have a great effect on Project 98 macros, it is something to take into account.

Some of the macros used by project managers can be fairly involved and complex. It is likely that IT is not aware of them, so like the database reporting issues above, you should check with your users to ensure any applications get tested before your migration.

Project 98 and Project 2000 on the same machine. Project 98 and 2000 share many DLLs (dynamic-link libraries), so having them both on the same machine can cause some problems. Microsoft does not support this configuration, so if you do it and run into trouble, you will not get any help from them. If any of your users must have access to both versions, they will need two machines or a dual boot.
IT Manager Republic will feature new articles about Microsoft Project in the coming months. What questions would you like to ask the experts? Post a comment below or send us a suggestion about future Project articles.

Editor's Picks

Free Newsletters, In your Inbox