The MS Project 2000 Revolution

By Jim Maddock (Member, Boston Chapter)

Background

I’m a Systems Analyst who helps to provide IT support to the project management staff at my employer. Last year we looked at implementing a project management system that would help reduce the existing dependency on meetings, phone calls and emails for project status updates and task information. This case study looks at the problems we faced and how we overcame them to implement the best solution.

Scenario

The company I work for is a supplier of automated material handling systems. As such, the equipment that the company designs and manufactures is installed at customer sites located around the world. A typical sales order project is a $10 million system, takes 6 months to a year to complete, involves 20-40 employees at any given time, and consists of 500-1,000 tasks in a project plan. Project managers and planners develop a project plan for each sales order, and they assign resources to the tasks. The project manager is responsible for making sure the resources execute to the plan, and they provide project updates to the project planners, who maintain and update the project plan with that information. With between 10 to 20 projects in process at the same time at different customer sites located around the world, keeping track of changes and updates was difficult. Typically, project information was sent to project managers, planners, resources and managers via phone calls, emails and meetings. This system proved extremely inefficient, so we needed to find a new way to communicate project status.

Installation and Hardware

We researched several different tools but decided to go with Microsoft Project 2000 and use Project Central to solve our collaboration problems. We used Microsoft SQL Server 2000 as the database to store our projects, which provided a method to share project information among multiple users and provided a method to use third party reporting tools. We selected a Compaq Proliant ML-370 server, with dual 933 MHz CPUs, 1 GB RAM, six hot swap 9 GB hard drives and two 9 GB internal hard drives. Five of the hot swap drives were configured in a RAID 5 for the project files, one hot swap drive was configured as a hot spare that would switch in automatically should one of the other drives fail. The two internal 9 GB drives were configured as a mirrored pair for the operating system and the database transaction logs. We used Windows 2000 Server with SP 2 as the operating system, with SQL Server 2000 as the database. The transaction log and the database were located on separate physical drives to improve performance.

Training

We utilized the services of a Microsoft Project Partner to provide Project Central training for the project planners. The planners then provided training for the project resources, using our in-house training classroom. We also made the Microsoft supplied training materials available on our intranet.

Implementation

We created several databases on the server so that various departments, such as sales order support and new product development, would only have access to their own projects. An account was created in the databases for each user, with read only or read/write privileges depending on the individual and their role. System DSNs were created on each computer, allowing users to access project files via the ODBC button when opening files from within MS Project 2000. Windows authentication was used to verify the users and Project Central was set up to display project information such as Gantt charts to the resources that didn’t have MS Project 2000 installed on their computers.

Trials and Tribulations

When the planners started using MS Project 2000, they encountered a few problems. One problem was the corruption of tasks and task dependencies in large projects. Fortunately the release of the MS Project 2000 SR1 update reduced many of those types of problems. The planners also encountered unwanted random renaming of our custom WBS whenever a project was saved with the attached resource pool open. They found a work around for this problem available on the Microsoft support site http://support.microsoft.com. They also found that projects sometimes locked as read only in the database when MS Project 2000 crashed on a user computer. This was resolved by using the SQL Server Enterprise Manager to open the MSP_PROJECTS table, and then set the values in the PROJ_READ_ONLY, PROJ_READ_WRITE, PROJ_READ_COUNT, and PROJ_LOCKED entries to 0 for the locked projects.

A change in direction

Although Project Central solved many of our communication problems, a major complaint from project resources was that they didn’t like entering hours they worked into Project Central, and then again in the company electronic timesheet. Our company has been using an electronic timesheet for many years, and since May 2001 we had used a web-based version. The main issue was that the majority of the 650 employees in the company did not work on sales order projects, and therefore did not use MS Project or Project Central. They needed to use the timesheet to ensure that they could log their hours for payroll purposes. However, it was discovered that the timesheet product that was being used was compatible with MS Project 2000. The timesheet company made a utility that provided import and export of project tasks and information to and from MS Project 2000 and the timesheet application.

The new method

Of course each company is different, but we found that the utility used in conjunction with MS Project 2000 was the most effective way of ensuring that our company captured all the relevant activities. Now, the project planners assign resources to tasks in MS Project 2000, using the company resource pool. The planners place the employee ID numbers in the resource pool initials column, and this value is used by the utility to map resources in MS Project 2000 to the employee timesheets. When the utility is executed, the activities are exported into the timesheet program, and a project number, customer name and task description are assigned to each resource. The resource can then click on a task to find the planned start date, planned finish date, and estimated hours. When a resource begins work on a task, they enter the hours in their timesheet. When we run the update utility, it takes the timesheet information and populates the MS Project 2000 plan with the actual start date and actual hours worked by each resource on each task. The resource can also use an ETC field in their timesheet to communicate back to the planners that their task needs fewer or more hours to be completed than were originally estimated. When the task is complete, the utility updates the actual finish date in Project 2000.

Conclusion

MS Project 2000 completely revolutionized the way we managed our sales orders. The numbers of emails, phone calls and meetings that had been an integral part of the project planning for the sales order were reduced, so that more time could be dedicated to the project in hand, and less time spent in communicating the project development. The fact that MS Project integrated so well into our own timekeeping system meant that the tool could have maximum effect on those concerned with the project management – changing the way they communicated and worked, without affecting the other staff members who needed to use the timesheet (for payment purposes) on a regular basis.