S
smreilly
I am a relatively new user of Project Server. We use Project Pro &
Server 2007 to manage tasks across multiple software releases - so a
separate .mpp for Release X, Release Y, and so on, with resources
shared across the projects.
Scenario - Person A completes his tasks in Release X and moves on to
his tasks in Release Y. Some time later, a customer issue arises in
Release X that Product Management claims cannot wait until Release Y,
it needs to be fixed in a patch or new build of Release X. So Person A
goes back to Release X, makes the changes and then comes back to
Release Y and picks up where he left off.
Here are some ideas and questions that I have, but I would like to
have some outside validation to know if I'm on the right track or
not...
Build "dummy" tasks into Release X for post release customer issues,
but these need to start after the software is released (we might
release ~5 builds of Release X over the course of a few months,
containing bug fixes, features that missed the initial deadlines, etc.
and they are all tracked in a single .mpp).
We are discouraged from linking tasks together across .mpps - should I
up the priority of the new Release X task to put it at the front of
Person A's Release Y task queue then re-level?
What is the best way to show (pictues) Product Management the impact
adding the new tasks into Release X has on Release Y, especially if
Person A is on the critical path? Maybe they will decide that it would
be better to appease the customer with a phone call rather than
interrupt Release Y for a Release X fire drill...
Do I need to build slack into Release Y to accommodate interruptions
to Release X or is this covered with the dummy tasks and releveling
across both projects?
Any words of wisdom that can be shared would be greatly appreciated.
Thanks!
Server 2007 to manage tasks across multiple software releases - so a
separate .mpp for Release X, Release Y, and so on, with resources
shared across the projects.
Scenario - Person A completes his tasks in Release X and moves on to
his tasks in Release Y. Some time later, a customer issue arises in
Release X that Product Management claims cannot wait until Release Y,
it needs to be fixed in a patch or new build of Release X. So Person A
goes back to Release X, makes the changes and then comes back to
Release Y and picks up where he left off.
Here are some ideas and questions that I have, but I would like to
have some outside validation to know if I'm on the right track or
not...
Build "dummy" tasks into Release X for post release customer issues,
but these need to start after the software is released (we might
release ~5 builds of Release X over the course of a few months,
containing bug fixes, features that missed the initial deadlines, etc.
and they are all tracked in a single .mpp).
We are discouraged from linking tasks together across .mpps - should I
up the priority of the new Release X task to put it at the front of
Person A's Release Y task queue then re-level?
What is the best way to show (pictues) Product Management the impact
adding the new tasks into Release X has on Release Y, especially if
Person A is on the critical path? Maybe they will decide that it would
be better to appease the customer with a phone call rather than
interrupt Release Y for a Release X fire drill...
Do I need to build slack into Release Y to accommodate interruptions
to Release X or is this covered with the dummy tasks and releveling
across both projects?
Any words of wisdom that can be shared would be greatly appreciated.
Thanks!