Combining Linked Projects

[Roland67]

I need to create a file which combines numerous sub-projects (some with
sub-projects), total tasks around 6000. I have tried building a new schedule
with inserted projects and no links back to the original. However, project
keeps losing hard-coded dates and external link information. If I lose this
information I will be spending considerable amount of time relinking
everything.

Suggestions / recommendations? Thanks

 

[John]

I need to create a file which combines numerous sub-projects (some with
sub-projects), total tasks around 6000. I have tried building a new schedule
with inserted projects and no links back to the original. However, project
keeps losing hard-coded dates and external link information. If I lose this
information I will be spending considerable amount of time relinking
everything.

Suggestions / recommendations? Thanks

Roland67,
What do you mean "Project keeps losing hard-coded dates and link
information"? It is difficult to tell what may be happening without more
information. Then maybe we can offer suggestions or recommendations.

I also question the use of "hard coded" dates. A well structured Project
file ideally should have no hard dates, however there can be exceptions.
What is the nature of your "hard dates"?

John
Project MVP

 

[Roland67]

i agree that task dates should not be hardcoded. I've asked what it is
dependent on and the answer keeps coming back as "nothing, thats just when
the task should start".

Hard dates are those where the date is typed into the cell rather than
determined by a link. We have dates in 2008 / 2009 where tasks begin. When
those tasks are inserted into another project then the date reverts back to
the start of the project as entered in the "Project Information" area.

RC

 

[Jan De Messemaeker]

One detail needs specifying here.
Quote:
"Hard dates are those where the date is typed into the cell"
FORGET IT.
When the date is typed into the cell Project creates a Start no earlier than
constraint.
By no means does this mean that this date won't change (for instance by a
link)
HTH

 

[Roland67]

Thank you for your input.

Jan, your correct in your comments. Tasks do take on a constraint when
manually entered rather than linked. And yes, they can be changed if a link
pushed them beyond that constraint.

John, I hear what you're saying. BTW, nice soapbox! This project's
customer wants to know tasks going all the way out to its proposed completion
in 2010. We do not have any blinders on to not expect changes in tasks past
2005. We are just required to plan as best we can.

Now back to the "slamming" (I like that term) start dates. Any other
suggestions as Jan has indicated the inclusion of constraints won't work?

 

[John]

i agree that task dates should not be hardcoded. I've asked what it is
dependent on and the answer keeps coming back as "nothing, thats just when
the task should start".

Hard dates are those where the date is typed into the cell rather than
determined by a link. We have dates in 2008 / 2009 where tasks begin. When
those tasks are inserted into another project then the date reverts back to
the start of the project as entered in the "Project Information" area.

RC

Roland,
I would have to ask the question, who says that is "just when the task
should start"? Further, if these tasks are out in the 2008/2009 time
frame, I challenge anyone to be that specific. Something has to happen
(i.e. predecessor, like maybe a contract) to initiate those tasks. If
you are planning specific details more than a year out, somebody is
kidding themselves - life just isn't that predictable.

Ok, enough on the soapbox. When you insert a subproject into a master
file, any tasks in the subproject that have no constraint (i.e.
as-soon-as-possible) will immediately "slam" back to the Project Start
Date of the master. It sounds like that is what is happening. One way to
prevent that is to give the subproject tasks a constraint of,
"start-no-earlier-than".

Hope this helps.
John
Project MVP

 

[Jan De Messemaeker]

But I did not say that!
I said entering dates in the start field won't help.
Insert a field "Constraint Type" and one "Constraint date"
If you want to nail down a task, set type to Must start on and the date
desired.
That way even a link won't move it.
HTH

 

[John]

Thank you for your input.

Jan, your correct in your comments. Tasks do take on a constraint when
manually entered rather than linked. And yes, they can be changed if a link
pushed them beyond that constraint.

John, I hear what you're saying. BTW, nice soapbox! This project's
customer wants to know tasks going all the way out to its proposed completion
in 2010. We do not have any blinders on to not expect changes in tasks past
2005. We are just required to plan as best we can.

Now back to the "slamming" (I like that term) start dates. Any other
suggestions as Jan has indicated the inclusion of constraints won't work?

Roland,
Did I misinterpret what is happening? I understood you to say that when
your subprojects were inserted into a master, some of the tasks slammed
over to the Project Start date of the master, however (and I had to
confirm this with my own test), this will only occur if the subprojects
are statically consolidated into the master (i.e. subprojects not linked
to the master). In a dynamically consolidated master, the tasks in each
subproject adhere to the Project Start date of their respective
subprojects.

Perhaps we need a re-statement of what is happening before we can offer
other suggestions.

By the way, I understand about customer wants. I just hope they are not
looking for detail planning of any tasks beyond 12 months. Tasks beyond
the rule-of-thumb 12 month window should be expressed as "planning
packages". That is, they have a rough idea of Duration and perhaps even
cost, but no details. As time marches on and those out-year planning
packages get within 3 months of the present, then they should be detail
planned.

Just for reference, I am a firm believer that the constraint types
"must-start-on" and "must-finish-on" should never be used. When you get
down to it, they defy reality. It is said there are only two certainties
in life. One of them has to do with "rendering unto Caesar" and the
other has to do with the grim reaper. The "best laid plans" do not fit
into either category. Oops, there I am on that soapbox again. Sorry.

John
Project MVP

 

[Steve House [MVP]]

Jumping in here. You're sayin the client wants to know tasks all the way
out to completion in 2010. Perfectly reasonable. But something is putting
those tasks out there in 2008 and 2009 - if there was nothing driving the
dates, you could put them all tomorrow and get the project done now, not in
2010. But there is some tangible reason the task "Wax the Fids" is
scheduled in 2008 and not tomorrow beyond your just tossing a dart at a
calendar. The project plan should be a model that accumulates all of those
tangible reasons and advises you of the dates where you CAN schedule the
tasks, not just accepting from you a list of dates where you think you can
scheduled them. You don't tell it the dates, it calculates where they can
fall and then tells them to you - the difference being the direction that
the information about the dates flows.

 

[John]

Jumping in here. You're sayin the client wants to know tasks all the way
out to completion in 2010. Perfectly reasonable. But something is putting
those tasks out there in 2008 and 2009 - if there was nothing driving the
dates, you could put them all tomorrow and get the project done now, not in
2010. But there is some tangible reason the task "Wax the Fids" is
scheduled in 2008 and not tomorrow beyond your just tossing a dart at a
calendar. The project plan should be a model that accumulates all of those
tangible reasons and advises you of the dates where you CAN schedule the
tasks, not just accepting from you a list of dates where you think you can
scheduled them. You don't tell it the dates, it calculates where they can
fall and then tells them to you - the difference being the direction that
the information about the dates flows.

Steve<
"Wax the Fids"? That's a new one. Is a Fid part of a widget? Please
elaborate I just know there is some enlightening information I can learn
here.

John

 

[Steve House [MVP]]

Most factories can be converted to produce either widgets or fids but to be
viable for fids the waxing line has to be quite proficient. Fids need
waxing because they must be very, very smooth to be effective.

Actually, until Guinness introduced their widget-equipped can to hold back
the carbonation in the their products until opening, widgets and fids were
considered fictional products for economics classes. But in truth, there
really is a product called a "fid" that's been around hundreds of years.
It's a tool used in marlinspike seamanship for splicing lines and wire rope.
Looks like a very heavy duty needle but is constructed in such a way that is
it split or open on the blunt end and so can attach to a strand of a rope
sort of like a cap holding the strand longitudinally on the very end rather
than with it being threaded latterly through an eye. The marlinspike is a
pointy teardrop shaped thing that is used to pry the strands of the rope
apart and then fid can be threaded through the gap created pulling the
incoming strand along with it.

"The More You Know ..."


--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[John]

Most factories can be converted to produce either widgets or fids but to be
viable for fids the waxing line has to be quite proficient. Fids need
waxing because they must be very, very smooth to be effective.

Actually, until Guinness introduced their widget-equipped can to hold back
the carbonation in the their products until opening, widgets and fids were
considered fictional products for economics classes. But in truth, there
really is a product called a "fid" that's been around hundreds of years.
It's a tool used in marlinspike seamanship for splicing lines and wire rope.
Looks like a very heavy duty needle but is constructed in such a way that is
it split or open on the blunt end and so can attach to a strand of a rope
sort of like a cap holding the strand longitudinally on the very end rather
than with it being threaded latterly through an eye. The marlinspike is a
pointy teardrop shaped thing that is used to pry the strands of the rope
apart and then fid can be threaded through the gap created pulling the
incoming strand along with it.

"The More You Know ..."

Steve,
Thank you for that detailed enlightenment. Now I can tell my wife that I
learned something on the internet today. Wow!

Although I didn't mention it earlier, I too am aware of an actual item
called a fid but it is a little different than what you describe. The
one I am familiar with is much like an awl and is used to separate
compressed springs in a prototyping board. Perhaps it is a smaller,
later generation of the marlinspike.

"... less you have to learn."

John