having item float with another item

Mike,

Critical means if the activity is delayed at all, it will delay the project. Since you have constrained the notification to occur as late as possible, and you cannot start the (critical0 shutdown without it, then the notification will and should also show as critical. I am not aware of a way to avoid showing it as red without removing all the other red from the bar chart as well.

I'm a bit confused by the rest of your message:

-if the date is correct, why is it a problem that it is at the very begining of the schedule?

-if the date is correct, why is it a problem that it is 6 months from now?

-When you say it shows a -31 day delay, what do you mean? Delay vs what? The baseline? Or do you mean negative float? What is the name of the column that shows -31 days?

PS: Please only click the "SAVE" button once when posting. -You keep sending a lot of duplicate messages

Mike, when you assigned the give the notice activity the zero-float constraint, did you set it to zero free flaot or zero total float?

If you use zero free float, it shouldn't be showing as critical unless the shutdown it refers to is also critical.

If you used zero total float, it will be showing as critical because that's what zero total float means!

Mike,

Does give 7 day notice for shutdown have another successor other than shutdown station?

I am assuming notice to proceed and shutdown station are not in the critical path as you are not showing them bold and therefore there is a possibility the give 7 day notice for shutdown is critical because it is in another chain that is critical, perhaps an open ended chain.  

Maybe this is the schedule you added the additional successor as to check what happens.

The following is another way to model the 7 days notice that can be implemented with P3, is based on logic always forward, does not require use of constraints and is not invalidated with additional successors but kind of complex.

This is one of the reasons I have been asking for a Strict("fixed") Link Activity type. If you use such activity type for the 7 days notice with a d=0 and FS(7 days lag) strict("fixed") link the precedence would be correct, not prone to error and simple. Perhaps shall be named "Float with another". At the moment we have no other option than to deal with what we have.

Best regards,

Rafael

Faiz,

Here there is no reason you cannot use forward logic, the SS Relationship with a lag of +12 Days is one option but suggest adding a FF lag to make sure all Blockwork finishes before Plaster Finishes if there is a slower than expected progress for the Blockwork activity.

Splitting the Blocwork activity as follows is another option, takes more steps but might be favored by those who want the schedule to be as transparent as it can be.

Spilt Block Work into two,  [1] Blockwork A1 d=12 days and [2] Blockwork A2 d=2 days

Link [1] Blockwork A1 to [2] Blockwork A2 with FS(0 lag)

Link [1] Blockwork A1 to [3] Plaster with FS(0 lag)

Link [2] Blockwork A2 to [3] Plaster with FF(2 days lag)

You will get the following.

[1] Block Work A1..........XXXXXXXXXXXX

[2] Block Work A2.................................XX

[3] Plaster............................................XXXXXXXXXX

Note that you estimate 2 days for Blockwork A2 but it can still be delayed until there are 2 days left to finish plaster, this requirement you can change if it is another.

Your approach to solve the issue using FS with negative lag I have seen common on MSP schedules, it works but at the expense of transparency, the negative lag debate will go on forever. In this case [FS(-lag)] I am not that picky and can accept it as a less favored option in this case, different from the "just in time" models.

Best regards,

Rafael

NEVER SAY NEVER

Hi Rafael,

You Mentioned here that One Should Avoid giving Negative lag.See the Below mentioned Example,

Block Work             14 Days

Plaster                    10 Days

And Situation is that we need to start the plaster work 2 days before the Finish Of Block Work.So If I Follow your concept I'll give SS Relationship with a lag of +12 DAys,

If I follow my practice i Would Give FS Relationship with -2 Days Lag.

What is Apropriate Approach??

Regards,

Faiz

Mike,

An example of when you can use the zero float constraint and more than one successor is when you have two activities in the future, depending on the progress which one starts first can switch but you need to issue the notice before the first successor starts. Schedules with thousands of activities can have a few of these occasions.

You get into trouble with zero-free-float activities when you use them to drive a successor.

If you work on this side of the Atlantic only contractual milestones are allowed constraints but this example is difficult if not impossible using the logic option and doubt about the volume lag option.

ALAP = zero free float constraint

NEVER SAY NEVER

Still the general rule for good practice is that you shall not use constraints when it is feasible to model it using logic.

Mike,

Yes it should work OK in the future, so long as you do not add any additional sucessors to the notice activity -as Rafael pointed out, this can lead to some serious schedulnig errors. -I can't imagine why you would want to, but if you think there's a risk of this occuring, include wihin your regualr update procedure a quick filter check of all activities with zero free floats . 

Since you're using P3, you won't be able to use the volume lag solution that Rafael gave you. I'm sure Rafael knows this -it's just his subtle way of making us all jealous about the software he gets to use ;o)

Mike,

You asked, "do you think this will consistently work in the future ?" Well not necessarily, if you add another successor to the notice activity it can be dragged back by the new successor.

I prefer avoiding both, the zero free float constraint and the negative lag, both can represent reverse logic at some point in time.

It can be done in different ways.

The following figure shows a possible way I would handle the issue today.

1. Trigger 7 days notice [d1] after some volume of work is performed on predecessor activity [d3], such that remaining volume equals ~ the required lag. A spreadsheet can be convenient to do the math if on hundreds of activities.
2. Shutdown [d2] will be dependent on the notice [d1] and on the actual fulfillment of the finishing of the driving predecessor [d3].
3. Note seven days notice can accept other successors [d0] without invalidating the model.
4. Note Predecessor activity [d3] was not split, no additional activity was required and the model requirement for the predecessor activity be scheduled as a continuous activity is met.

If you do not have volume lag then splitting the activity [d3] might be your best option, better splitting the predecessor than using negative lag, better than using zero float constraint.  Same as with my option a spreadsheet can be of help if talking of many such cases.

That we got away with the negative lag option does not mean it was good practice. It was not a catch 22 but wrong modeling practice. At that time I was not aware of the issues, I became aware of the issues here at PP.

Reverse logic breaks the rules of the physical world you are trying to model. You cannot go back into the future to determine when in the future an activity finished and then trigger a response into the past. Reverse logic can create problems with claim analysis, an issue that have been presented before at PP.

In summary;

1. negative lag option will yield wrong float values and the requirement for notice will not be enforced by logic,
2. even when the zero float constraint option can model within some limitations "just in time" it is reverse logic and can be invalidated by adding a successor to the notice activity,
3. the activity splitting option provides true forward logic but splits the activity,
4. the volume lag option keeps the forward looking logic, is not invalidated by adding another successor and does not require an additional activity,
5. there are other more complicated options.

It is up to you.

Best regards,

Rafael

From, http://www.htcprojectcontrols.com/TTB2004-2.pdf

 "However, P3 does not provide a consistent result by using the lag value."

 Mighty P3 is not as omnipotent as some believe.

I do not like the idea of using negative lag as it allows for modeling the impossible, same as with constraints that create negative float, they allow the plan to be based on an event in the future driving an event in the past. This is wrong modeling, but what if the reference is correct about P3?

I remember a job in which the not to do list was endless; no negative lag allowed, no constraints allowed except those contractual (using software that create negative float under these constraints) and many more.

We were required to plan a coordination meeting two weeks before the installation activity for hundreds of activities. We were using Primavera SureTrak and I do not remember how it behaves under this specific issue as compared to P3, at this moment I no longer have access to P3 nor SureTrak.

How would you model this without the use of negative lag nor constraints?

A Catch 22?

Finally we got a waiver to use negative lag, the Owner insisted on no constraints other than contractual.

Never say never, under certain circumstances these "forbidden functionalities" do their work, it is up to you to make good use of them. Good practice shall not forbid them but require you to prove them adequate.

Give it a FS relationship with predecessor and successor, no other relationships, put a 7d lag on the sucessor, and constrain it to have zero free float.

Does this work? If not, please describe what goes wrong.