you do have to progress a large lag by reducing it if the predcessor moves to the right. Inessence the large lag is actiing as a place holder.
for example
orginally
Activit A has a -------FS relationship with 100 day lag to Activity B this holds activity B in place since a start constraint can not be used.
Next update
Activity A has slipped to the right by 10 days therefore to hold Activity B in place you must reduce the lag to 90 days. Inessence you are progressing the lag to hold Activity B in place.
That is what I meant by progressing the lag its a matter of reducing the duration to hold the date of its successor.
From your explanation, you have FS relationships with lags in the logical network that impose a minimum interval of 125 days from MIL10 TO MIL11 and another minimum interval of 44 days from MIL11 to MIL12. In most cases using such lags would be poor practice as Zoltan noted.
The Finish-on constraints are double-sided; a combination of Finish-on-or-after and Finish-on-or-before - both with the same constraint date. The Early Finish of MIL11 will be the LATER of the constraint date or 125 days after MIL10's EF. The Late Finish of MIL11 will be the EARLIER of the constraint date or 44 days before MIL12's LF. As a consequence, the milestone will always have Total Float less than or equal to zero. It seems to me that the primary justification for such a constraint is to satisfy a project manager/Client/Owner who prefers the milestone to sit firmly on its established - latest allowable - date during project execution. This is typically not justified by contract language and can be considered poor practice.
Combining long lags with Finish-on constraints and logic seems doubly-poor in my view, even though it is "possible".
Member for
21 years 8 months
Member for21 years8 months
Submitted by Rafael Davila on Fri, 2018-02-02 22:57
A lag do not needs to be progressed by the scheduler; when active it is progressed automatically upon update as elapsed time, only if scheduler want to modify the lag then he must do so.
Lag becomes active as soon as predecessor node starts.
Member for
16 years 3 months
Member for16 years4 months
Submitted by Zoltan Palffy on Fri, 2018-02-02 14:46
Member for
16 years 3 monthsyou do have to progress a
you do have to progress a large lag by reducing it if the predcessor moves to the right. Inessence the large lag is actiing as a place holder.
for example
orginally
Activit A has a -------FS relationship with 100 day lag to Activity B this holds activity B in place since a start constraint can not be used.
Next update
Activity A has slipped to the right by 10 days therefore to hold Activity B in place you must reduce the lag to 90 days. Inessence you are progressing the lag to hold Activity B in place.
That is what I meant by progressing the lag its a matter of reducing the duration to hold the date of its successor.
Member for
18 years 11 monthsrox Ira,"Is that possible?"
rox Ira,
"Is that possible?" Yes, it is.
From your explanation, you have FS relationships with lags in the logical network that impose a minimum interval of 125 days from MIL10 TO MIL11 and another minimum interval of 44 days from MIL11 to MIL12. In most cases using such lags would be poor practice as Zoltan noted.
The Finish-on constraints are double-sided; a combination of Finish-on-or-after and Finish-on-or-before - both with the same constraint date. The Early Finish of MIL11 will be the LATER of the constraint date or 125 days after MIL10's EF. The Late Finish of MIL11 will be the EARLIER of the constraint date or 44 days before MIL12's LF. As a consequence, the milestone will always have Total Float less than or equal to zero. It seems to me that the primary justification for such a constraint is to satisfy a project manager/Client/Owner who prefers the milestone to sit firmly on its established - latest allowable - date during project execution. This is typically not justified by contract language and can be considered poor practice.
Combining long lags with Finish-on constraints and logic seems doubly-poor in my view, even though it is "possible".
Member for
21 years 8 monthsA lag do not needs to be
A lag do not needs to be progressed by the scheduler; when active it is progressed automatically upon update as elapsed time, only if scheduler want to modify the lag then he must do so.
Lag becomes active as soon as predecessor node starts.
Member for
16 years 3 monthsyou donot want finish on you
you donot want finish on you want finish on or before
why do they need the lag ? a lag need to be progressed I would NEVER use such a long lag
Member for
7 years 9 monthsHi Zoltan, thank you for the
Hi Zoltan, thank you for the answer. They have a "finish on" not "finish on or before" constraint. It is not float what they have, but lag.
Member for
7 years 9 monthsHi Zoltan, thank you for the
Hi Zoltan, thank you for the answer. They have a "finish on" not "finish on or before" constraint. It is not float what they have, but lag.
Member for
16 years 3 monthsok lets clear a few things up
ok lets clear a few things up with the termonology before we analyze this
whan you say finish on constrtaint Can I assume you mean finish on or before constraint ?
whan you say have 125 and 44 days of lag do you really mean days of float
a lag is different than float.
if the answer is float yes they can have float this much float based on thier predecessors and successor