B
Brenda
Is there a secret to maintaining the integrity of links between 2 different
project schedules?
project schedules?
R
Ratheesh
Brenda,
Can you please elaborate your question.May be some will be able to help.
Can you please elaborate your question.May be some will be able to help.
B
Brenda
I just joined an organization that has 5 different schedules for their one
project whose tasks interlink.
As an example:
This XYZ project has 5 different components; A, B, C, D, & E.
There are tasks on schedule E that component C is dependent upon.
Then there are tasks on schedules D & B that component A is dependent upon.
These links between schedules are impossible to maintain.
It seems if you ever open a project file that is a different version of
these schedules (we save a new working version daily for version control),
some of these tasks try to go out and grab another link. We end up with links
to former versions or even totally different schedules.
Other than putting all of the schedules together in one large project file,
is there a process or trick to ensure that the proper links are maintained
and false links don't get pulled into the schedule?
Any and all experience and/or suggestions will be greatly appreciated!
project whose tasks interlink.
As an example:
This XYZ project has 5 different components; A, B, C, D, & E.
There are tasks on schedule E that component C is dependent upon.
Then there are tasks on schedules D & B that component A is dependent upon.
These links between schedules are impossible to maintain.
It seems if you ever open a project file that is a different version of
these schedules (we save a new working version daily for version control),
some of these tasks try to go out and grab another link. We end up with links
to former versions or even totally different schedules.
Other than putting all of the schedules together in one large project file,
is there a process or trick to ensure that the proper links are maintained
and false links don't get pulled into the schedule?
Any and all experience and/or suggestions will be greatly appreciated!
A
AndyB
Hi Brenda, I think I know what you mean and no you shouldn't rename to
up-issue the file as this will break the directory path to the sub-projects.
You will need to maintain them in a single directory and then forget about
the file naming of those files and I would suggest up-issue the progress
reports as an output instead. I have to be very careful with this myself
when the master consolidation file references many sub-projects and their
sharing with the resource pool.
For example the projects are named: Project/Project code/Stage (we operate
a 6 milestone common gated process with 6 distinct stages).
These sit in a folder titled: Project Manager Name
Which in turn sits in a folder titled
rogramme Name
So the path for the resource pool or cross links or inserted projects always
reads the same:
Programme/Project Manager/Project Name/Project Code/Stage
Yes it still requires some maintenance but by having a structured directory
path it becomes easier to see where broken links have come from.
I hope this helps,
AndyB
up-issue the file as this will break the directory path to the sub-projects.
You will need to maintain them in a single directory and then forget about
the file naming of those files and I would suggest up-issue the progress
reports as an output instead. I have to be very careful with this myself
when the master consolidation file references many sub-projects and their
sharing with the resource pool.
For example the projects are named: Project/Project code/Stage (we operate
a 6 milestone common gated process with 6 distinct stages).
These sit in a folder titled: Project Manager Name
Which in turn sits in a folder titled
rogramme NameSo the path for the resource pool or cross links or inserted projects always
reads the same:
Programme/Project Manager/Project Name/Project Code/Stage
Yes it still requires some maintenance but by having a structured directory
path it becomes easier to see where broken links have come from.
I hope this helps,
AndyB