moving task bars

[Nils214]

ok, this is weird. I have two final tasks at the end of my project (I did
not create this project buy am trying to adapt it to new information). Now
when I move these two tasks to a position following all the previous task,
they cause approx 1/3rd of the other tasks to move to the same end date. I
have set some of these tasks to 'alap' and some to 'asap'. Originally the two
final tasks did follow the previous tasks, but after I changed the project
start date from mid 2005 to jan 01st 2006, they project has rescheduled and i
am faced with this latest incomprehensible problem.
Help, and asap if possible
Thanks
Nils214

 

[Jan De Messemaeker]

Hi,

It is normal that alap tasks move to really alap, often to the end of the
project.
And don't the asap tasks have links with the alap tasks?

 

[Nils214]

Thanks for the reply.
there were no links at all between the final two tasks and the 'alap or asap
tasks. The alap tasks were linked to the asap tasks, and the asap tasks
followed from an earlier task that was on the critical path. By my logic the
alap tasks should only finish at the start of the following tasks that were
set as asap, but ended in line with the final two tasks when I moved these
beyond the asap tasks. Evidently this was not and is not the case...illogical
maybe?
Anyway I have subsequently solved the problem by resetting all to asap and
linking in the previously alap tasks to preceeding tasks to ensure the logic
followed correctly thro the program.
All seems ok now.

 

[Jan De Messemaeker]

Hi,

May I first quote you?

By my logic the
alap tasks should only finish at the start of the following tasks that were
set as asap

Wel, by my logic as well, and I've been asking for that development over the
past 5 years or so, but to no avail. An ASAP task becomes critical and is
"stronger" than any asap following, causing those to become critical as
well.

 

[Trevor Rabey]

ALAP in MSP is, unfortunately, dicey.
It's too strong.
It will suck all of the float out of it's successors.

I just about fell off my chair when I discovered it.
I was explaining to someone how to model purchasing to make material
delivery occur just in time, like this:

100 order ALAP
101 deliver FS100+90ed ALAP

102 construction
103 Tasks
104 lay bricks FS101, FS Tasks
105 more
Tasks

106 end

If 104 is already on the critical path, 101 can't push it, nothing bad
happens, it works and you get the latest that you can place the order
without holding up construction.
.....but what a surprise if 104 is not critical before you link it to 101.
All of 101's successors go critical!

In P* there is a zero free float constraint. That's good. Better than ALAP.
P* also has a longest path calculator, which makes up for leveling ruining
the critical path. That's good. Also, the jumping along the predecessor
chain is good. One day, MSP will have this too.

There are ways around it. if the alap is taken off 100, 101 their float and
LF still gives the answer for latest to order.