Adding a predecessor does not change date?

[bob]

Task 20 already has predecessors 2,4,6,8 and so Task 20 follows the latest
of those dates.

I insert task 10, and add that number to task 20's predecessors:

2,4,6,8,10

Task 10 is later than 2,4,6,or 8 and SHOULD push out task 20, but some times
it does not.
And some times it does. I have to watch this very carefully and do a lot of
manual changing.

Is the reason for this because task 20 was set with a duration? Or because
of something else?
I'm trying to ensure that anytime I add a new predecessor, that it actually
affects the start date.

 

[Jan De Messemaeker]

Hi,

Maybe Task20 has an Actual Start date. That fixes it (predecessors change
the plan they are not supposed to change history).
It may also have a strong constraint such as Must... or Finish no later
than.
Or finally, Calculation may be set to manual.
HTH

 

[bob]

Thanks.
So, if a task is entered with a date, then a predecessor cannot affect it's
date?

 

[Jan De Messemaeker]

HI?

Who says "a date"?

- An Actual Start or finish date
- A strong constraint (MSO, MFO, FNLT)

These are stronger than links

But weak cosntraints such as SNET or FNET are overridden by links.
HTH

 

[Steve House [Project MVP]]

It depends. First of all you should never, ever enter scheduled start and
end dates for tasks except under rare and special circumstances! Project's
whole reason for existence is to tell you the dates on which you should be
scheduling the tasks in order to accomplish your goals, not simply parrot
back the dates you want to or think you should be able to schedule them. If
you're scheduling from project start forward and the task's entered with a
date typed in the Start column a Start No Earlier constraint is established
that will not allow the task to move any earlier than the date entered but
it could be pushed later by predecessors (among other things). Entering
something in the Finish column will give you a MFNET constraint. If you're
scheduling backwards from project end date, you'll get a MSNLT or MFNLT
constraints instead. OTOH, if you type in a Must Start On, Must Finish On,
or a Must Start or Finish No Later Than constraint date on the task
information form, that locks the task to that date and nothing will change
it. .

 

[bob]

"But weak cosntraints such as SNET or FNET are overridden by links"

Ah, I think that is my answer! I will look on how to change those
constraints to SNET.

I know that locking in start dates is a sensitive issue with this group, and
I've failed in explaining that this is our reality.

We have special tools arriving on hard dates and those are set in stone. Of
course, things can go wrong, but this tool maker has been making our tools
for over a decade, and nobody can recall him missing a deadline/date. So, I
enter tool A on 8/1, tool B on 9/1, etc. We can produce widgets when the
tools arrive and installed. These tools are about 500 line items.

But alas, I learned yesterday that some of the material for tool S will be
late, so even though the tool is here, I cannot make widgets without
material. I enter a predecessor for tool S's production that reflects the
late material, BUT, even though tool S is on time, my production date fails
to move out to reflect the late material. It remains the same, which is
inaccurate.

On Monday, I will change tool S's constraints to SNET, and then the material
arriving later should move out the widget production date.

Many thanks! If this works, it solves a great many hours of manual
examinations and changes!

bob


I have

 

[Jan De Messemaeker]

HI,

Glad to oblige!

 

[Steve House [Project MVP]]

You have indeed mentioned the sort of situations an SNET is designed for.
I'd prefer to use "semi-hard" constraints rather than say the dates are set
in stone. You can't begin a task until the required tools arrive so that
part is certain, BUT you could begin later if other circumstances conspire
to make it impossible to start as soon as the tools show up. A hard
constraint, Must Start On, says the task *WILL* start on that date, no if's,
and's or but's and there is absolutely nothing in the universe, no
eventuality known to man or action of anyone working on the project would
make it start otherwise. Short of acts of nature that just doesn't happen
very often.

 

[davegb]

Steve House [Project MVP] wrote:
A hard

constraint, Must Start On, says the task *WILL* start on that date, no if's,
and's or but's and there is absolutely nothing in the universe, no
eventuality known to man or action of anyone working on the project would
make it start otherwise. Short of acts of nature that just doesn't happen
very often.

This statement seems internally conflicted, Steve. "Absolutely nothing
in the universe, no eventuality known to man or action of anyone
working on the project " precludes "acts of nature" (these are "known
to man"). So can "acts of nature", hurricanes, floods, volcanos
erupting, etc., legitimately put off an MSO?

 

[Steve House [Project MVP]]

Perhaps stated a little too strongly <grin>. But remember that the schedule
is a predictive model of the real world but it is not the same thing AS the
real world. Too many people think that the very act of expressing a plan in
itself creates the conditions that make it happen that way and that
successful project management is fundamentally an act of will-power and
determination to make things happen in the way you want them to. An MSO
constraint implies that the task WILL happen as writ down, end of story. I
feel very uncomfortable with the idea that anything humans do is that
solidly fixed in time. Obviously an "act of God" might change it but the
MSO essentially is saying that human activity is not the driving force
behind the date on which it occurs.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Steve House [Project MVP] wrote:
A hard

constraint, Must Start On, says the task *WILL* start on that date, no
if's,
and's or but's and there is absolutely nothing in the universe, no
eventuality known to man or action of anyone working on the project would
make it start otherwise. Short of acts of nature that just doesn't happen
very often.

This statement seems internally conflicted, Steve. "Absolutely nothing
in the universe, no eventuality known to man or action of anyone
working on the project " precludes "acts of nature" (these are "known
to man"). So can "acts of nature", hurricanes, floods, volcanos
erupting, etc., legitimately put off an MSO?

 

[davegb]

Perhaps stated a little too strongly <grin>. But remember that the schedule
is a predictive model of the real world but it is not the same thing AS the
real world. Too many people think that the very act of expressing a plan in
itself creates the conditions that make it happen that way and that
successful project management is fundamentally an act of will-power and
determination to make things happen in the way you want them to. An MSO
constraint implies that the task WILL happen as writ down, end of story.

Just giving you a hard time, as usual! <evil grin>
I interpret MSO and MFO a little differently than you do. To me, it
means that the task needs to occur at that time or the consequences are
dire. This could be showing up at the courthouse on time or the keynote
speaker stepping up to the podium at 8:00 am Monday morning to start
the conference. There is little or no flexibility. In the first case, a
warrant may be issued or a hefty fine imposed, in the second, a couple
of hundred people who paid good money for whatever getting antzy by the
minute.

I totally agree with you that too many projects are scheduled by edict
- a manager or client thinking that by pronuouncing it so, it must
happen, without any knowledge of whether or not it's reasonable or even
possible! Certainly, this can undermine an intelligent approach to
scheduling.

Some years ago, when I first started teaching MSP, I had some students
come to class who had been given a list of over 3,000 tasks, each with
a start and a finish date, no dependencies, and orders to create a CP
schedule for the project! Mission Impossible! Even Tom couldn't make
that happen.

I often quote Eisenhower in my classes and consulting engagements,
"Plans are meaningless. Planning is everything."

Regards,
Dave

 

[Steve House [Project MVP]]

I have to disagree completely that a constraint is the best way to schedule
the circumstance you describe here. I suggest that a DEADLINE is the better
way to show something "needs to occur by that time or the consequences are
dire." A constraint of any sort limits Project's freedom to display the
tasks where it thinks they should go. But the reason for using scheduling
software instead of simply drawing task bars in Magic Marker on a wall
calendar is to have a tool that does exactly that - calculates schedules
for us so that we have a tool to use to figure out what we must do in order
to meet those requirements. As such, we need to allow Project to freely
calculate the results of our potential decisions - if I put Joe on this
task, will it move my completion up or set it back? But a constraint says
DON'T show me the results of those decisions and instead just show on this
date as I dictate whether it actually can happen then or not! If we put
your example of showing up in court at a certain time into our plan with an
MSO constraint, it's going to show we're going to make it on time regardless
of whether it's actually going to be physically possible to do so. The case
could be in 10 minutes, we could be 1000 miles away and on foot, and yet the
plan will STILL show that we're going to make it just fine! To me that
completely defeats the purpose of doing the plan in the first place. But
using a Deadline instead does a couple of very useful things - it clearly
marks the date I need to hit AND more importantly, it shows a) if I'm going
to make it as the plan now stands, and b) let's me see exactly what the
effects are going to be of any controls or changes I apply. Now that's far
more useful than a mere pretty Gantt chart of the plan I hope to accomplish.
Without constraints distorting the plan into painting a false picture of
success (regardless of whether it's workable or not) and lulling me into a
false sense of confidence, I now have a tool I can use to design a plan that
meets the required objectives.

 

[Jan De Messemaeker]

Hi,

I do not have the energy to write as much prose as Steve, just that I agree
with Dave, that when the consequences are dire, you put a constraint rather
than a deadline.
If you present a plan with a later date to an executive you risk being shot
or beheaded on teh spot.
The result is the same - you have to work to avoid the dire consequences.
Meanwhile, be optimistioc and show the result you NEED to realize.
Greetings,

 

[Steve House [Project MVP]]

Jan, you'd never, ever present that plan to an executive until whatever
conditions that caused the late date was resolved so that the freely
calculated date meet the required objectives. Only then do you show it to
the executive. Keep it a deep dark seceret until all the scheduling issues
have been resolved to your satisfaction and the unconstrained plan meets the
requirements. Only then can you show it to him with some confidence that it
really is possible to do it the way you have outlined and have it be a
success. If you present the plan while using a constraint to force a taak
to a required date in the schedule when Project wants to put it elsewhere,
you are promising the boss you can deliver on his expectations when the best
tool you have to predict what is really going to happen in your project is
telling you that it's going to be impossible to do it if you try to work the
plan as you have outlined it. I say that beause the only time you NEED to
use a constraint to put something on a certain date is when it doesn't fall
there of its own accord. If you DIDN'T have to use a constraint to get
Project to put that task on the "correct" date, you'd be able to make the
requirements without worry. The simple fact you have to use a constraint to
get it to come out "right" for the boss is telling you it simply isn't going
to work out as it is supposed to and you WILL, without any doubt, go over
schedule and/or over budget. The act of writing something down in the plan
does not insure it will happen that way and the need to put in the
constraint in the first place is telling you it CAN'T happen the way you
want it to.

I feel the plan is not to document what the stakeholders want to see, it is
the tool you use to decide how to organize a schedule that gives them the
outcome they expect. You can only use it that way if you don't force it to
fib to you about whether your proposed plan is actually going to be
successful. Otherwise it's like the schoolboy who keeps assuring his parents
he's getting all "A"s when in fact he's flunking out.


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

 

[Jan De Messemaeker]

Hi Steve,

Just two thoughts to add
1. In this world of consolidations and Project Server the pM sdoes not
decide when the executive looks at his plan. He may do so at any moment.

2. My advice is that rather than on dates, the PM bases his actions on Total
Slack. What he/she has to work on is negative total slack.

Greetings,

 

[Steve House [Project MVP]]

So, don't publish it to the server until you're resolved all the missed
deadlines. In fact, I think there's an even stronger case to be made for
NOT using constraints such as you suggest in the Server world - as a PM you
are intimately familiar with slack time - how to obtain a report on it and
the report's interpretation - but the Executive and others viewing the plan
probably lack such technical expertise. You'd not publish the plan until
you were very close to transitioning from the planning to the implementation
phase of the project lifecycle. In fact, once you publish the plan and
commence work is when you *really* want MSP to freely calculate the actual
dates that are going to be hit given progress to date. If things aren't
going quite right and it means you'll miss your planned finish date, I
suggest a glance at the Finsh date column should warn you of that fact by
showing the date the present rate of progress is going to put you at. I
want to see the Estimated Actual Completion Date, not the Planned or
Required completion dates, listed there. Using hard finish constraints
makes it ALWAYS look at first glance that you're going to make your
objectives even when you're really running late. You have to know to run a
slack time report for the future tasks and how to interpret it along with EV
reports to get any clue that your project is actually in trouble.

Sure, using slack works well if you know what you're looking at and don't
overlook the fact that you MUST tweak the schedule in the planning phase
until all the negative slacks go away. But it is far more obvious what is
going on in the plan if one sees a nice big red diamond in the indicator
column indicating a missed deadline, a date in the Finish column that shows
where you really are going to end up if you keep on going on your present
path unless you do something to fix it, a pretty green arrow on the Gantt
chart itself showing what your requirements are, and task's end or a
milestone diamond off to the the right of that arrow glowering at you
demanding you figure out a valid way to move it to the left. IMHO, using
constraints and slack time to adjust the schedule worked well enough in its
day before the turn of the century but since the advent of the deadline
field in Project 2000, there has been a better way. Continuing to use the
old-fashioned method now is kind of like writing a novel using a quill pen
and squid ink instead of a word processor. It works, but there are much
better ways now available. <grin>

There's a joke that says the only question you have to ask in the interview
when hiring an accountant is "What's two plus two?" The fellow you hire is
the one that answers "What would you like it to be?" Well, to my way of
thinking using a constraint to make a finish date appear to be on schedule
when it's not (and there would be no need ever to bother using the
constraint to get it to that date in the first place unless it was being
calculated to miss it without putting the constraint on, with the
unconstrained task is being placed later in the schedule than you want it to
be) is the equivalent of that accountant who tells the boss he's making a
profit when the harsh reality is he's losing money by the bucketfull. It'll
keep the boss happy until the day where you promised to deliver the
completed project and have to go into his office with the news that there's
6 more weeks of work to go. "But look here, that spiffy Gantt chart you
gave me for my wall shows it's right on time! What went wrong? Somebody
must not have worked the way the plan said they should - heads will roll!"
But actually, your plan only appeared to be one that would finish on time
when worked the way you outlined it because you used constraints to "fudge"
the dates to appear something other than what was actually possible. If you
don't use constraints to distort the plan, you'll never have to confront
that scenario because you (and your boss) will have known things weren't
going right far enough ahead of time to actually do something about it, the
red marker on the Gantt task table for the missed deadline having been
glowing like the low oil pressure light on your car's dashboard warning you
of trouble as soon as the first hints of problems reared their heads.

Oh, and another point - you can still use your favorite slack time
methodology even if you use deadlines in stead of constraints. Project's
slack time calculations treat deadlines as if they were FNLT or MFO
constraints and produces exactly the same results as you're getting with
your method. In fact, using deadlines instead of constraints is very
similar to using constraints with the "Tasks Always Obey Constraints" option
turned off, except that unlike that option, using them doesn't also disable
any SNET constraints letting tasks move earlier than they should in the
process.

I have to repeat myself - the plan does not exist to document expectations.
It exists to tell you if the work schedule you have in mind is going to meet
expectations or not. Using constraints forces it to tell you what you want
to hear rather than what you need to hear in order to avoid disaster. If
the work plan is going to fail to meet requirements, you need to let your
tool inform you of that fact in time to change it.

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

Hi Steve,

Just two thoughts to add
1. In this world of consolidations and Project Server the pM sdoes not
decide when the executive looks at his plan. He may do so at any moment.

2. My advice is that rather than on dates, the PM bases his actions on
Total
Slack. What he/she has to work on is negative total slack.

Greetings,

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
+32-495-300 620

Jan, you'd never, ever present that plan to an executive until whatever
conditions that caused the late date was resolved so that the freely
calculated date meet the required objectives. Only then do you show it
to
the executive. Keep it a deep dark seceret until all the scheduling issues
have been resolved to your satisfaction and the unconstrained plan meets the
requirements. Only then can you show it to him with some confidence that it
really is possible to do it the way you have outlined and have it be a
success. If you present the plan while using a constraint to force a
taak
to a required date in the schedule when Project wants to put it
elsewhere,
you are promising the boss you can deliver on his expectations when the best
tool you have to predict what is really going to happen in your project
is
telling you that it's going to be impossible to do it if you try to work the
plan as you have outlined it. I say that beause the only time you NEED
to
use a constraint to put something on a certain date is when it doesn't fall
there of its own accord. If you DIDN'T have to use a constraint to get
Project to put that task on the "correct" date, you'd be able to make the
requirements without worry. The simple fact you have to use a constraint to
get it to come out "right" for the boss is telling you it simply isn't going
to work out as it is supposed to and you WILL, without any doubt, go over
schedule and/or over budget. The act of writing something down in the plan
does not insure it will happen that way and the need to put in the
constraint in the first place is telling you it CAN'T happen the way you
want it to.

I feel the plan is not to document what the stakeholders want to see, it is
the tool you use to decide how to organize a schedule that gives them the
outcome they expect. You can only use it that way if you don't force it to
fib to you about whether your proposed plan is actually going to be
successful. Otherwise it's like the schoolboy who keeps assuring his parents
he's getting all "A"s when in fact he's flunking out.


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


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

Hi,

I do not have the energy to write as much prose as Steve, just that I
agree
with Dave, that when the consequences are dire, you put a constraint
rather
than a deadline.
If you present a plan with a later date to an executive you risk being
shot
or beheaded on teh spot.
The result is the same - you have to work to avoid the dire consequences.
Meanwhile, be optimistioc and show the result you NEED to realize.
Greetings,

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
+32-495-300 620
"Steve House [Project MVP]" <[email protected]>
schreef in bericht I have to disagree completely that a constraint is the best way to
schedule
the circumstance you describe here. I suggest that a DEADLINE is the
better
way to show something "needs to occur by that time or the consequences
are
dire." A constraint of any sort limits Project's freedom to display the
tasks where it thinks they should go. But the reason for using
scheduling
software instead of simply drawing task bars in Magic Marker on a wall
calendar is to have a tool that does exactly that - calculates schedules
for us so that we have a tool to use to figure out what we must do in
order
to meet those requirements. As such, we need to allow Project to freely
calculate the results of our potential decisions - if I put Joe on
this
task, will it move my completion up or set it back? But a constraint
says
DON'T show me the results of those decisions and instead just show on
this
date as I dictate whether it actually can happen then or not! If we put
your example of showing up in court at a certain time into our plan with
an
MSO constraint, it's going to show we're going to make it on time
regardless
of whether it's actually going to be physically possible to do so.
The
case
could be in 10 minutes, we could be 1000 miles away and on foot, and yet
the
plan will STILL show that we're going to make it just fine! To me
that
completely defeats the purpose of doing the plan in the first place. But
using a Deadline instead does a couple of very useful things - it clearly
marks the date I need to hit AND more importantly, it shows a) if I'm
going
to make it as the plan now stands, and b) let's me see exactly what
the
effects are going to be of any controls or changes I apply. Now
that's
far
more useful than a mere pretty Gantt chart of the plan I hope to
accomplish.
Without constraints distorting the plan into painting a false picture of
success (regardless of whether it's workable or not) and lulling me into
a
false sense of confidence, I now have a tool I can use to design a
plan
that
meets the required objectives.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



...
Just giving you a hard time, as usual! <evil grin>
I interpret MSO and MFO a little differently than you do. To me, it
means that the task needs to occur at that time or the consequences are
dire. This could be showing up at the courthouse on time or the keynote
speaker stepping up to the podium at 8:00 am Monday morning to start
the conference. There is little or no flexibility. In the first
case, a
warrant may be issued or a hefty fine imposed, in the second, a couple
of hundred people who paid good money for whatever getting antzy by the
minute.
...

Regards,
Dave