Constraints and lags together

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 

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.

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.

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

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. 

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".

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.