Splitting one huge plan into multiple smaller plans & retaining dependencies

D

dossmk

I tried searching multiple discussion groups but was unable to find a
solution for the issue I am about to describe, so I decided to post a
new message here in the hope that some of you may have dealt with
something similar in the past and may be able to point me in the right
direction.

I have a massive plan subdivided by individual teams. The reason I
have one massive plan is because there are inter-team dependencies.

Yes, I know I can have inter-plan dependencies in MS-Proejct, but I am
not sure whether they will continue to work properly on Project Server
2003, especially considering that the plan will keep getting modified
very often in terms of re-assigning resources, deleting tasks, adding
new tasks and a whole lot of re-publishing.

Anyway, my question is, what is the best way to split this one massive
plan into separate team plans and still maintain interdependencies on
Project Server 2003?

Any pointers anyone can give me would be gratefully accepted.

Thank you all and cheers
 
B

Ben Howard

You'll need to split the massive plan into the sub plans and then recreate
the links after the plans have been published to the server. I would also
manage these dependencies in Excel, rather than just project. There are
various techniques regarding hard links / soft links, but this isn't the
forum.
 
D

dossmk

Thank you Ben. Couple of questions:

1. Why do you suggest that these dependencies be managed in Excel and
not in Project?
2. Re. hard links and soft links, could you point me to the right
forum please? I would like to learn more about them.

Thanks and cheers
 
R

rt

Thank you Ben. Couple of questions:

1. Why do you suggest that these dependencies be managed in Excel and
not in Project?
2. Re. hard links and soft links, could you point me to the right
forum please? I would like to learn more about them.

Thanks and cheers



- Tekst uit oorspronkelijk bericht weergeven -
Click to expand...

I agree with Ben; interproject dependencies don't always make life
easier. You can also consider modelling these dependencies with
milestones: put a milestone in plan B called "deliverable from plan A"
and manage those milestones. Milestone reports across these projects
can then give you the level of control you need.
 
B

Ben Howard

Hi,
I'd manage them in Excel as well as model them in project more from a
process and visibility perspective more than anything else. IMHO each
dependency should have a unique number, give and get dates, and be managed on
a weekly/monthly basis by the programme team....
 
G

GirlGeek

Hi,
I'd manage them in Excel as well as model them in project more from a
process and visibility perspective more than anything else. IMHO each
dependency should have a unique number, give and get dates, and be managed on
a weekly/monthly basis by the programme team....

--
Thanks, Ben.http://appleparkltd.spaces.live.com/








- Show quoted text -
Click to expand...

So to expand on what Ben is saying, I read a good idea in this forum:
Create 2 custom fields: 1) "Give/Get", 2) "Give/Get Reference. For the
first, I'd say Give or Get on the Milestone row for whether it's a
Predecessor (Give) or Successor (Get), then in the Reference field,
put the name of the other project and the name of the task. I wouldn't
put task ID because that changes.

I've also used a custom flag field successfully, called 'Key
Milestone' to create Key Milestone reports - rather than MS's built-in
Milestones, because some of the milestones don't need to be reported
on. Give management a list on paper of all milestones, and have them
yellow-highlight the 'Key' milestones then flag those. You can create
a custom view in PWA showing the Key Milestones. You can flag the ones
with a Give/Get as Key.
 
G

Gary L. Chefetz [MVP]

Inter-project dependencies are manageable providing that the following are
true:

Your schedules are well-structured (We can write a book about that)
Your dependencies are judiciously chosen and carefully managed

To make dependencies manageable, not just inter-project dependencies, your
plans should follow a waterfall structure following the logical workflow.
With this structure in place, you should try to always set dependencies from
a lower-ID task to a higher-ID task. If you can stick to this mandate, your
dependencies should be easy (easier at least) to manage. The same holds true
for inter-project dependencies. Try to keep them all flowing from plan A to
plan B and not back and forth between them. When you create dependencies
that cause workflows to criss-cross with each other, you open the door to
circular relationships that can drive you mad.

--

Gary L. Chefetz, MVP
MSProjectExperts
For Project Server Consulting: http://www.msprojectexperts.com
For Project Server FAQS: http://www.projectserverexperts.com
 
Top