Hold out on entering dates?

[Ethan]

Is there any way to construct tasks, durations, etc. in a template but not
enter dates?

We're a service company and many of our phases begin when clients send us
materials to begin formatting. It would be nice if those date fields could be
be blank, and then when entered, the rest of the project calcuates and fills
in the dates.

Is that possible?

 

[Jan De Messemaeker]

Hi Ethan,

The solid recommendation is to NEVER ENTER DATES in MS Project, whether
templates or not.
Enter tasks and durations, then relationships between tasks.
Project will calculate the rest.

And even if you have entered dates in a template, Project has the
functionality to do exactly what you want - recalculate all dates. On the
Analysis toolbar, click the Adjust dates button.

Project's first and foremost role is to CALCULATE dates. You're on the right
track.
HTH

 

[bob]

"The solid recommendation is to NEVER ENTER DATES in MS Project,"

But 90% of our world is nothing but dates.
We need to ship to Vendor A on this date, Vendor B picks up on this day, a
shipment arrives on this date, etc, etc for hundreds of lines. There is no
way around it.
We then try to work with these anchor dates and calculate the durations,
which we use for other purposes.

For example, I have a firm committment on say
1/1/05
and another hard date event or milestone on
3/1/05.

We then have to figure the duration, or gap, and then schedule other related
events in between. Our problem is this: Event 2 is predicted to be late,
say 3/10/05, and I have to know that new duration. I have not found any way
to do this without manualy clicking the duration until it matches the date.
Horrible effort, but we can't find another way.

 

[Jan De Messemaeker]

Hi,

Let's not argue on this, I see a different approach.
By all means, as I said, enter "logical" dates and when the syttart date is
known use Adjust dates from the toolbar.

HTH

 

[Steve House [Project MVP]]

90% of all projects are date critical but that doesn't mean you should
figure the dates outside of Project and pump them in as user input.
Remember that Project's reason for existence is to calculate the start and
finish dates of the tasks within your project. I like to think of it as
"you don't tell Project the dates you're going to work, it tells you the
dates you both SHOULD work and will BE ABLE to work." The fancy views and
Gantt charts are just frosting on a piece of schedule calculation software
but are not the reason it exists or the reason to use it.

When you enter dates in the Start and Finish columns for your tasks, the
Start date entry sets a "Start No Earlier Than" constraint and that says
that under no circumstances will the task ever be scheduled to start earlier
than that date. BUT it can be pushed later than that date no problem. The
same for entering a date in the Finish column - it sets a "Finish No Earlier
Than" constraint. If you enter both dates, the constraint is determined by
the last date entered.

Tasks can only happen when the predecessors and resources come together so
that everything required to do the work is in place. You might have a
commitment on 1/1/05 but the promise of delivery is not in itself enough to
make it happen - there are a myriad of other things that have to happen for
it all to come together on the 1st. Project's job is to take the was you
organized the work at the moment and tell you if you'll finish on schedule
or not. If not, it tells you the date you will hit the way things are
presently organized and a model that will let you experiment with changing
the organization - rearranging resources, for example - to come up with a
strategy that WILL have it hit the promised dates.

The hard dates you mention should be entered as deadlines. Project will
monitor them and tell you if the plan as you have presently entered it will
meet them or not. In the best of all possible worlds, you'd build the plan
in Project BEFORE agreeing to the commitment dates with the customer, prior
to negotiating the contracts, using the project schedule to determine what
is realistic and doable before promising the moon, but most of the time we
don't have that luxury unless you're lucky enough to work for a
project-driven company that has learned the wisdom of that approach.

I'm sure you feel that your situation is unique and you can't work the way
we suggest but believe me, it's not. If you try building the plan by
entering specific dates on which the tasks will take place it will be a
miracle if you end up with a usable schedule. I have yet to see an example
of such an approach that didn't end up with a "wishful thinking" plan that
bore no resemblance to what actually happened in reality when the project
was worked. Often it's a waste of the time spent building it because the
resulting plan was useless for real world work scheduling, failing to allow
proper progress monitoring, or to alert for emerging problems. Trust us,
you'll have a far better shot at hitting those "must hit" commitment dates
if you try it our way - we've been there before.

 

[bob]

Very well explained, and very accurate.
Thank you.
On those rare occasions when we have control over events, that is precisely
what we do.

 

[Steve House [Project MVP]]

I truly don't mean to sound argumenative here but I'm very confused. You
say you don't usually have control over events. Then what are you using
scheduling software to accomplish for you if your schedule has already been
predetermined? What do you do if your existing schedule says you need to be
polishing the fids during the first week of August but the polish supplier
says he can't deliver before September? Since MSP generates the task dates
it predicts from the information you have given it about the length of time
it will take to lay the foundations for the work and when the resources who
will do it are available, how do you handle to situation where the
predetermined schedule says something is supposed o happen over a certain
period of time by Project informs you it is physically impossible for it to
happen then?

I'll reiterate, the project schedule is not a list of required delivery
dates. Required dates should be entered as deadlines and not costraints.
The schedule then becomes a "what-if" analytic model that predicts what the
delivery dates would be IF you organized the work in a certain way. If the
resulting schedule meets your requirements, you're cool. If it doesn't, and
most of the time in the first draft it won't, you change the factors that
you realistcally control that drive the schedule such as the order you
perform the work if possible, the number of resources assigned to take, and
so forth until it does.

The object of the exercise is not just to list your objectives. It is to
create a tool that will help you figure out exactly what you need to do when
in order to meet those objectives. Entering fixed dates absolutely prevents
it from doing that properly.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Very well explained, and very accurate.
Thank you.
On those rare occasions when we have control over events, that is
precisely
what we do.

"Steve House [Project MVP]" <[email protected]>
wrote
in message news:%[email protected]...

90% of all projects are date critical but that doesn't mean you should
figure the dates outside of Project and pump them in as user input.
Remember that Project's reason for existence is to calculate the start
and
finish dates of the tasks within your project. I like to think of it as
"you don't tell Project the dates you're going to work, it tells you the
dates you both SHOULD work and will BE ABLE to work." The fancy views and
Gantt charts are just frosting on a piece of schedule calculation
software
but are not the reason it exists or the reason to use it.

When you enter dates in the Start and Finish columns for your tasks, the
Start date entry sets a "Start No Earlier Than" constraint and that says
that under no circumstances will the task ever be scheduled to start earlier
than that date. BUT it can be pushed later than that date no problem.
The
same for entering a date in the Finish column - it sets a "Finish No Earlier
Than" constraint. If you enter both dates, the constraint is determined by
the last date entered.

Tasks can only happen when the predecessors and resources come together
so
that everything required to do the work is in place. You might have a
commitment on 1/1/05 but the promise of delivery is not in itself enough to
make it happen - there are a myriad of other things that have to happen for
it all to come together on the 1st. Project's job is to take the was you
organized the work at the moment and tell you if you'll finish on
schedule
or not. If not, it tells you the date you will hit the way things are
presently organized and a model that will let you experiment with
changing
the organization - rearranging resources, for example - to come up with a
strategy that WILL have it hit the promised dates.

The hard dates you mention should be entered as deadlines. Project will
monitor them and tell you if the plan as you have presently entered it will
meet them or not. In the best of all possible worlds, you'd build the plan
in Project BEFORE agreeing to the commitment dates with the customer, prior
to negotiating the contracts, using the project schedule to determine
what
is realistic and doable before promising the moon, but most of the time
we
don't have that luxury unless you're lucky enough to work for a
project-driven company that has learned the wisdom of that approach.

I'm sure you feel that your situation is unique and you can't work the
way
we suggest but believe me, it's not. If you try building the plan by
entering specific dates on which the tasks will take place it will be a
miracle if you end up with a usable schedule. I have yet to see an example
of such an approach that didn't end up with a "wishful thinking" plan
that
bore no resemblance to what actually happened in reality when the project
was worked. Often it's a waste of the time spent building it because the
resulting plan was useless for real world work scheduling, failing to allow
proper progress monitoring, or to alert for emerging problems. Trust us,
you'll have a far better shot at hitting those "must hit" commitment
dates
if you try it our way - we've been there before.

 

[bob]

Not being argumentative either.

"Then what are you using scheduling software to accomplish for you if your
schedule has already been predetermined?"

I never said the schedule was predetermined. I said "dates" are
predetermined. Different critter entirely.

If vendor a's parts arrive on 1/1, and vendor b's on 2/1 and c's on 3/1, and
we need to assemble those parts into something else, then the earliest
possible date for complete assembly in 3/1+1. However, we can configure the
parts to begin assembly on 2/1 which is the earliest date that we have two
parts. It has to wait until 3/1 for the last part, but with planning, we can
have it 67% complete, assuming equal parts. We can then plan to ship the
final product on 3/1 + ??? days.

That is why durations count. If 3/1 is too late for the product, and the
cost of delay is high, then we can air ship those parts, arriving on 2/10
instead.

BTW: these "parts" are often large loads of raw steel, tons of it, and sea
ship is cheaper, unless the delay cost more than the accelerated shipping
cost.

That's one example of 100's, that we face every day.

A typical completed module, or product, might be 50-500 lines in MSP, so it
is a big help in sorting this out. We've never found a way to do it better,
except for Primavera, but we cannot expect our suppliers to lay out
thousands of dollars just so we can exchange schedules.

With some manual effort, MSP works okay enough.

I truly don't mean to sound argumenative here but I'm very confused. You
say you don't usually have control over events. Then what are you using
scheduling software to accomplish for you if your schedule has already been
predetermined? What do you do if your existing schedule says you need to be
polishing the fids during the first week of August but the polish supplier
says he can't deliver before September? Since MSP generates the task dates
it predicts from the information you have given it about the length of time
it will take to lay the foundations for the work and when the resources who
will do it are available, how do you handle to situation where the
predetermined schedule says something is supposed o happen over a certain
period of time by Project informs you it is physically impossible for it to
happen then?

I'll reiterate, the project schedule is not a list of required delivery
dates. Required dates should be entered as deadlines and not costraints.
The schedule then becomes a "what-if" analytic model that predicts what the
delivery dates would be IF you organized the work in a certain way. If the
resulting schedule meets your requirements, you're cool. If it doesn't, and
most of the time in the first draft it won't, you change the factors that
you realistcally control that drive the schedule such as the order you
perform the work if possible, the number of resources assigned to take, and
so forth until it does.

The object of the exercise is not just to list your objectives. It is to
create a tool that will help you figure out exactly what you need to do when
in order to meet those objectives. Entering fixed dates absolutely prevents
it from doing that properly.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Very well explained, and very accurate.
Thank you.
On those rare occasions when we have control over events, that is
precisely
what we do.

"Steve House [Project MVP]" <[email protected]>
wrote
in message news:%[email protected]...

90% of all projects are date critical but that doesn't mean you should
figure the dates outside of Project and pump them in as user input.
Remember that Project's reason for existence is to calculate the start
and
finish dates of the tasks within your project. I like to think of it as
"you don't tell Project the dates you're going to work, it tells you the
dates you both SHOULD work and will BE ABLE to work." The fancy views and
Gantt charts are just frosting on a piece of schedule calculation
software
but are not the reason it exists or the reason to use it.

When you enter dates in the Start and Finish columns for your tasks, the
Start date entry sets a "Start No Earlier Than" constraint and that says
that under no circumstances will the task ever be scheduled to start earlier
than that date. BUT it can be pushed later than that date no problem.
The
same for entering a date in the Finish column - it sets a "Finish No Earlier
Than" constraint. If you enter both dates, the constraint is

determined
by

the last date entered.

Tasks can only happen when the predecessors and resources come together
so
that everything required to do the work is in place. You might have a
commitment on 1/1/05 but the promise of delivery is not in itself

enough
to

make it happen - there are a myriad of other things that have to happen for
it all to come together on the 1st. Project's job is to take the was you
organized the work at the moment and tell you if you'll finish on
schedule
or not. If not, it tells you the date you will hit the way things are
presently organized and a model that will let you experiment with
changing
the organization - rearranging resources, for example - to come up with a
strategy that WILL have it hit the promised dates.

The hard dates you mention should be entered as deadlines. Project will
monitor them and tell you if the plan as you have presently entered it will
meet them or not. In the best of all possible worlds, you'd build the plan
in Project BEFORE agreeing to the commitment dates with the customer, prior
to negotiating the contracts, using the project schedule to determine
what
is realistic and doable before promising the moon, but most of the time
we
don't have that luxury unless you're lucky enough to work for a
project-driven company that has learned the wisdom of that approach.

I'm sure you feel that your situation is unique and you can't work the
way
we suggest but believe me, it's not. If you try building the plan by
entering specific dates on which the tasks will take place it will be a
miracle if you end up with a usable schedule. I have yet to see an example
of such an approach that didn't end up with a "wishful thinking" plan
that
bore no resemblance to what actually happened in reality when the project
was worked. Often it's a waste of the time spent building it because the
resulting plan was useless for real world work scheduling, failing to allow
proper progress monitoring, or to alert for emerging problems. Trust us,
you'll have a far better shot at hitting those "must hit" commitment
dates
if you try it our way - we've been there before.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs




"The solid recommendation is to NEVER ENTER DATES in MS Project,"

But 90% of our world is nothing but dates.
We need to ship to Vendor A on this date, Vendor B picks up on this
day, a
shipment arrives on this date, etc, etc for hundreds of lines. There

is
no

way around it.
We then try to work with these anchor dates and calculate the
durations,
which we use for other purposes.

For example, I have a firm committment on say
1/1/05
and another hard date event or milestone on
3/1/05.

We then have to figure the duration, or gap, and then schedule other
related
events in between. Our problem is this: Event 2 is predicted to be late,
say 3/10/05, and I have to know that new duration. I have not found
any
way
to do this without manualy clicking the duration until it matches the
date.
Horrible effort, but we can't find another way.




"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in message
Hi Ethan,

The solid recommendation is to NEVER ENTER DATES in MS Project,
whether
templates or not.
Enter tasks and durations, then relationships between tasks.
Project will calculate the rest.

And even if you have entered dates in a template, Project has the
functionality to do exactly what you want - recalculate all dates.

On
the

Analysis toolbar, click the Adjust dates button.

Project's first and foremost role is to CALCULATE dates. You're on the
right
track.
HTH
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
+32-495-300 620
"Ethan" <[email protected]> schreef in bericht
Is there any way to construct tasks, durations, etc. in a template but
not
enter dates?

We're a service company and many of our phases begin when clients send
us
materials to begin formatting. It would be nice if those date fields
could
be
be blank, and then when entered, the rest of the project calcuates and
fills
in the dates.

Is that possible?

 

[Steve House [Project MVP]]

What you are describing is indeed one of the very few situations where Start
No Earlier Than constraints actually do make sense. Since entering a start
date does, in fact, set a SNET constraint rather instead of fixing the start
date, what you're doing by "setting the start date" is exactly what I would
do, I'd just do it a slightly different manner. (Would I would NOT do is
use a Must Start ON constraint which does truly lock the start date to a
specific date - something that is almost never appropriate except when
things are scheduled around natural events not subject to human
intervention, like eclipses.)

Among the scheduling assumptions Project works best with is the idea that
the tasks are broken down to the level of the work performed by one skill
set that results in one specific deliverable. So I'd decompose your
schedule down to the point that if A & B can indeed be assembled together
and set aside to await C's arrival, that module constitutes a discrete
deliverable and thus "Assemble A&B" would be one task while "Join Module AB
with C" would be an entirely separate task. Before the first of those two
task's I'd enter 2 milestones, "Receive Parts A" with an SNET of 1/1 and
"Receive Parts B" with an SNET of 2/1. Both of those milestones would be
predecessors to Assembly Task 1 and their dates would determine the start
date of the first assembly task. Assembly task 1's schedule start would be
calculated from those milestones and its finish by its duration but it would
have no constraints, Project freely calculating its dates without any input
from us. There's also be a milestone "Receive Parts C" with an SNET of 3/1.
Assembly Task 2 would have predecessors of the finish of Assembly 1 and the
Receive C milestone. It would not have any constraints itself so that its
dates are determined by when the first assembly is done AND when the
required parts arrive. It would have no constraints but it WOULD have a
Deadline entry of the date your contract requires you to deliver it to your
customer. That way your actual working schedule dates are driven by the
availability of the parts and the time it takes to do the work. I suggest
that is a valid model of real-world work behaviour. The deadline sends you
a red flag if delays make it so you'll miss your shipdate with enough
advanced notice to actually have a chance to do something to fix it. Try an
experiment using this strategy and see if it helps develop a workable
schedule for you.


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

Not being argumentative either.

"Then what are you using scheduling software to accomplish for you if your
schedule has already been predetermined?"

I never said the schedule was predetermined. I said "dates" are
predetermined. Different critter entirely.

If vendor a's parts arrive on 1/1, and vendor b's on 2/1 and c's on 3/1,
and
we need to assemble those parts into something else, then the earliest
possible date for complete assembly in 3/1+1. However, we can configure
the
parts to begin assembly on 2/1 which is the earliest date that we have two
parts. It has to wait until 3/1 for the last part, but with planning, we
can
have it 67% complete, assuming equal parts. We can then plan to ship the
final product on 3/1 + ??? days.

That is why durations count. If 3/1 is too late for the product, and the
cost of delay is high, then we can air ship those parts, arriving on 2/10
instead.

BTW: these "parts" are often large loads of raw steel, tons of it, and sea
ship is cheaper, unless the delay cost more than the accelerated shipping
cost.

That's one example of 100's, that we face every day.

A typical completed module, or product, might be 50-500 lines in MSP, so
it
is a big help in sorting this out. We've never found a way to do it
better,
except for Primavera, but we cannot expect our suppliers to lay out
thousands of dollars just so we can exchange schedules.

With some manual effort, MSP works okay enough.

"Steve House [Project MVP]" <[email protected]>
wrote
in message news:%[email protected]...

I truly don't mean to sound argumenative here but I'm very confused. You
say you don't usually have control over events. Then what are you using
scheduling software to accomplish for you if your schedule has already been
predetermined? What do you do if your existing schedule says you need to be
polishing the fids during the first week of August but the polish
supplier
says he can't deliver before September? Since MSP generates the task dates
it predicts from the information you have given it about the length of time
it will take to lay the foundations for the work and when the resources who
will do it are available, how do you handle to situation where the
predetermined schedule says something is supposed o happen over a certain
period of time by Project informs you it is physically impossible for it to
happen then?

I'll reiterate, the project schedule is not a list of required delivery
dates. Required dates should be entered as deadlines and not costraints.
The schedule then becomes a "what-if" analytic model that predicts what the
delivery dates would be IF you organized the work in a certain way. If the
resulting schedule meets your requirements, you're cool. If it doesn't, and
most of the time in the first draft it won't, you change the factors that
you realistcally control that drive the schedule such as the order you
perform the work if possible, the number of resources assigned to take, and
so forth until it does.

The object of the exercise is not just to list your objectives. It is to
create a tool that will help you figure out exactly what you need to do when
in order to meet those objectives. Entering fixed dates absolutely prevents
it from doing that properly.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Very well explained, and very accurate.
Thank you.
On those rare occasions when we have control over events, that is
precisely
what we do.

"Steve House [Project MVP]" <[email protected]>
wrote
in message 90% of all projects are date critical but that doesn't mean you should
figure the dates outside of Project and pump them in as user input.
Remember that Project's reason for existence is to calculate the start
and
finish dates of the tasks within your project. I like to think of it as
"you don't tell Project the dates you're going to work, it tells you the
dates you both SHOULD work and will BE ABLE to work." The fancy
views
and
Gantt charts are just frosting on a piece of schedule calculation
software
but are not the reason it exists or the reason to use it.

When you enter dates in the Start and Finish columns for your tasks, the
Start date entry sets a "Start No Earlier Than" constraint and that says
that under no circumstances will the task ever be scheduled to start
earlier
than that date. BUT it can be pushed later than that date no problem.
The
same for entering a date in the Finish column - it sets a "Finish No
Earlier
Than" constraint. If you enter both dates, the constraint is determined
by
the last date entered.

Tasks can only happen when the predecessors and resources come
together
so
that everything required to do the work is in place. You might have a
commitment on 1/1/05 but the promise of delivery is not in itself enough
to
make it happen - there are a myriad of other things that have to
happen
for
it all to come together on the 1st. Project's job is to take the was you
organized the work at the moment and tell you if you'll finish on
schedule
or not. If not, it tells you the date you will hit the way things are
presently organized and a model that will let you experiment with
changing
the organization - rearranging resources, for example - to come up
with a
strategy that WILL have it hit the promised dates.

The hard dates you mention should be entered as deadlines. Project will
monitor them and tell you if the plan as you have presently entered it
will
meet them or not. In the best of all possible worlds, you'd build the
plan
in Project BEFORE agreeing to the commitment dates with the customer,
prior
to negotiating the contracts, using the project schedule to determine
what
is realistic and doable before promising the moon, but most of the
time
we
don't have that luxury unless you're lucky enough to work for a
project-driven company that has learned the wisdom of that approach.

I'm sure you feel that your situation is unique and you can't work the
way
we suggest but believe me, it's not. If you try building the plan by
entering specific dates on which the tasks will take place it will be
a
miracle if you end up with a usable schedule. I have yet to see an
example
of such an approach that didn't end up with a "wishful thinking" plan
that
bore no resemblance to what actually happened in reality when the project
was worked. Often it's a waste of the time spent building it because the
resulting plan was useless for real world work scheduling, failing to
allow
proper progress monitoring, or to alert for emerging problems. Trust us,
you'll have a far better shot at hitting those "must hit" commitment
dates
if you try it our way - we've been there before.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs




"The solid recommendation is to NEVER ENTER DATES in MS Project,"

But 90% of our world is nothing but dates.
We need to ship to Vendor A on this date, Vendor B picks up on this
day,
a
shipment arrives on this date, etc, etc for hundreds of lines. There is
no
way around it.
We then try to work with these anchor dates and calculate the
durations,
which we use for other purposes.

For example, I have a firm committment on say
1/1/05
and another hard date event or milestone on
3/1/05.

We then have to figure the duration, or gap, and then schedule other
related
events in between. Our problem is this: Event 2 is predicted to be
late,
say 3/10/05, and I have to know that new duration. I have not found
any
way
to do this without manualy clicking the duration until it matches
the
date.
Horrible effort, but we can't find another way.




"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in
message
Hi Ethan,

The solid recommendation is to NEVER ENTER DATES in MS Project,
whether
templates or not.
Enter tasks and durations, then relationships between tasks.
Project will calculate the rest.

And even if you have entered dates in a template, Project has the
functionality to do exactly what you want - recalculate all dates. On
the
Analysis toolbar, click the Adjust dates button.

Project's first and foremost role is to CALCULATE dates. You're on the
right
track.
HTH
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
+32-495-300 620
"Ethan" <[email protected]> schreef in bericht
Is there any way to construct tasks, durations, etc. in a
template
but
not
enter dates?

We're a service company and many of our phases begin when clients
send
us
materials to begin formatting. It would be nice if those date fields
could
be
be blank, and then when entered, the rest of the project
calcuates
and
fills
in the dates.

Is that possible?

 

[bob]

That is very good!
Thanks, I need to digest it a bit more, and then try next week.

bob

What you are describing is indeed one of the very few situations where Start
No Earlier Than constraints actually do make sense. Since entering a start
date does, in fact, set a SNET constraint rather instead of fixing the start
date, what you're doing by "setting the start date" is exactly what I would
do, I'd just do it a slightly different manner. (Would I would NOT do is
use a Must Start ON constraint which does truly lock the start date to a
specific date - something that is almost never appropriate except when
things are scheduled around natural events not subject to human
intervention, like eclipses.)

Among the scheduling assumptions Project works best with is the idea that
the tasks are broken down to the level of the work performed by one skill
set that results in one specific deliverable. So I'd decompose your
schedule down to the point that if A & B can indeed be assembled together
and set aside to await C's arrival, that module constitutes a discrete
deliverable and thus "Assemble A&B" would be one task while "Join Module AB
with C" would be an entirely separate task. Before the first of those two
task's I'd enter 2 milestones, "Receive Parts A" with an SNET of 1/1 and
"Receive Parts B" with an SNET of 2/1. Both of those milestones would be
predecessors to Assembly Task 1 and their dates would determine the start
date of the first assembly task. Assembly task 1's schedule start would be
calculated from those milestones and its finish by its duration but it would
have no constraints, Project freely calculating its dates without any input
from us. There's also be a milestone "Receive Parts C" with an SNET of 3/1.
Assembly Task 2 would have predecessors of the finish of Assembly 1 and the
Receive C milestone. It would not have any constraints itself so that its
dates are determined by when the first assembly is done AND when the
required parts arrive. It would have no constraints but it WOULD have a
Deadline entry of the date your contract requires you to deliver it to your
customer. That way your actual working schedule dates are driven by the
availability of the parts and the time it takes to do the work. I suggest
that is a valid model of real-world work behaviour. The deadline sends you
a red flag if delays make it so you'll miss your shipdate with enough
advanced notice to actually have a chance to do something to fix it. Try an
experiment using this strategy and see if it helps develop a workable
schedule for you.


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

Not being argumentative either.

"Then what are you using scheduling software to accomplish for you if your
schedule has already been predetermined?"

I never said the schedule was predetermined. I said "dates" are
predetermined. Different critter entirely.

If vendor a's parts arrive on 1/1, and vendor b's on 2/1 and c's on 3/1,
and
we need to assemble those parts into something else, then the earliest
possible date for complete assembly in 3/1+1. However, we can configure
the
parts to begin assembly on 2/1 which is the earliest date that we have two
parts. It has to wait until 3/1 for the last part, but with planning, we
can
have it 67% complete, assuming equal parts. We can then plan to ship the
final product on 3/1 + ??? days.

That is why durations count. If 3/1 is too late for the product, and the
cost of delay is high, then we can air ship those parts, arriving on 2/10
instead.

BTW: these "parts" are often large loads of raw steel, tons of it, and sea
ship is cheaper, unless the delay cost more than the accelerated shipping
cost.

That's one example of 100's, that we face every day.

A typical completed module, or product, might be 50-500 lines in MSP, so
it
is a big help in sorting this out. We've never found a way to do it
better,
except for Primavera, but we cannot expect our suppliers to lay out
thousands of dollars just so we can exchange schedules.

With some manual effort, MSP works okay enough.

"Steve House [Project MVP]" <[email protected]>
wrote
in message news:%[email protected]...

I truly don't mean to sound argumenative here but I'm very confused. You
say you don't usually have control over events. Then what are you using
scheduling software to accomplish for you if your schedule has already been
predetermined? What do you do if your existing schedule says you need

to
be

polishing the fids during the first week of August but the polish
supplier
says he can't deliver before September? Since MSP generates the task dates
it predicts from the information you have given it about the length of time
it will take to lay the foundations for the work and when the resources who
will do it are available, how do you handle to situation where the
predetermined schedule says something is supposed o happen over a certain
period of time by Project informs you it is physically impossible for

it
to

happen then?

I'll reiterate, the project schedule is not a list of required delivery
dates. Required dates should be entered as deadlines and not costraints.
The schedule then becomes a "what-if" analytic model that predicts what the
delivery dates would be IF you organized the work in a certain way. If the
resulting schedule meets your requirements, you're cool. If it

doesn't,
and

most of the time in the first draft it won't, you change the factors that
you realistcally control that drive the schedule such as the order you
perform the work if possible, the number of resources assigned to take, and
so forth until it does.

The object of the exercise is not just to list your objectives. It is to
create a tool that will help you figure out exactly what you need to do when
in order to meet those objectives. Entering fixed dates absolutely prevents
it from doing that properly.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


Very well explained, and very accurate.
Thank you.
On those rare occasions when we have control over events, that is
precisely
what we do.

"Steve House [Project MVP]" <[email protected]>
wrote
in message 90% of all projects are date critical but that doesn't mean you should
figure the dates outside of Project and pump them in as user input.
Remember that Project's reason for existence is to calculate the start
and
finish dates of the tasks within your project. I like to think of

it
as

"you don't tell Project the dates you're going to work, it tells you the
dates you both SHOULD work and will BE ABLE to work." The fancy
views
and
Gantt charts are just frosting on a piece of schedule calculation
software
but are not the reason it exists or the reason to use it.

When you enter dates in the Start and Finish columns for your tasks, the
Start date entry sets a "Start No Earlier Than" constraint and that says
that under no circumstances will the task ever be scheduled to start
earlier
than that date. BUT it can be pushed later than that date no problem.
The
same for entering a date in the Finish column - it sets a "Finish No
Earlier
Than" constraint. If you enter both dates, the constraint is determined
by
the last date entered.

Tasks can only happen when the predecessors and resources come
together
so
that everything required to do the work is in place. You might have a
commitment on 1/1/05 but the promise of delivery is not in itself enough
to
make it happen - there are a myriad of other things that have to
happen
for
it all to come together on the 1st. Project's job is to take the

was
you

organized the work at the moment and tell you if you'll finish on
schedule
or not. If not, it tells you the date you will hit the way things are
presently organized and a model that will let you experiment with
changing
the organization - rearranging resources, for example - to come up
with a
strategy that WILL have it hit the promised dates.

The hard dates you mention should be entered as deadlines. Project will
monitor them and tell you if the plan as you have presently entered it
will
meet them or not. In the best of all possible worlds, you'd build the
plan
in Project BEFORE agreeing to the commitment dates with the customer,
prior
to negotiating the contracts, using the project schedule to determine
what
is realistic and doable before promising the moon, but most of the
time
we
don't have that luxury unless you're lucky enough to work for a
project-driven company that has learned the wisdom of that approach.

I'm sure you feel that your situation is unique and you can't work the
way
we suggest but believe me, it's not. If you try building the plan by
entering specific dates on which the tasks will take place it will be
a
miracle if you end up with a usable schedule. I have yet to see an
example
of such an approach that didn't end up with a "wishful thinking" plan
that
bore no resemblance to what actually happened in reality when the project
was worked. Often it's a waste of the time spent building it

because
the

resulting plan was useless for real world work scheduling, failing to
allow
proper progress monitoring, or to alert for emerging problems.

Trust
us,

you'll have a far better shot at hitting those "must hit" commitment
dates
if you try it our way - we've been there before.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs




"The solid recommendation is to NEVER ENTER DATES in MS Project,"

But 90% of our world is nothing but dates.
We need to ship to Vendor A on this date, Vendor B picks up on this
day,
a
shipment arrives on this date, etc, etc for hundreds of lines.

There
is

no
way around it.
We then try to work with these anchor dates and calculate the
durations,
which we use for other purposes.

For example, I have a firm committment on say
1/1/05
and another hard date event or milestone on
3/1/05.

We then have to figure the duration, or gap, and then schedule other
related
events in between. Our problem is this: Event 2 is predicted to be
late,
say 3/10/05, and I have to know that new duration. I have not found
any
way
to do this without manualy clicking the duration until it matches
the
date.
Horrible effort, but we can't find another way.




"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in
message
Hi Ethan,

The solid recommendation is to NEVER ENTER DATES in MS Project,
whether
templates or not.
Enter tasks and durations, then relationships between tasks.
Project will calculate the rest.

And even if you have entered dates in a template, Project has the
functionality to do exactly what you want - recalculate all

dates.
On

the
Analysis toolbar, click the Adjust dates button.

Project's first and foremost role is to CALCULATE dates. You're

on
the

right
track.
HTH
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
+32-495-300 620
"Ethan" <[email protected]> schreef in bericht
Is there any way to construct tasks, durations, etc. in a
template
but
not
enter dates?

We're a service company and many of our phases begin when clients
send
us
materials to begin formatting. It would be nice if those date fields
could
be
be blank, and then when entered, the rest of the project
calcuates
and
fills
in the dates.

Is that possible?