Milestone Tasks and their successors  
Author Message
woemlavy





PostPosted: Wed Jan 07 07:14:00 CST 2004 Top

Microsoft Project >> Milestone Tasks and their successors

Hello

I have a Milestone Task with a date Wednesday 04/02/04.
Its successors have start dates Thursday 05/02/04.

On my colleague's High Level Schedule - from where these
activities have been manually copied - the successor tasks
both have start dates of Wednesday 04/02/04...which is
what I want mine to show.

Sorry - but I can't for the life of me find the option
that tells milestones not to push successor tasks to the
next day.

Hope you can help. Thanks very much

Elaine.

DotNet297  
 
 
Gérard





PostPosted: Wed Jan 07 07:14:00 CST 2004 Top

Microsoft Project >> Milestone Tasks and their successors Hello Elaine,

I guess that your milestone has a date constraint such as Must Finish On...
which takes place the evening at 17:00. So the successeur must start on the
next day.
Try the Must Start On constraint which takes place on the morning (08:00)

Hope this helps,

Gérard Ducouret



> Hello
>
> I have a Milestone Task with a date Wednesday 04/02/04.
> Its successors have start dates Thursday 05/02/04.
>
> On my colleague's High Level Schedule - from where these
> activities have been manually copied - the successor tasks
> both have start dates of Wednesday 04/02/04...which is
> what I want mine to show.
>
> Sorry - but I can't for the life of me find the option
> that tells milestones not to push successor tasks to the
> next day.
>
> Hope you can help. Thanks very much
>
> Elaine.


 
 
Steve





PostPosted: Wed Jan 07 08:39:39 CST 2004 Top

Microsoft Project >> Milestone Tasks and their successors Even better, avoid hard constraints like the plague. IMHO constraints
exist to model mandatory conditions and physical impossibilities, like
the fact Christmas Day must always start on 25 Dec, imposed on the plan
but not a part of it. The goals or objectives within a Project or
phase, like "Contract Negotiations are to be completed by 01 Feb," even
if expressed most strongly such as one's boss adding "and if it's not
you're fired!", is the function of deadlines, not constraints. A
constraint limits where Project can place the task. If predecessors or
resource limitations, etc, are going to drive a milestone past its
required deadline, I want to see that fact on the Gantt with the
milestone sitting on the date it *will* occur unless I do something to
fix it, *not* on the date where I *want* it to occur but won't hit with
the plan as it presently stands. Just saying something will happen on
or by a certain date is not in and of itself sufficient to make it
possible. If it's after its deadline, that's my cue that I need to get
to work and redo the plan. If I have a constraint on the milestone
though, it always obeys the constraint date condition whether or not
that can actually happen and I never get the alert telling me there's a
problem. I can easily end up blindly assuming all is well until it's
too late to do anything about it.

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





> Hello Elaine,
>
> I guess that your milestone has a date constraint such as Must Finish
On...
> which takes place the evening at 17:00. So the successeur must start
on the
> next day.
> Try the Must Start On constraint which takes place on the morning
(08:00)
>
> Hope this helps,
>
> Gérard Ducouret
>

de

> > Hello
> >
> > I have a Milestone Task with a date Wednesday 04/02/04.
> > Its successors have start dates Thursday 05/02/04.
> >
> > On my colleague's High Level Schedule - from where these
> > activities have been manually copied - the successor tasks
> > both have start dates of Wednesday 04/02/04...which is
> > what I want mine to show.
> >
> > Sorry - but I can't for the life of me find the option
> > that tells milestones not to push successor tasks to the
> > next day.
> >
> > Hope you can help. Thanks very much
> >
> > Elaine.
>
>


 
 
Gérard





PostPosted: Wed Jan 07 11:38:05 CST 2004 Top

Microsoft Project >> Milestone Tasks and their successors Hi Steve,

I agree when you say "avoid hard constraints like the plague". I fight
everyday with project managers for that.
But sometime you really have date constraints, and generally they are hard
constraints.
In automotive industry, there are some milestones which are not negotiable.
I knew a Project Director who has been brought to negociate a delay on some
milestones. He obtained satisfaction because the management was in front of
the "fait accompli". But at the end of the meeting, he was no more Project
Director.
NB : It's very easy to display (graphically) the negative Total Slack in the
Gantt Chart. So you always see if your schedule is in time or not ! And you
see *all the tasks* on which you can work to come back within the date
constraint.

Gérard



> Even better, avoid hard constraints like the plague. IMHO constraints
> exist to model mandatory conditions and physical impossibilities, like
> the fact Christmas Day must always start on 25 Dec, imposed on the plan
> but not a part of it. The goals or objectives within a Project or
> phase, like "Contract Negotiations are to be completed by 01 Feb," even
> if expressed most strongly such as one's boss adding "and if it's not
> you're fired!", is the function of deadlines, not constraints. A
> constraint limits where Project can place the task. If predecessors or
> resource limitations, etc, are going to drive a milestone past its
> required deadline, I want to see that fact on the Gantt with the
> milestone sitting on the date it *will* occur unless I do something to
> fix it, *not* on the date where I *want* it to occur but won't hit with
> the plan as it presently stands. Just saying something will happen on
> or by a certain date is not in and of itself sufficient to make it
> possible. If it's after its deadline, that's my cue that I need to get
> to work and redo the plan. If I have a constraint on the milestone
> though, it always obeys the constraint date condition whether or not
> that can actually happen and I never get the alert telling me there's a
> problem. I can easily end up blindly assuming all is well until it's
> too late to do anything about it.
>
> --
> Steve House
> MS Project MVP
> Visit http://www.mvps.org/project/faqs.htm for the FAQs
>
>
>


> > Hello Elaine,
> >
> > I guess that your milestone has a date constraint such as Must Finish
> On...
> > which takes place the evening at 17:00. So the successeur must start
> on the
> > next day.
> > Try the Must Start On constraint which takes place on the morning
> (08:00)
> >
> > Hope this helps,
> >
> > Gérard Ducouret
> >

> de

> > > Hello
> > >
> > > I have a Milestone Task with a date Wednesday 04/02/04.
> > > Its successors have start dates Thursday 05/02/04.
> > >
> > > On my colleague's High Level Schedule - from where these
> > > activities have been manually copied - the successor tasks
> > > both have start dates of Wednesday 04/02/04...which is
> > > what I want mine to show.
> > >
> > > Sorry - but I can't for the life of me find the option
> > > that tells milestones not to push successor tasks to the
> > > next day.
> > >
> > > Hope you can help. Thanks very much
> > >
> > > Elaine.
> >
> >
>
>


 
 
Steve





PostPosted: Wed Jan 07 14:11:43 CST 2004 Top

Microsoft Project >> Milestone Tasks and their successors I never said the milestones were negotiable. In the real world they
aren't, more often than not. But what we see on the computer screen
when looking at the project file is not the real world, it is a model of
the real world and that is a major distinction that is often lost. The
real world dictates what we must do, its milestones - which really do
have constraints - indicate what we NEED to get. The plan, OTOH,
predicts what we're GOING to get, for better or worse, if we try to do
it in the way we've modeled the work. If those calculated results do
not conform to the needs of our project, we need to change the parts of
the model that drive those unacceptable results until they do. Our
problem then is to manipulate the controllable parts of that model so
that the calculated milestones indicated in the plan fall on or before
the mandatory milestones that we must hit when we actually work the
project in the real world. If we are going to effectively use the plan
for this sort of "what-if" modeling, we must see what happens to the
calculated milestones when we change one of the determinants that drive
them, whether that change is in the right direction or the wrong one.
Perhaps we should stop calling it a "plan" at all and instead call it a
"prediction" at least up until it's finalized and signed off as being
ready to go. Move over Miss Cleo!

Here's what I see as the problem with constraints. Take the simplest
case - we have to create 100 widgets. We have 1 person to do it with
and he can create a maximum of 10 a day - that's determined by the
physics of creating widgets and we simply have to accept that as a given
and base everything else on that fact. But the boss has said we must be
complete in 5 days. So we put that into our plan as a task of 10 days

milestone linked as a successor and the milestone has a "must finish on"
or "must finish no later than" constraint 5 days away. What does our
plan show? It shows the milestone happening right on time even though
the task that determines what we're really going to get doesn't finish
for another 5 days! Now in this case we can see the problem easily
because the predecessor is just above the milestone but imagine the more
usual case where that widget task is 25 or 50 lines above the milestone
in the task list ... when looking at the milestone the arrow coming from
its predecessor comes straight down into the screen from the top and
looks perfectly normal, the "hook" to the right to connect to the end of
the predecessor that is finishing after the milestone indicates it is is
way up under the predecessor and invisible when looking at the milestone
task. So the boss says "How about it? Are we going to make schedule?"
I look for the milestone in the project plan, see it's sitting there on
the required date, and happily tell the boss "No Problem, right on
time!" So what's going to happen 5 days from now? At 10 widgets a day,
the max one person can do, we've actually only done 50 and have to go to
the boss with the news that we're only halfway there. Not exactly a
career enhancing move. What should we have done? We should NOT have
put the constraint on to begin with and used a deadline instead ! Then
when we entered our plan we would have seen a couple of things
differently - first of all there would be a big red flag next to
milestone warning us there's a problem. Secondly we would have seen the
milestone diamond sitting 5 days to the right of the deadline arrowhead,
telling us exactly how bad the problem is. Now when the boss asks if
we're going to make schedule, we can tell him with confidence "Not with
only one guy working on it but if you can convince the manager of
manufacturing to lend us an extra widget expert to help out, we can make
it." Now our plan is not just a pretty picture of our hopes for the
project, it's giving us the concrete information we need in order to
make the effective managerial decisions necessary to achieve those
objectives - in this case, to meet our required milestone we *have* to
get more resources or live with the late delivery - there are no other
options.

So where would I use a constraint? I need to ship a boatload of iron
ore to Europe. The ice won't break up in the lake and Seaway until
April so the boat can't move until then. I'd model that physical
reality in the plan with a "Start No Earlier Than" constraint on the
task. Even if we're loaded and ready to go on New Years day, it simply
cannot happen until at least April no matter what and the plan should
reflect that. That, to my way of thinking, is the proper use of
constraints.

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






> Hi Steve,
>
> I agree when you say "avoid hard constraints like the plague". I fight
> everyday with project managers for that.
> But sometime you really have date constraints, and generally they are
hard
> constraints.
> In automotive industry, there are some milestones which are not
negotiable.
> I knew a Project Director who has been brought to negociate a delay on
some
> milestones. He obtained satisfaction because the management was in
front of
> the "fait accompli". But at the end of the meeting, he was no more
Project
> Director.
> NB : It's very easy to display (graphically) the negative Total Slack
in the
> Gantt Chart. So you always see if your schedule is in time or not !
And you
> see *all the tasks* on which you can work to come back within the
date10
> constraint.
>
> Gérard
>

le

> > Even better, avoid hard constraints like the plague. IMHO
constraints
> > exist to model mandatory conditions and physical impossibilities,
like
> > the fact Christmas Day must always start on 25 Dec, imposed on the
plan
> > but not a part of it. The goals or objectives within a Project or
> > phase, like "Contract Negotiations are to be completed by 01 Feb,"
even
> > if expressed most strongly such as one's boss adding "and if it's
not
> > you're fired!", is the function of deadlines, not constraints. A
> > constraint limits where Project can place the task. If predecessors
or
> > resource limitations, etc, are going to drive a milestone past its
> > required deadline, I want to see that fact on the Gantt with the
> > milestone sitting on the date it *will* occur unless I do something
to
> > fix it, *not* on the date where I *want* it to occur but won't hit
with
> > the plan as it presently stands. Just saying something will happen
on
> > or by a certain date is not in and of itself sufficient to make it
> > possible. If it's after its deadline, that's my cue that I need to
get
> > to work and redo the plan. If I have a constraint on the milestone
> > though, it always obeys the constraint date condition whether or not
> > that can actually happen and I never get the alert telling me
there's a
> > problem. I can easily end up blindly assuming all is well until
it's
> > too late to do anything about it.
> >
> > --
> > Steve House
> > MS Project MVP
> > Visit http://www.mvps.org/project/faqs.htm for the FAQs
> >
> >
> >

message

> > > Hello Elaine,
> > >
> > > I guess that your milestone has a date constraint such as Must
Finish
> > On...
> > > which takes place the evening at 17:00. So the successeur must
start
> > on the
> > > next day.
> > > Try the Must Start On constraint which takes place on the morning
> > (08:00)
> > >
> > > Hope this helps,
> > >
> > > Gérard Ducouret
> > >

message
> > de

> > > > Hello
> > > >
> > > > I have a Milestone Task with a date Wednesday 04/02/04.
> > > > Its successors have start dates Thursday 05/02/04.
> > > >
> > > > On my colleague's High Level Schedule - from where these
> > > > activities have been manually copied - the successor tasks
> > > > both have start dates of Wednesday 04/02/04...which is
> > > > what I want mine to show.
> > > >
> > > > Sorry - but I can't for the life of me find the option
> > > > that tells milestones not to push successor tasks to the
> > > > next day.
> > > >
> > > > Hope you can help. Thanks very much
> > > >
> > > > Elaine.
> > >
> > >
> >
> >
>
>


 
 
Gérard





PostPosted: Thu Jan 08 14:04:31 CST 2004 Top

Microsoft Project >> Milestone Tasks and their successors Hello Steve,

I agree with almost everything you explain. I just point out that with a
hard constraint (Finish Not Later Than for ex.) *and* the display of
negative Total Slack (From Late Finish ... To Finish in the Bar Styles
dialog) you have good visible warnings if you hit the milestone.
Furthermore, you immediately see how severe is the problem (Deadline too, I
agree) but the more interesting is that you see what are the sequences of
tasks you have to improve : "imagine the more usual case where that widget
task is 25 or 50 lines above the milestone in the task list" : with this
graphical negative slack you immediately see that the problem concerns tasks
25, 26 and task 50 .

Sincerely,

Gérard



> I never said the milestones were negotiable. In the real world they
> aren't, more often than not. But what we see on the computer screen
> when looking at the project file is not the real world, it is a model of
> the real world and that is a major distinction that is often lost. The
> real world dictates what we must do, its milestones - which really do
> have constraints - indicate what we NEED to get. The plan, OTOH,
> predicts what we're GOING to get, for better or worse, if we try to do
> it in the way we've modeled the work. If those calculated results do
> not conform to the needs of our project, we need to change the parts of
> the model that drive those unacceptable results until they do. Our
> problem then is to manipulate the controllable parts of that model so
> that the calculated milestones indicated in the plan fall on or before
> the mandatory milestones that we must hit when we actually work the
> project in the real world. If we are going to effectively use the plan
> for this sort of "what-if" modeling, we must see what happens to the
> calculated milestones when we change one of the determinants that drive
> them, whether that change is in the right direction or the wrong one.
> Perhaps we should stop calling it a "plan" at all and instead call it a
> "prediction" at least up until it's finalized and signed off as being
> ready to go. Move over Miss Cleo!
>
> Here's what I see as the problem with constraints. Take the simplest
> case - we have to create 100 widgets. We have 1 person to do it with
> and he can create a maximum of 10 a day - that's determined by the
> physics of creating widgets and we simply have to accept that as a given
> and base everything else on that fact. But the boss has said we must be
> complete in 5 days. So we put that into our plan as a task of 10 days

> milestone linked as a successor and the milestone has a "must finish on"
> or "must finish no later than" constraint 5 days away. What does our
> plan show? It shows the milestone happening right on time even though
> the task that determines what we're really going to get doesn't finish
> for another 5 days! Now in this case we can see the problem easily
> because the predecessor is just above the milestone but imagine the more
> usual case where that widget task is 25 or 50 lines above the milestone
> in the task list ... when looking at the milestone the arrow coming from
> its predecessor comes straight down into the screen from the top and
> looks perfectly normal, the "hook" to the right to connect to the end of
> the predecessor that is finishing after the milestone indicates it is is
> way up under the predecessor and invisible when looking at the milestone
> task. So the boss says "How about it? Are we going to make schedule?"
> I look for the milestone in the project plan, see it's sitting there on
> the required date, and happily tell the boss "No Problem, right on
> time!" So what's going to happen 5 days from now? At 10 widgets a day,
> the max one person can do, we've actually only done 50 and have to go to
> the boss with the news that we're only halfway there. Not exactly a
> career enhancing move. What should we have done? We should NOT have
> put the constraint on to begin with and used a deadline instead ! Then
> when we entered our plan we would have seen a couple of things
> differently - first of all there would be a big red flag next to
> milestone warning us there's a problem. Secondly we would have seen the
> milestone diamond sitting 5 days to the right of the deadline arrowhead,
> telling us exactly how bad the problem is. Now when the boss asks if
> we're going to make schedule, we can tell him with confidence "Not with
> only one guy working on it but if you can convince the manager of
> manufacturing to lend us an extra widget expert to help out, we can make
> it." Now our plan is not just a pretty picture of our hopes for the
> project, it's giving us the concrete information we need in order to
> make the effective managerial decisions necessary to achieve those
> objectives - in this case, to meet our required milestone we *have* to
> get more resources or live with the late delivery - there are no other
> options.
>
> So where would I use a constraint? I need to ship a boatload of iron
> ore to Europe. The ice won't break up in the lake and Seaway until
> April so the boat can't move until then. I'd model that physical
> reality in the plan with a "Start No Earlier Than" constraint on the
> task. Even if we're loaded and ready to go on New Years day, it simply
> cannot happen until at least April no matter what and the plan should
> reflect that. That, to my way of thinking, is the proper use of
> constraints.
>
> --
> Steve House
> MS Project MVP
> Visit http://www.mvps.org/project/faqs.htm for the FAQs
>
>
>
>


> > Hi Steve,
> >
> > I agree when you say "avoid hard constraints like the plague". I fight
> > everyday with project managers for that.
> > But sometime you really have date constraints, and generally they are
> hard
> > constraints.
> > In automotive industry, there are some milestones which are not
> negotiable.
> > I knew a Project Director who has been brought to negociate a delay on
> some
> > milestones. He obtained satisfaction because the management was in
> front of
> > the "fait accompli". But at the end of the meeting, he was no more
> Project
> > Director.
> > NB : It's very easy to display (graphically) the negative Total Slack
> in the
> > Gantt Chart. So you always see if your schedule is in time or not !
> And you
> > see *all the tasks* on which you can work to come back within the
> date10
> > constraint.
> >
> > Gérard
> >

> le

> > > Even better, avoid hard constraints like the plague. IMHO
> constraints
> > > exist to model mandatory conditions and physical impossibilities,
> like
> > > the fact Christmas Day must always start on 25 Dec, imposed on the
> plan
> > > but not a part of it. The goals or objectives within a Project or
> > > phase, like "Contract Negotiations are to be completed by 01 Feb,"
> even
> > > if expressed most strongly such as one's boss adding "and if it's
> not
> > > you're fired!", is the function of deadlines, not constraints. A
> > > constraint limits where Project can place the task. If predecessors
> or
> > > resource limitations, etc, are going to drive a milestone past its
> > > required deadline, I want to see that fact on the Gantt with the
> > > milestone sitting on the date it *will* occur unless I do something
> to
> > > fix it, *not* on the date where I *want* it to occur but won't hit
> with
> > > the plan as it presently stands. Just saying something will happen
> on
> > > or by a certain date is not in and of itself sufficient to make it
> > > possible. If it's after its deadline, that's my cue that I need to
> get
> > > to work and redo the plan. If I have a constraint on the milestone
> > > though, it always obeys the constraint date condition whether or not
> > > that can actually happen and I never get the alert telling me
> there's a
> > > problem. I can easily end up blindly assuming all is well until
> it's
> > > too late to do anything about it.
> > >
> > > --
> > > Steve House
> > > MS Project MVP
> > > Visit http://www.mvps.org/project/faqs.htm for the FAQs
> > >
> > >
> > >

> message

> > > > Hello Elaine,
> > > >
> > > > I guess that your milestone has a date constraint such as Must
> Finish
> > > On...
> > > > which takes place the evening at 17:00. So the successeur must
> start
> > > on the
> > > > next day.
> > > > Try the Must Start On constraint which takes place on the morning
> > > (08:00)
> > > >
> > > > Hope this helps,
> > > >
> > > > Gérard Ducouret
> > > >

> message
> > > de

> > > > > Hello
> > > > >
> > > > > I have a Milestone Task with a date Wednesday 04/02/04.
> > > > > Its successors have start dates Thursday 05/02/04.
> > > > >
> > > > > On my colleague's High Level Schedule - from where these
> > > > > activities have been manually copied - the successor tasks
> > > > > both have start dates of Wednesday 04/02/04...which is
> > > > > what I want mine to show.
> > > > >
> > > > > Sorry - but I can't for the life of me find the option
> > > > > that tells milestones not to push successor tasks to the
> > > > > next day.
> > > > >
> > > > > Hope you can help. Thanks very much
> > > > >
> > > > > Elaine.
> > > >
> > > >
> > >
> > >
> >
> >
>
>


 
 
Steve





PostPosted: Thu Jan 08 16:53:15 CST 2004 Top

Microsoft Project >> Milestone Tasks and their successors True enough - what it doesn't give you though is the direct indication
of the date you WILL hit unless you change something.

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




> Hello Steve,
>
> I agree with almost everything you explain. I just point out that with
a
> hard constraint (Finish Not Later Than for ex.) *and* the display of
> negative Total Slack (From Late Finish ... To Finish in the Bar Styles
> dialog) you have good visible warnings if you hit the milestone.
> Furthermore, you immediately see how severe is the problem (Deadline
too, I
> agree) but the more interesting is that you see what are the sequences
of
> tasks you have to improve : "imagine the more usual case where that
widget
> task is 25 or 50 lines above the milestone in the task list" : with
this
> graphical negative slack you immediately see that the problem concerns
tasks
> 25, 26 and task 50 .
>
> Sincerely,
>
> Gérard
>

le

> > I never said the milestones were negotiable. In the real world they
> > aren't, more often than not. But what we see on the computer screen
> > when looking at the project file is not the real world, it is a
model of
> > the real world and that is a major distinction that is often lost.
The
> > real world dictates what we must do, its milestones - which really
do
> > have constraints - indicate what we NEED to get. The plan, OTOH,
> > predicts what we're GOING to get, for better or worse, if we try to
do
> > it in the way we've modeled the work. If those calculated results
do
> > not conform to the needs of our project, we need to change the parts
of
> > the model that drive those unacceptable results until they do. Our
> > problem then is to manipulate the controllable parts of that model
so
> > that the calculated milestones indicated in the plan fall on or
before
> > the mandatory milestones that we must hit when we actually work the
> > project in the real world. If we are going to effectively use the
plan
> > for this sort of "what-if" modeling, we must see what happens to the
> > calculated milestones when we change one of the determinants that
drive
> > them, whether that change is in the right direction or the wrong
one.
> > Perhaps we should stop calling it a "plan" at all and instead call
it a
> > "prediction" at least up until it's finalized and signed off as
being
> > ready to go. Move over Miss Cleo!
> >
> > Here's what I see as the problem with constraints. Take the
simplest
> > case - we have to create 100 widgets. We have 1 person to do it
with
> > and he can create a maximum of 10 a day - that's determined by the
> > physics of creating widgets and we simply have to accept that as a
given
> > and base everything else on that fact. But the boss has said we
must be
> > complete in 5 days. So we put that into our plan as a task of 10
days

> > milestone linked as a successor and the milestone has a "must finish
on"
> > or "must finish no later than" constraint 5 days away. What does
our
> > plan show? It shows the milestone happening right on time even
though
> > the task that determines what we're really going to get doesn't
finish
> > for another 5 days! Now in this case we can see the problem easily
> > because the predecessor is just above the milestone but imagine the
more
> > usual case where that widget task is 25 or 50 lines above the
milestone
> > in the task list ... when looking at the milestone the arrow coming
from
> > its predecessor comes straight down into the screen from the top and
> > looks perfectly normal, the "hook" to the right to connect to the
end of
> > the predecessor that is finishing after the milestone indicates it
is is
> > way up under the predecessor and invisible when looking at the
milestone
> > task. So the boss says "How about it? Are we going to make
schedule?"
> > I look for the milestone in the project plan, see it's sitting there
on
> > the required date, and happily tell the boss "No Problem, right on
> > time!" So what's going to happen 5 days from now? At 10 widgets a
day,
> > the max one person can do, we've actually only done 50 and have to
go to
> > the boss with the news that we're only halfway there. Not exactly a
> > career enhancing move. What should we have done? We should NOT
have
> > put the constraint on to begin with and used a deadline instead !
Then
> > when we entered our plan we would have seen a couple of things
> > differently - first of all there would be a big red flag next to
> > milestone warning us there's a problem. Secondly we would have seen
the
> > milestone diamond sitting 5 days to the right of the deadline
arrowhead,
> > telling us exactly how bad the problem is. Now when the boss asks
if
> > we're going to make schedule, we can tell him with confidence "Not
with
> > only one guy working on it but if you can convince the manager of
> > manufacturing to lend us an extra widget expert to help out, we can
make
> > it." Now our plan is not just a pretty picture of our hopes for
the
> > project, it's giving us the concrete information we need in order to
> > make the effective managerial decisions necessary to achieve those
> > objectives - in this case, to meet our required milestone we *have*
to
> > get more resources or live with the late delivery - there are no
other
> > options.
> >
> > So where would I use a constraint? I need to ship a boatload of
iron
> > ore to Europe. The ice won't break up in the lake and Seaway until
> > April so the boat can't move until then. I'd model that physical
> > reality in the plan with a "Start No Earlier Than" constraint on the
> > task. Even if we're loaded and ready to go on New Years day, it
simply
> > cannot happen until at least April no matter what and the plan
should
> > reflect that. That, to my way of thinking, is the proper use of
> > constraints.
> >
> > --
> > Steve House
> > MS Project MVP
> > Visit http://www.mvps.org/project/faqs.htm for the FAQs
> >
> >
> >
> >

message

> > > Hi Steve,
> > >
> > > I agree when you say "avoid hard constraints like the plague". I
fight
> > > everyday with project managers for that.
> > > But sometime you really have date constraints, and generally they
are
> > hard
> > > constraints.
> > > In automotive industry, there are some milestones which are not
> > negotiable.
> > > I knew a Project Director who has been brought to negociate a
delay on
> > some
> > > milestones. He obtained satisfaction because the management was in
> > front of
> > > the "fait accompli". But at the end of the meeting, he was no more
> > Project
> > > Director.
> > > NB : It's very easy to display (graphically) the negative Total
Slack
> > in the
> > > Gantt Chart. So you always see if your schedule is in time or not
!
> > And you
> > > see *all the tasks* on which you can work to come back within the
> > date10
> > > constraint.
> > >
> > > Gérard
> > >

dans
> > le

> > > > Even better, avoid hard constraints like the plague. IMHO
> > constraints
> > > > exist to model mandatory conditions and physical
impossibilities,
> > like
> > > > the fact Christmas Day must always start on 25 Dec, imposed on
the
> > plan
> > > > but not a part of it. The goals or objectives within a Project
or
> > > > phase, like "Contract Negotiations are to be completed by 01
Feb,"
> > even
> > > > if expressed most strongly such as one's boss adding "and if
it's
> > not
> > > > you're fired!", is the function of deadlines, not constraints.
A
> > > > constraint limits where Project can place the task. If
predecessors
> > or
> > > > resource limitations, etc, are going to drive a milestone past
its
> > > > required deadline, I want to see that fact on the Gantt with the
> > > > milestone sitting on the date it *will* occur unless I do
something
> > to
> > > > fix it, *not* on the date where I *want* it to occur but won't
hit
> > with
> > > > the plan as it presently stands. Just saying something will
happen
> > on
> > > > or by a certain date is not in and of itself sufficient to make
it
> > > > possible. If it's after its deadline, that's my cue that I
need to
> > get
> > > > to work and redo the plan. If I have a constraint on the
milestone
> > > > though, it always obeys the constraint date condition whether or
not
> > > > that can actually happen and I never get the alert telling me
> > there's a
> > > > problem. I can easily end up blindly assuming all is well until
> > it's
> > > > too late to do anything about it.
> > > >
> > > > --
> > > > Steve House
> > > > MS Project MVP
> > > > Visit http://www.mvps.org/project/faqs.htm for the FAQs
> > > >
> > > >
> > > >

> > message

> > > > > Hello Elaine,
> > > > >
> > > > > I guess that your milestone has a date constraint such as Must
> > Finish
> > > > On...
> > > > > which takes place the evening at 17:00. So the successeur must
> > start
> > > > on the
> > > > > next day.
> > > > > Try the Must Start On constraint which takes place on the
morning
> > > > (08:00)
> > > > >
> > > > > Hope this helps,
> > > > >
> > > > > Gérard Ducouret
> > > > >

> > message
> > > > de

> > > > > > Hello
> > > > > >
> > > > > > I have a Milestone Task with a date Wednesday 04/02/04.
> > > > > > Its successors have start dates Thursday 05/02/04.
> > > > > >
> > > > > > On my colleague's High Level Schedule - from where these
> > > > > > activities have been manually copied - the successor tasks
> > > > > > both have start dates of Wednesday 04/02/04...which is
> > > > > > what I want mine to show.
> > > > > >
> > > > > > Sorry - but I can't for the life of me find the option
> > > > > > that tells milestones not to push successor tasks to the
> > > > > > next day.
> > > > > >
> > > > > > Hope you can help. Thanks very much
> > > > > >
> > > > > > Elaine.
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>


 
 
Jan





PostPosted: Fri Jan 09 11:35:16 CST 2004 Top

Microsoft Project >> Milestone Tasks and their successors Hi Steve,

Some despair is coming up, because I have at least told you 5 times alreeady
that you see when the TASK is scheduled to be finished that is linked to the
fixed milestone.

You really fight an isolated fight, you know, people all over the world use
fixd dates on milestone, it simply is more visible than deadline dates.

Greetings,
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
Project Management Consultancy
Prom+ade BVBA
32-495-300 620


> True enough - what it doesn't give you though is the direct indication
> of the date you WILL hit unless you change something.
>
> --
> Steve House
> MS Project MVP
> Visit http://www.mvps.org/project/faqs.htm for the FAQs
>
>


> > Hello Steve,
> >
> > I agree with almost everything you explain. I just point out that with
> a
> > hard constraint (Finish Not Later Than for ex.) *and* the display of
> > negative Total Slack (From Late Finish ... To Finish in the Bar Styles
> > dialog) you have good visible warnings if you hit the milestone.
> > Furthermore, you immediately see how severe is the problem (Deadline
> too, I
> > agree) but the more interesting is that you see what are the sequences
> of
> > tasks you have to improve : "imagine the more usual case where that
> widget
> > task is 25 or 50 lines above the milestone in the task list" : with
> this
> > graphical negative slack you immediately see that the problem concerns
> tasks
> > 25, 26 and task 50 .
> >
> > Sincerely,
> >
> > Gérard
> >

> le

> > > I never said the milestones were negotiable. In the real world they
> > > aren't, more often than not. But what we see on the computer screen
> > > when looking at the project file is not the real world, it is a
> model of
> > > the real world and that is a major distinction that is often lost.
> The
> > > real world dictates what we must do, its milestones - which really
> do
> > > have constraints - indicate what we NEED to get. The plan, OTOH,
> > > predicts what we're GOING to get, for better or worse, if we try to
> do
> > > it in the way we've modeled the work. If those calculated results
> do
> > > not conform to the needs of our project, we need to change the parts
> of
> > > the model that drive those unacceptable results until they do. Our
> > > problem then is to manipulate the controllable parts of that model
> so
> > > that the calculated milestones indicated in the plan fall on or
> before
> > > the mandatory milestones that we must hit when we actually work the
> > > project in the real world. If we are going to effectively use the
> plan
> > > for this sort of "what-if" modeling, we must see what happens to the
> > > calculated milestones when we change one of the determinants that
> drive
> > > them, whether that change is in the right direction or the wrong
> one.
> > > Perhaps we should stop calling it a "plan" at all and instead call
> it a
> > > "prediction" at least up until it's finalized and signed off as
> being
> > > ready to go. Move over Miss Cleo!
> > >
> > > Here's what I see as the problem with constraints. Take the
> simplest
> > > case - we have to create 100 widgets. We have 1 person to do it
> with
> > > and he can create a maximum of 10 a day - that's determined by the
> > > physics of creating widgets and we simply have to accept that as a
> given
> > > and base everything else on that fact. But the boss has said we
> must be
> > > complete in 5 days. So we put that into our plan as a task of 10
> days

> > > milestone linked as a successor and the milestone has a "must finish
> on"
> > > or "must finish no later than" constraint 5 days away. What does
> our
> > > plan show? It shows the milestone happening right on time even
> though
> > > the task that determines what we're really going to get doesn't
> finish
> > > for another 5 days! Now in this case we can see the problem easily
> > > because the predecessor is just above the milestone but imagine the
> more
> > > usual case where that widget task is 25 or 50 lines above the
> milestone
> > > in the task list ... when looking at the milestone the arrow coming
> from
> > > its predecessor comes straight down into the screen from the top and
> > > looks perfectly normal, the "hook" to the right to connect to the
> end of
> > > the predecessor that is finishing after the milestone indicates it
> is is
> > > way up under the predecessor and invisible when looking at the
> milestone
> > > task. So the boss says "How about it? Are we going to make
> schedule?"
> > > I look for the milestone in the project plan, see it's sitting there
> on
> > > the required date, and happily tell the boss "No Problem, right on
> > > time!" So what's going to happen 5 days from now? At 10 widgets a
> day,
> > > the max one person can do, we've actually only done 50 and have to
> go to
> > > the boss with the news that we're only halfway there. Not exactly a
> > > career enhancing move. What should we have done? We should NOT
> have
> > > put the constraint on to begin with and used a deadline instead !
> Then
> > > when we entered our plan we would have seen a couple of things
> > > differently - first of all there would be a big red flag next to
> > > milestone warning us there's a problem. Secondly we would have seen
> the
> > > milestone diamond sitting 5 days to the right of the deadline
> arrowhead,
> > > telling us exactly how bad the problem is. Now when the boss asks
> if
> > > we're going to make schedule, we can tell him with confidence "Not
> with
> > > only one guy working on it but if you can convince the manager of
> > > manufacturing to lend us an extra widget expert to help out, we can
> make
> > > it." Now our plan is not just a pretty picture of our hopes for
> the
> > > project, it's giving us the concrete information we need in order to
> > > make the effective managerial decisions necessary to achieve those
> > > objectives - in this case, to meet our required milestone we *have*
> to
> > > get more resources or live with the late delivery - there are no
> other
> > > options.
> > >
> > > So where would I use a constraint? I need to ship a boatload of
> iron
> > > ore to Europe. The ice won't break up in the lake and Seaway until
> > > April so the boat can't move until then. I'd model that physical
> > > reality in the plan with a "Start No Earlier Than" constraint on the
> > > task. Even if we're loaded and ready to go on New Years day, it
> simply
> > > cannot happen until at least April no matter what and the plan
> should
> > > reflect that. That, to my way of thinking, is the proper use of
> > > constraints.
> > >
> > > --
> > > Steve House
> > > MS Project MVP
> > > Visit http://www.mvps.org/project/faqs.htm for the FAQs
> > >
> > >
> > >
> > >

> message

> > > > Hi Steve,
> > > >
> > > > I agree when you say "avoid hard constraints like the plague". I
> fight
> > > > everyday with project managers for that.
> > > > But sometime you really have date constraints, and generally they
> are
> > > hard
> > > > constraints.
> > > > In automotive industry, there are some milestones which are not
> > > negotiable.
> > > > I knew a Project Director who has been brought to negociate a
> delay on
> > > some
> > > > milestones. He obtained satisfaction because the management was in
> > > front of
> > > > the "fait accompli". But at the end of the meeting, he was no more
> > > Project
> > > > Director.
> > > > NB : It's very easy to display (graphically) the negative Total
> Slack
> > > in the
> > > > Gantt Chart. So you always see if your schedule is in time or not
> !
> > > And you
> > > > see *all the tasks* on which you can work to come back within the
> > > date10
> > > > constraint.
> > > >
> > > > Gérard
> > > >

> dans
> > > le

> > > > > Even better, avoid hard constraints like the plague. IMHO
> > > constraints
> > > > > exist to model mandatory conditions and physical
> impossibilities,
> > > like
> > > > > the fact Christmas Day must always start on 25 Dec, imposed on
> the
> > > plan
> > > > > but not a part of it. The goals or objectives within a Project
> or
> > > > > phase, like "Contract Negotiations are to be completed by 01
> Feb,"
> > > even
> > > > > if expressed most strongly such as one's boss adding "and if
> it's
> > > not
> > > > > you're fired!", is the function of deadlines, not constraints.
> A
> > > > > constraint limits where Project can place the task. If
> predecessors
> > > or
> > > > > resource limitations, etc, are going to drive a milestone past
> its
> > > > > required deadline, I want to see that fact on the Gantt with the
> > > > > milestone sitting on the date it *will* occur unless I do
> something
> > > to
> > > > > fix it, *not* on the date where I *want* it to occur but won't
> hit
> > > with
> > > > > the plan as it presently stands. Just saying something will
> happen
> > > on
> > > > > or by a certain date is not in and of itself sufficient to make
> it
> > > > > possible. If it's after its deadline, that's my cue that I
> need to
> > > get
> > > > > to work and redo the plan. If I have a constraint on the
> milestone
> > > > > though, it always obeys the constraint date condition whether or
> not
> > > > > that can actually happen and I never get the alert telling me
> > > there's a
> > > > > problem. I can easily end up blindly assuming all is well until
> > > it's
> > > > > too late to do anything about it.
> > > > >
> > > > > --
> > > > > Steve House
> > > > > MS Project MVP
> > > > > Visit http://www.mvps.org/project/faqs.htm for the FAQs
> > > > >
> > > > >
> > > > >

> > > message

> > > > > > Hello Elaine,
> > > > > >
> > > > > > I guess that your milestone has a date constraint such as Must
> > > Finish
> > > > > On...
> > > > > > which takes place the evening at 17:00. So the successeur must
> > > start
> > > > > on the
> > > > > > next day.
> > > > > > Try the Must Start On constraint which takes place on the
> morning
> > > > > (08:00)
> > > > > >
> > > > > > Hope this helps,
> > > > > >
> > > > > > Gérard Ducouret
> > > > > >

> > > message
> > > > > de

> > > > > > > Hello
> > > > > > >
> > > > > > > I have a Milestone Task with a date Wednesday 04/02/04.
> > > > > > > Its successors have start dates Thursday 05/02/04.
> > > > > > >
> > > > > > > On my colleague's High Level Schedule - from where these
> > > > > > > activities have been manually copied - the successor tasks
> > > > > > > both have start dates of Wednesday 04/02/04...which is
> > > > > > > what I want mine to show.
> > > > > > >
> > > > > > > Sorry - but I can't for the life of me find the option
> > > > > > > that tells milestones not to push successor tasks to the
> > > > > > > next day.
> > > > > > >
> > > > > > > Hope you can help. Thanks very much
> > > > > > >
> > > > > > > Elaine.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>


 
 
Steve





PostPosted: Fri Jan 09 12:06:17 CST 2004 Top

Microsoft Project >> Milestone Tasks and their successors You're right, IF the late task is one the screen when you're looking at
the milestone. But imagine the scenario where you have a dozen summary
tasks in parallel, all with a dozen subtasks, each summary is linked to
the finish milestone. The finish milestone has a "Must finish on" or
"Must finish no later than" constraint on it of, say 15 Feb, so that's
the date it sits on in the Gantt chart. The first summary task is late
and doesn't finish until 15 March, the only one that is a problem.
Unless you change the plan for the first summary, 15 March is the date
you WILL reach that milestone on even though the plan says you're
supposed to hit it 15 Feb and every report you run promises you will be
finished on 15 Feb. I want to plan to predict what is going to happen,
tell me that if things continue as they are I will finish 15 Mar no
matter how badly we want or need it to be otherwise. It doesn't need to
tell me what I want to happen, I already know that answer to that. I
need it to tell me if I'm going to be successful or if I need to figure
out another approach. You seem to be operating as if the plan is a
staement of what you intend to happen - I see it as an analytic tool
that tells me if it's even POSSIBLE to meet expectations and if so what
strategy I can devise that will achieve them. Unless I see the effect
of the various option choices I make, resource deployments, etc, it
doesn't fulfill that role. I want it to answer the question "If
resource Bob leaves the project and I can't replace him, how will late
that make us finish? Is it worth the cost of replacing him or shall we
live with the delay?" If my finish milestone never moves beyond its
required finish date because of a constraint, I can never answer those
questions. The project schedule is not a work schedule. It is a
dynamic modeling tool for managers to use to make decisions between
alternative business cases and strategies and a model that doesn't
change is like having a calculator that always displays the same answer
no matter what numbers you input or operations you perform on them. A
plan that always shows a milestone occuring on time, regardless of
whether it CAN occur on time or not. is exactly the same thing.

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



"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in

> Hi Steve,
>
> Some despair is coming up, because I have at least told you 5 times
alreeady
> that you see when the TASK is scheduled to be finished that is linked
to the
> fixed milestone.
>
> You really fight an isolated fight, you know, people all over the
world use
> fixd dates on milestone, it simply is more visible than deadline
dates.
>
> Greetings,
> --
> Jan De Messemaeker
> Microsoft Project Most Valuable Professional
> Project Management Consultancy
> Prom+ade BVBA
> 32-495-300 620

bericht

> > True enough - what it doesn't give you though is the direct
indication
> > of the date you WILL hit unless you change something.
> >
> > --
> > Steve House
> > MS Project MVP
> > Visit http://www.mvps.org/project/faqs.htm for the FAQs
> >
> >

message

> > > Hello Steve,
> > >
> > > I agree with almost everything you explain. I just point out that
with
> > a
> > > hard constraint (Finish Not Later Than for ex.) *and* the display
of
> > > negative Total Slack (From Late Finish ... To Finish in the Bar
Styles
> > > dialog) you have good visible warnings if you hit the milestone.
> > > Furthermore, you immediately see how severe is the problem
(Deadline
> > too, I
> > > agree) but the more interesting is that you see what are the
sequences
> > of
> > > tasks you have to improve : "imagine the more usual case where
that
> > widget
> > > task is 25 or 50 lines above the milestone in the task list" :
with
> > this
> > > graphical negative slack you immediately see that the problem
concerns
> > tasks
> > > 25, 26 and task 50 .
> > >
> > > Sincerely,
> > >
> > > Gérard
> > >

dans
> > le

> > > > I never said the milestones were negotiable. In the real world
they
> > > > aren't, more often than not. But what we see on the computer
screen
> > > > when looking at the project file is not the real world, it is a
> > model of
> > > > the real world and that is a major distinction that is often
lost.
> > The
> > > > real world dictates what we must do, its milestones - which
really
> > do
> > > > have constraints - indicate what we NEED to get. The plan,
OTOH,
> > > > predicts what we're GOING to get, for better or worse, if we try
to
> > do
> > > > it in the way we've modeled the work. If those calculated
results
> > do
> > > > not conform to the needs of our project, we need to change the
parts
> > of
> > > > the model that drive those unacceptable results until they do.
Our
> > > > problem then is to manipulate the controllable parts of that
model
> > so
> > > > that the calculated milestones indicated in the plan fall on or
> > before
> > > > the mandatory milestones that we must hit when we actually work
the
> > > > project in the real world. If we are going to effectively use
the
> > plan
> > > > for this sort of "what-if" modeling, we must see what happens to
the
> > > > calculated milestones when we change one of the determinants
that
> > drive
> > > > them, whether that change is in the right direction or the wrong
> > one.
> > > > Perhaps we should stop calling it a "plan" at all and instead
call
> > it a
> > > > "prediction" at least up until it's finalized and signed off as
> > being
> > > > ready to go. Move over Miss Cleo!
> > > >
> > > > Here's what I see as the problem with constraints. Take the
> > simplest
> > > > case - we have to create 100 widgets. We have 1 person to do it
> > with
> > > > and he can create a maximum of 10 a day - that's determined by
the
> > > > physics of creating widgets and we simply have to accept that as
a
> > given
> > > > and base everything else on that fact. But the boss has said we
> > must be
> > > > complete in 5 days. So we put that into our plan as a task of
10
> > days

> > > > milestone linked as a successor and the milestone has a "must
finish
> > on"
> > > > or "must finish no later than" constraint 5 days away. What
does
> > our
> > > > plan show? It shows the milestone happening right on time even
> > though
> > > > the task that determines what we're really going to get doesn't
> > finish
> > > > for another 5 days! Now in this case we can see the problem
easily
> > > > because the predecessor is just above the milestone but imagine
the
> > more
> > > > usual case where that widget task is 25 or 50 lines above the
> > milestone
> > > > in the task list ... when looking at the milestone the arrow
coming
> > from
> > > > its predecessor comes straight down into the screen from the top
and
> > > > looks perfectly normal, the "hook" to the right to connect to
the
> > end of
> > > > the predecessor that is finishing after the milestone indicates
it
> > is is
> > > > way up under the predecessor and invisible when looking at the
> > milestone
> > > > task. So the boss says "How about it? Are we going to make
> > schedule?"
> > > > I look for the milestone in the project plan, see it's sitting
there
> > on
> > > > the required date, and happily tell the boss "No Problem, right
on
> > > > time!" So what's going to happen 5 days from now? At 10
widgets a
> > day,
> > > > the max one person can do, we've actually only done 50 and have
to
> > go to
> > > > the boss with the news that we're only halfway there. Not
exactly a
> > > > career enhancing move. What should we have done? We should NOT
> > have
> > > > put the constraint on to begin with and used a deadline instead
!
> > Then
> > > > when we entered our plan we would have seen a couple of things
> > > > differently - first of all there would be a big red flag next to
> > > > milestone warning us there's a problem. Secondly we would have
seen
> > the
> > > > milestone diamond sitting 5 days to the right of the deadline
> > arrowhead,
> > > > telling us exactly how bad the problem is. Now when the boss
asks
> > if
> > > > we're going to make schedule, we can tell him with confidence
"Not
> > with
> > > > only one guy working on it but if you can convince the manager
of
> > > > manufacturing to lend us an extra widget expert to help out, we
can
> > make
> > > > it." Now our plan is not just a pretty picture of our hopes
for
> > the
> > > > project, it's giving us the concrete information we need in
order to
> > > > make the effective managerial decisions necessary to achieve
those
> > > > objectives - in this case, to meet our required milestone we
*have*
> > to
> > > > get more resources or live with the late delivery - there are no
> > other
> > > > options.
> > > >
> > > > So where would I use a constraint? I need to ship a boatload of
> > iron
> > > > ore to Europe. The ice won't break up in the lake and Seaway
until
> > > > April so the boat can't move until then. I'd model that
physical
> > > > reality in the plan with a "Start No Earlier Than" constraint on
the
> > > > task. Even if we're loaded and ready to go on New Years day, it
> > simply
> > > > cannot happen until at least April no matter what and the plan
> > should
> > > > reflect that. That, to my way of thinking, is the proper use of
> > > > constraints.
> > > >
> > > > --
> > > > Steve House
> > > > MS Project MVP
> > > > Visit http://www.mvps.org/project/faqs.htm for the FAQs
> > > >
> > > >
> > > >
> > > >

> > message

> > > > > Hi Steve,
> > > > >
> > > > > I agree when you say "avoid hard constraints like the plague".
I
> > fight
> > > > > everyday with project managers for that.
> > > > > But sometime you really have date constraints, and generally
they
> > are
> > > > hard
> > > > > constraints.
> > > > > In automotive industry, there are some milestones which are
not
> > > > negotiable.
> > > > > I knew a Project Director who has been brought to negociate a
> > delay on
> > > > some
> > > > > milestones. He obtained satisfaction because the management
was in
> > > > front of
> > > > > the "fait accompli". But at the end of the meeting, he was no
more
> > > > Project
> > > > > Director.
> > > > > NB : It's very easy to display (graphically) the negative
Total
> > Slack
> > > > in the
> > > > > Gantt Chart. So you always see if your schedule is in time or
not
> > !
> > > > And you
> > > > > see *all the tasks* on which you can work to come back within
the
> > > > date10
> > > > > constraint.
> > > > >
> > > > > Gérard
> > > > >

écrit
> > dans
> > > > le

> > > > > > Even better, avoid hard constraints like the plague. IMHO
> > > > constraints
> > > > > > exist to model mandatory conditions and physical
> > impossibilities,
> > > > like
> > > > > > the fact Christmas Day must always start on 25 Dec, imposed
on
> > the
> > > > plan
> > > > > > but not a part of it. The goals or objectives within a
Project
> > or
> > > > > > phase, like "Contract Negotiations are to be completed by 01
> > Feb,"
> > > > even
> > > > > > if expressed most strongly such as one's boss adding "and if
> > it's
> > > > not
> > > > > > you're fired!", is the function of deadlines, not
constraints.
> > A
> > > > > > constraint limits where Project can place the task. If
> > predecessors
> > > > or
> > > > > > resource limitations, etc, are going to drive a milestone
past
> > its
> > > > > > required deadline, I want to see that fact on the Gantt with
the
> > > > > > milestone sitting on the date it *will* occur unless I do
> > something
> > > > to
> > > > > > fix it, *not* on the date where I *want* it to occur but
won't
> > hit
> > > > with
> > > > > > the plan as it presently stands. Just saying something will
> > happen
> > > > on
> > > > > > or by a certain date is not in and of itself sufficient to
make
> > it
> > > > > > possible. If it's after its deadline, that's my cue that I
> > need to
> > > > get
> > > > > > to work and redo the plan. If I have a constraint on the
> > milestone
> > > > > > though, it always obeys the constraint date condition
whether or
> > not
> > > > > > that can actually happen and I never get the alert telling
me
> > > > there's a
> > > > > > problem. I can easily end up blindly assuming all is well
until
> > > > it's
> > > > > > too late to do anything about it.
> > > > > >
> > > > > > --
> > > > > > Steve House
> > > > > > MS Project MVP
> > > > > > Visit http://www.mvps.org/project/faqs.htm for the FAQs
> > > > > >
> > > > > >
> > > > > >

in
> > > > message

> > > > > > > Hello Elaine,
> > > > > > >
> > > > > > > I guess that your milestone has a date constraint such as
Must
> > > > Finish
> > > > > > On...
> > > > > > > which takes place the evening at 17:00. So the successeur
must
> > > > start
> > > > > > on the
> > > > > > > next day.
> > > > > > > Try the Must Start On constraint which takes place on the
> > morning
> > > > > > (08:00)
> > > > > > >
> > > > > > > Hope this helps,
> > > > > > >
> > > > > > > Gérard Ducouret
> > > > > > >

dans le
> > > > message
> > > > > > de

> > > > > > > > Hello
> > > > > > > >
> > > > > > > > I have a Milestone Task with a date Wednesday 04/02/04.
> > > > > > > > Its successors have start dates Thursday 05/02/04.
> > > > > > > >
> > > > > > > > On my colleague's High Level Schedule - from where these
> > > > > > > > activities have been manually copied - the successor
tasks
> > > > > > > > both have start dates of Wednesday 04/02/04...which is
> > > > > > > > what I want mine to show.
> > > > > > > >
> > > > > > > > Sorry - but I can't for the life of me find the option
> > > > > > > > that tells milestones not to push successor tasks to the
> > > > > > > > next day.
> > > > > > > >
> > > > > > > > Hope you can help. Thanks very much
> > > > > > > >
> > > > > > > > Elaine.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>