Milestones add time to projects?

[superfly]

I've got a project with many sub-projects. A milestone is set for a fixed day
at the end of each sub-project. The milestones have no predessors but they
are each contained within sub-projects. Although they have 0 duration, they
are somehow adding time to each sub-project. When I outdent them outside of
their sub-projects, the sub comes out to 12 hours. When I indent them inside,
the sub is 12.57 hours. HOW DO I FIX THIS?

 

[Gérard Ducouret]

Hello,
Display the time besides the date: Tools / Options / View / Date format :
choose a format with 12:33
and check what is the time of the date constraint on your milestones

Hope this helps,

Gérard Ducouret

 

[Steve House [Project MVP]]

The best solution is to completely remove the fixed-date constraint from
your milestone and link it into the chain of subtasks as the last task in
the chain. The duration of a summary is from the start of the earliest task
to the finish of the latest task, If I have a summary containing only two
subtasks, both of them milestones of zero duration, and use a MSO or MFO
contraint to fix the subtasks to dates 2 weeks apart, the summary will show
a duration of 2 weeks. Milestones are NOT dates per se - they are
signifigant EVENTS (such as "Approval Received" or "Design Finished") that
occur during the project. They may, and usually do, have deadlines or dates
where they are supposed to hit but that doesn't mean they are "fixed dates."
A "fixed date " means it WILL happen on that date no matter what else is
going on or whether the events leading up to it happen on time or not. That
approval, for example, will come whenever it comes, be it early, on-time, or
late. What your plan should be showing is where the milestone is likely to
happen as determined by the work leading up to it, with a deadline
indicating where it is supposed to happen if you're meeting your objectives
so you can compare the two and determine if your plan is a good one or if
you have to go back to the drawing board and reschedule to better meet the
required performance.

 

[John Sitka]

Steve, do you have an effective canned answer (document) for this problem.
I have not yet met anyone who instinctively understands this. Thousands of
"man years" of thinking of hard due dates is difficult to overcome.
In fact I stepped over the line the other day when looking at a huge scheduling board
filled with fixed dates; I declared it a intricate and beautiful plan for failure because
somewhere in that huge matrix of tasks many things will go wrong or slowly and all
deliverables will be late, oops. This isn't the best way to change minds; I know but the
fatigue of this crusade had me in a moment of weakness.

 

[Steve House [Project MVP]]

I agree and share the frustration - it seems like too many people have a
very difficult time understanding that the model of the project one sees on
the screen in MS Project or on a snappy Gantt chart on the wall is NOT the
same thing as the project itself. In the real world one has a contract date
to meet and it's non-negotiable. The real project has a firm end date while
milestones within it have firm dates that must be met or you're unemployed.
But the job of the project manager is not just to parrot those dates in a
spiffy chart and pretend that documenting the objectives in a Project plan
and communicating them to the team will be sufficient to make it happen the
way it's supposed to - his or her job is figure out just what exactly what
has to happen when in order to MEET those requirements. And in order to
figure out what we have to do, how we have to structure the work in order to
meet those firm dates, we need to build a model in Project that allows us to
simulate to consequences of the various management decisions we might make.
Do we put Joe on A or have him help Fred on B next week? Do we need to hire
some temps or try to do it with our present staff? Do we wax the widgets
first or should we polish the fids first and then wax the widgets when
that's done? But such a model is useless unless it actually shows you the
likely outcomes of the various decisions you might make. Project needs to
be able to show us that doing A then B will make us 2 weeks late at the end
of the process but if we rearrange it and do B before A we'll finish a week
early. We simply MUST have a project plan that shows us where we'll truly
end up if we try to perform the work the way we have entered it so far. If
we pump our tasks, durations, and links into the plan and Project gives us a
date that's not acceptable, we have to restructure the work itself or else
we won't make the deadline in the real world either. Making something a
fixed date in the project plan means you're fixing it in the model and
effectively crippling Project's ability to show you whether or not decision
X will be a good thing or a bad thing. I say it over and over in my classes
and sound like a broken record here - Project is not intended to simply
document scheduling decisions that have made elsewhere - its job is to tell
you what scheduling decisions you ought to be making by predicting for you
the different outcomes of the various options you might choose. I try to
teach that constraints are valuable where (but only where) they effectively
model the real world - your project starts June first and you're ready to
wax the widget about the 15th. But the wax vendor is backordered and the
wax won't arrive until the 1st of July. Putting an SNET constraint of 1
July on the Waxing task is perfectly appropriate because it models a factor
affecting the scheduling of work that is imposed by conditions external to
the plan itself (in much the same way that links model factors affecting the
scheduling driven by conditions *within* the project)and in fact that truly
is the earliest that the task is able to start no matter what you do earlier
in the project. But the boss coming in stormy angry and shouting "You
better finish that waxing by the first of July or by G*d I'll find someone
who can!" is not a constraint - it is a very strongly stated objective best
modeled with a deadline entry, not a constraint entry. The date is NOT
fixed no matter how much we or the boss or the signatories of a contract
might wish it to be - the waxing will finish whenever the last widget is
waxed, not a moment before and not a moment after - and just declaring it to
be fixed by putting a constraint on it won't make it any different. There's
a big difference between "occurs before July 1st" and "needs to occur before
July 1st." We build the plan to figure out how to meet the dates we need to
meet and to do that we have to see where the present plan will put them, for
better or worse.

Sorry for getting long winded and preachy (and redundent)- it's a bad habit
of mine LOL

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

 

[John Sitka]

But the boss coming in stormy angry and shouting "You
better finish that waxing by the first of July or by G*d I'll find someone who can!" is not a constraint - it is a very strongly
stated objective best modeled with a deadline entry, not a constraint entry. The date is NOT fixed no matter how much we or the
boss or the signatories of a contract might wish it to be - the waxing will finish whenever the last widget is waxed, not a moment
before and not a moment after - and just declaring it to be fixed by putting a constraint on it won't make it any different.

I see so many people struggle with this, their foreheads get crinkly and for a minute
they think they understand, then 5 minutes later they are back to talking fixed dates again.

"Just mouseover the bar, it will tell you; tracking, leveling and additonal planning efforts
will change what that mouseover shows as the project proceeds, that's why we use this thing."

The application of constraint dates has something to do with having to have answers.
Maybe if we removed the incorrect question when it comes to projects as systems.
"When will that task be done" should be "Is the whole project going to make it on time."

 

[Steve House [Project MVP]]

When I was in university back in the stone age my profs always said that the
main thing you get out of an education (biochemistry and economics in my
case) is the ability to formulate meanful questions and and some skills at
finding the answers.

I think the overwhelming temptation to use fixed dates stems from the sheer
terror of showing the boss a tentative plan where all the Gantt bars don't
align to his assigned objectives and having to explain why the plan he
outlined for us or our sales rep promised the client us won't work. For me,
I'd rather have to explain, using my Project files as visual aids, 6 months
before the project is due why we have to hire more staff, rework his pet
schedule, or renegotiate the contract, than to have to go knock on his door
the day before the promised delivery date and explain why we've suddenly
found there's still a month of work remaining before we're done. It's far
better for your career to take the boss good news instead of bad news.


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

But the boss coming in stormy angry and shouting "You
better finish that waxing by the first of July or by G*d I'll find
someone who can!" is not a constraint - it is a very strongly stated
objective best modeled with a deadline entry, not a constraint entry.
The date is NOT fixed no matter how much we or the boss or the
signatories of a contract might wish it to be - the waxing will finish
whenever the last widget is waxed, not a moment before and not a moment
after - and just declaring it to be fixed by putting a constraint on it
won't make it any different.

I see so many people struggle with this, their foreheads get crinkly and
for a minute
they think they understand, then 5 minutes later they are back to talking
fixed dates again.

"Just mouseover the bar, it will tell you; tracking, leveling and
additonal planning efforts
will change what that mouseover shows as the project proceeds, that's why
we use this thing."

The application of constraint dates has something to do with having to
have answers.
Maybe if we removed the incorrect question when it comes to projects as
systems.
"When will that task be done" should be "Is the whole project going to
make it on time."

Steve, do you have an effective canned answer (document) for this
problem.
I have not yet met anyone who instinctively understands this. Thousands
of
"man years" of thinking of hard due dates is difficult to overcome.
In fact I stepped over the line the other day when looking at a huge
scheduling board
filled with fixed dates; I declared it a intricate and beautiful plan
for failure because
somewhere in that huge matrix of tasks many things will go wrong or
slowly and all
deliverables will be late, oops. This isn't the best way to change
minds; I know but the
fatigue of this crusade had me in a moment of weakness.


"Steve House [Project MVP]" <[email protected]>
wrote in message The best solution is to completely remove the fixed-date constraint
from your milestone and link it into the chain of subtasks as the last
task in the chain. The duration of a summary is from the start of the
earliest task to the finish of the latest task, If I have a summary
containing only two subtasks, both of them milestones of zero duration,
and use a MSO or MFO contraint to fix the subtasks to dates 2 weeks
apart, the summary will show a duration of 2 weeks. Milestones are NOT
dates per se - they are signifigant EVENTS (such as "Approval Received"
or "Design Finished") that occur during the project. They may, and
usually do, have deadlines or dates where they are supposed to hit but
that doesn't mean they are "fixed dates." A "fixed date " means it WILL
happen on that date no matter what else is going on or whether the
events leading up to it happen on time or not. That approval, for
example, will come whenever it comes, be it early, on-time, or late.
What your plan should be showing is where the milestone is likely to
happen as determined by the work leading up to it, with a deadline
indicating where it is supposed to happen if you're meeting your
objectives so you can compare the two and determine if your plan is a
good one or if you have to go back to the drawing board and reschedule
to better meet the required performance.

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


I've got a project with many sub-projects. A milestone is set for a
fixed day
at the end of each sub-project. The milestones have no predessors but
they
are each contained within sub-projects. Although they have 0
duration, they
are somehow adding time to each sub-project. When I outdent them
outside of
their sub-projects, the sub comes out to 12 hours. When I indent them
inside,
the sub is 12.57 hours. HOW DO I FIX THIS?

 

[davegb]

As one VP put it when he was talking with me at the beginning of a
consulting engagement, "I want to know why I have so many 100 day
projects until day 99".
I didn't tell him, at least not at first, "It's because you make up
schedules out of thin air, then demand that they be met, and don't want
to hear any other opinion, no matter how well founded in reality it may
be!"

When I was in university back in the stone age my profs always said that the
main thing you get out of an education (biochemistry and economics in my
case) is the ability to formulate meanful questions and and some skills at
finding the answers.

I think the overwhelming temptation to use fixed dates stems from the sheer
terror of showing the boss a tentative plan where all the Gantt bars don't
align to his assigned objectives and having to explain why the plan he
outlined for us or our sales rep promised the client us won't work. For me,
I'd rather have to explain, using my Project files as visual aids, 6 months
before the project is due why we have to hire more staff, rework his pet
schedule, or renegotiate the contract, than to have to go knock on his door
the day before the promised delivery date and explain why we've suddenly
found there's still a month of work remaining before we're done. It's far
better for your career to take the boss good news instead of bad news.


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

But the boss coming in stormy angry and shouting "You
better finish that waxing by the first of July or by G*d I'll find
someone who can!" is not a constraint - it is a very strongly stated
objective best modeled with a deadline entry, not a constraint entry.
The date is NOT fixed no matter how much we or the boss or the
signatories of a contract might wish it to be - the waxing will finish
whenever the last widget is waxed, not a moment before and not a moment
after - and just declaring it to be fixed by putting a constraint on it
won't make it any different.

I see so many people struggle with this, their foreheads get crinkly and
for a minute
they think they understand, then 5 minutes later they are back to talking
fixed dates again.

"Just mouseover the bar, it will tell you; tracking, leveling and
additonal planning efforts
will change what that mouseover shows as the project proceeds, that's why
we use this thing."

The application of constraint dates has something to do with having to
have answers.
Maybe if we removed the incorrect question when it comes to projects as
systems.
"When will that task be done" should be "Is the whole project going to
make it on time."

Steve, do you have an effective canned answer (document) for this
problem.
I have not yet met anyone who instinctively understands this. Thousands
of
"man years" of thinking of hard due dates is difficult to overcome.
In fact I stepped over the line the other day when looking at a huge
scheduling board
filled with fixed dates; I declared it a intricate and beautiful plan
for failure because
somewhere in that huge matrix of tasks many things will go wrong or
slowly and all
deliverables will be late, oops. This isn't the best way to change
minds; I know but the
fatigue of this crusade had me in a moment of weakness.


"Steve House [Project MVP]"

wrote in message The best solution is to completely remove the fixed-date constraint
from your milestone and link it into the chain of subtasks as the last
task in the chain. The duration of a summary is from the start of the
earliest task to the finish of the latest task, If I have a summary
containing only two subtasks, both of them milestones of zero duration,
and use a MSO or MFO contraint to fix the subtasks to dates 2 weeks
apart, the summary will show a duration of 2 weeks. Milestones are NOT
dates per se - they are signifigant EVENTS (such as "Approval Received"
or "Design Finished") that occur during the project. They may, and
usually do, have deadlines or dates where they are supposed to hit but
that doesn't mean they are "fixed dates." A "fixed date " means it WILL
happen on that date no matter what else is going on or whether the
events leading up to it happen on time or not. That approval, for
example, will come whenever it comes, be it early, on-time, or late.
What your plan should be showing is where the milestone is likely to
happen as determined by the work leading up to it, with a deadline
indicating where it is supposed to happen if you're meeting your
objectives so you can compare the two and determine if your plan is a
good one or if you have to go back to the drawing board and reschedule
to better meet the required performance.

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


I've got a project with many sub-projects. A milestone is set for a
fixed day
at the end of each sub-project. The milestones have no predessors but
they
are each contained within sub-projects. Although they have 0
duration, they
are somehow adding time to each sub-project. When I outdent them
outside of
their sub-projects, the sub comes out to 12 hours. When I indent them
inside,
the sub is 12.57 hours. HOW DO I FIX THIS?