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!

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

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,

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.