Maintaining Start Date of Activity Moved to a New Project Plan

[jrichardson]

The past 5 years my company has used MS Project Professional and Server 2003
to manage small and medium sized projects. We are now in the early stages of
also using the tools to manage large scale programs that span multiple years
with hundreds of resources and thousands of assignments.

Each project within the program has multiple releases and each release is
maintained in a single MS Project project plan (they are very large, but it
hasn't been a problem...yet). The project managers do release-level
reporting from within the project plan. The problem we are encountering is
that when an activity is "re-scoped" and moved from one release to another
after it has already started, we have a need to maintain the original actual
start date of the activity (as it was in the original release), but because
the actual start date is driven by the first date time is recorded to a task
in a timesheet, the actual start in the current release is always different
then the actual start of the original release.

Example:
Release - 1
Activity - Construct Program XYZ
Actual Start - 3/1/08

The Construct Program XYZ activity is "re-scoped" to Release 2 on 7/1/08.
The Construct Program XYZ activity in Release 1 is cancelled.

So now:
Release - 2
Activity - Construct Program XYZ
Actual Start - 7/1/08

We want to maintain that the actual start for the activity within Release 2
was 3/1/08, for reporting, accurate duration, and dependecy purposes. We do
not care about the historical hours or cost. That is being absorbed into
Release 1.

It was suggested to us that we simply log .1 hours of historical time for a
resource to the activity on 3/1/08. However, because we use Managed Periods
and only allow current period time entry (due to custom General Ledger
integration and financial period locking), users cannot go back in time to do
this.


Are there any suggestions from those who do this type of reporting or
project plan management with activities that are moved from project plan to
project plan? We would like to hear how the user community is addressing
these types of scenarios to more intelligently address our needs.

Thanks in advance for any thoughts.

Jason

 

[Jack Dahlgren]

Actual start can be entered for any task. It does not require a resource to
post time. Just insert the actual start column and enter the date.

Moving tasks with actual work can be problematic. The actual work protected
associated with the task can be difficult to deal with. However, you can turn
off managed time periods temporarily and edit the actual work protected that
the users have entered. For reasons of simplicity, I'd simply close any tasks
under the original release where they were and continue from that time in the
new release. If you want them both to show up in the "correct" release, try
using a custom field to tag each task with the release it belongs to. Then
you can determine which task efforts went to which release no matter which
project schedule they exist in.

-Jack Dahlgren