MS Project

We have been working for some months now on a 2 site deployment of MS Project standard 2000, MS Workgroup timesheeting and centralised resource pool levelling. To say it has been a rollercoaster ride would be an understatement. Welcome to the world of "what on earth happend then" and "what service release fixed this bug". To be fair to the tool, we are trying to use MS Project for an awful lot on this deployment. It is a:

• Time recording system for Accounts to charge labour costs to the project
• Time recording system to improve the accuracy of estimation
• Scheduling tool to commit deadlines to clients
• Levelling tool to level resources across the organisation
• Cost tracking tool to record forward estimates of actual equipment costs via purchase orders

And once interfaced to UniPhi

• Project status tool for project managers
• Dashboard reporting for information to sponsors
• Team member task performance reporter

Some of the things that have gone wrong are:

To email out one timesheet, a user must create a master plan of all plans linked to the resource pool. Once completed, one timesheet that includes tasks for all projects a person has been allocated to work on will be sent to them. As part of the control process, this master plan was being saved as "Master Plan for date.mpp" Unbeknowns to us, what happends is that the tasks that are allocated are put into the users task list in Outlook (nice feature I here you say) however, the filename is used as the "category" for the task. If the task has not changed from one week to the next, then the category is not updated. When the timesheet is returned, the system looks for the weeks before's master plan (which no longer exists) and throws an exception, crashing the project plan and corrupting the data. So we no longer rename the master plan.

Similar issues come from renaming the resource pool. The resource pool currently links to 135 projects. When the file is renamed, these plans can no longer find their pool as they are looking for their old name. Hence, the all have to be opened and re-linked to the new pool.

If a user ticks a task in outlook, it then apportions the estimated work for that task across the timeframe of the task and allocates that time as actual work (not good when actual work has to be actual work and not an MS Project calculated estimate.

If a project manager ticks a task as complete then the estimated work for that task is copied to the actual work for the resources assigned to that task (again, not good when you need to report actual actuals). So they now have to zero out remaining work when a task is completed, as all the actual work should come from the individuals timesheet.

To get the full integration into UniPhi, we needed to save the plans into the SQL Server 2000 database. This has caused a whole host of issues including:

Project ID increments if saved in MS Project 2002 when the file was created originally in 2000
MS Project 2000 had a service release that fixed a bug relating to winproj.exe errors when opening plans through an ODBC database.
SQL Server 2000 has a floating point exception bug that wasn't fixed until service pack 4.

These are some of the joyful issues we have encountered throughout this deployment. However, when you look at where this company is going in terms of being able to properly commit to deadlines, forward plan, allocate work efficiently and on a prioritised basis to team members, track actual versus plan on costs and time, resource level and use theory of constraints practices to crash the critical path; we think the pain and suffering has been worthwhile.