Cross Project Links Always Show Need to Publish Changes...

[Terry Peters]

Good Day:
My client has used a master project to create cross-project dependency links
between two projects (saving changes to the linked projects but not saving
the master project to Project Server 2003). The external predecessor and
successor show up as expected in each project. However, they are just now
noticing that even when they have made no changes to their linked tasks, the
"Published New and Changed Assignments" indicator displays for the task,
prompting them to update the server. I have not been able to test this out
at their site yet due to my travel schedule, but am wondering if (a) this
simply is due to changes made in the other linked project (my supposition
currently), or (b) this is just a fluke in the way Project Server handles the
external links? Let me know please if you have encountered this phenomenon.
Thanks,

 

[Gary L. Chefetz [MVP]]

Terry:

This is the exact behavior we see when cross-linking between projects
creates a circular relationship between the projects. No matter how many
times you open, save, and close, project always tells you the date changed
because the last plan saved, wins! Get it? You should be able to trace this
unless your source plans are a mess.

Strategies for cross linking success:

1) Allow only crosslinking of plans in one direction (All links flow from
Plan A to Plan B) - This is an interesting restriction because it is totally
safe.
2) Perform an structure review of plans before allowing external linking. In
general, if plans contain predecessors flowing upward in the WBS, they're
not good candidates for cross-linking. Overuse of in-plan linking makes for
bad external link candidates as well.

 

[Terry Peters]

Gary:
Thank you. My mind hadn't even inched in that direction. I will go back
and check the mix of dependencies that were added between the two projects.
By the by, you and Dale are too/two cool dudes, as my teenage daughter is
wont to say. Your wisdom is vastly appreciated (if appreciation can be vast).

 

[Terry Peters]

Gary:
Just a quick follow up question concerning suggestion number 2:
(a) I am not clear on what you mean by "predecessors flowing upward in the
WBS" (are you alluding to S/F relationships?), and
(b) why would "overuse" of links be a problem--normally I think it advisable
to create the project schedule by linking all tasks rather than typing in
start or finish dates for all tasks?

 

[Gary L. Chefetz [MVP]]

Terry:

Overuse = ***More than what's necessary to drive and represent the
schedule.*** This is way more common than you think because people forget
that task 9 does not have to be linked to task 2 because it inherits its
dependency on task two through a work path consisting of tasks 2 through 9.
One of the more difficult aspects of building a good schedule is that it
requires an ability to think-through the work paths.

Predecessor relationships that flow upward through the WBS makes a schedule
difficult to manage, particularly when using external links. Simply
structuring your project schedules so that this never occurs, makes it much
easier to manage. Inevitably, what goes up must come down. A plan with
relationship links that read like some wild EKG output is fairly
unmanageable on its own, let alone in a cross-linked program environment.

 

[Terry Peters]

Gary:
*Yes, I understand "Overuse". Agree.
*By "Predecessor relationships that flow upward through the WBS" I take it
you mean when a task successor is entered in the task list before its
predecessor is listed (so that the successor has an smaller Task ID Number
than the predecessor), yes? Certainly that makes the field more cluttered.
Thanks,

 

[Gary L. Chefetz [MVP]]

Terry:

You got it. Otherwise it's like tracing the path of a single strand of
spaghetti on a heaping plate.