Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Usage of Negative Lag

17 replies [Last post]
Ritesh Kumar
User offline. Last seen 1 year 39 weeks ago. Offline
Joined: 9 Apr 2006
Posts: 49
Dear All,

Why we should not appreciate the usage of negative lag in schedule? Doeas any one logic why we should we use otr not ?

Reagrds

Ritesh

Replies

Stephen Devaux
User offline. Last seen 14 weeks 2 days ago. Offline
Joined: 23 Mar 2005
Posts: 667
Hi, Rafael. I think you and I are in 99% agreement.

"I will give credit to all your statements as this is in no way in conflict to the statement that how best to split shall be by the scheduler on a case by case, sorry here I do not believe in shortcuts, though I would like them to be valid. Across the board, splitting rules are no good."

We absolutely agree that splitting should be based on a decision -- the issue is, when the scheduler has not recognized the issue, what should the forward pass algorithm decide? Someone once observed that not making a decision is also a decision. The default of not splitting decides that a 100% - 0% split is the valid one. And then it further determines that the start will be delayed, and the project will be delayed, a course of action that is very rarely mandatory, and one that most schedulers would avoid if they understood the mechanics and implications.

If I am building a fireplace that contains 80 bricks, the fact that I can’t FINISH inputting the 80th brick until a certain point should have no impact on when I lay the previous 79, or, indeed, on when I START to input the 80th brick.

I think that the "early dates" algorithm should attempt to give the earliest possible dates for the project to be completed -- and that means not arbitrarily deciding that two predecessor events (the starts of the two tasks in the SS relationship) must be delayed just because of a usually unrelated relationship that controls one of their finishes.

HOWEVER: I would be pretty comfortable with the current situation if, as you suggest, the software would flag the issue for the scheduler to make the decision. (Whatever way the default is, we completely agree that the scheduler should be "pinged" to make the final determination.)

"Even DRAG is not perfect, but can provide some guidance and some sanity when you have no other option than compress the schedule."

DRAG not only isn’t perfect, it’s a pain in the butt! It costs our project time and money! But DRAG is like gravity -- it exists and is slowing us down, whether we choose to recognize it or not. The Spider algorithm is simply a measurement tool, calculating just how much a given task is slowing us down. Just as with DRAG, we can use info about gravity to build a rocket, or we can ignore it -- but ignoring it doesn’t make either gravity or DRAG go away.

"Thanks for your comments about the need for these flags, Vladimir do not add functionality to Spider Project just because you ask him, it has to be useful. That he included DRAG computations into Spider is because although not an absolute answer it is useful. Hope Vladimir get our message, I doubt any other developer will take care the way he does, but maybe eventually the other will follow to the benefit of all."

To be fair, Spider has an unfair competitive advantage over other PM software packages -- and that’s Vladimir, someone who really understands project management in a very profound way. There are a number of other Total Project Control metrics that I wish he would incorporate (DRAG Cost, the CLUB, DIPP, and the DIPP Progress Index s-curve, to name a few) -- but I’m just really happy that he recognized the value of DRAG.

Unfortunately, there is still a PM education hurdle that has to be surmounted for even DRAG to provide real competitive edge. (When most people currently can’t compute total float, or, indeed, find a critical path with both hands and a mirror, DRAG will seem of little value.)

As most people invest in projects to make money, I think computing DRAG Cost would make the value of DRAG much more obvious -- but maybe that will come in time. (I certainly think that Spider is about the only package with the functionality to do it in a meaningful way.)

Fraternally in project management,

Steve the Bajan
Rafael Davila
User offline. Last seen 10 hours 16 min ago. Offline
Joined: 1 Mar 2004
Posts: 5229
Stephen,

I will give credit to all your statements as this is in no way in conflict to the statement that how best to split shall be by the scheduler on a case by case, sorry here I do not believe in shortcuts, though I would like them to be valid. Across the board splitting rules are no good.

I particularly liked your prior comment that no model is perfect. I would add could be a very practical approximation and the modeling need might change as the job moves and unexpected events happen.

Even DRAG is not perfect, but can provide some guidance and some sanity when you have no other option than compress the schedule.

"it’s really horrible that it should occur just because of the way a software algorithm is written" - If the algorithm is clear then the issue is not in the algorithm but still is a valid question. Perhaps those flags can help us all, I need them because I am not perfect and have fallen before on a few of these traps.

Thanks for your comments about the need for these flags, Vladimir do not add functionality to Spider Project just because you ask him, it has to be useful. That he included DRAG computations into Spider is because although not an absolute answer it is useful. Hope Vladimir get our message, I doubt any other developer will take care the way he does, but maybe eventually the other will follow to the benefit of all.

By the way about splitting activities and make them non-continuous, we avoid doing this, we usually resort to reduce manpower loading or use partial assigments. Continuous PDM forces you to do the correct modeling.

Best Regards,
Rafael
Stephen Devaux
User offline. Last seen 14 weeks 2 days ago. Offline
Joined: 23 Mar 2005
Posts: 667
Rafael, so interesting that you raise the "reverse CP" issue -- Vladimir and I had a long talk about it last year!

I believe that:

1. The CPM algorithm default forward pass should always be to make the early dates (and completion) of the schedule as early as possible.

2. The FF (and SF!) relationship should, by default, ONLY control the last nanosecond of the successor.

3. The number of occasions where the activity CAN’T be split is small.

4. More than 95% of the time, a planner whose schedule winds up being longer due to this anomaly would elect, if they recognized the situation, to split the activity.

5. Occasions where reverse CP is making the CP longer should be flagged by the software and give the user a warning notice.

Too many people die because projects take an extra week or day -- bad enough that this occurs due to complex work, insufficient resources or incompetent schedulers, but it’s really horrible that it should occur just because of the way a software algorithm is written.

Fraternally in project management,

Steve the Bajan
Rafael Davila
User offline. Last seen 10 hours 16 min ago. Offline
Joined: 1 Mar 2004
Posts: 5229
Vladimir,

http://www.mosaicprojects.com.au/PDF/Links_Lags_Ladders.pdf

By competing SS and FF links, I am referring to the case as shown in figure 12 of the above reference, a typical case where you shall decide whether to split or not to split your activity.

Figure 12

The other case is shown in figure 14.

Figure 14

As we have discussed before I am convinced the general rule shall be Continuous PDM while using Non-Continuous PDM across the board is wrong. Non-Continuous modeling can be done on exception basis within Continuous PDM rules that keep you in full control.

I am looking for a way for the software to flag the locations where this occurs. Then I will decide how to handle each case. Most probably continuous PDM will be the governing rule but there might be occasions it will not and I do not want to miss them.

This is not a flag like for out-of-sequence I believe shall always be corrected, no, here in most occasions it will be the appropiate choice, no correction in logic needed.

My problem with the filters is that I can create filters from the Gantt View and from the Links View but not sure if complex filters that combine filters from each view can be valid, I do not believe so.

I would not call these to be logical inconsistencies because this is how Continuous PDM is intended to work, perhaps possible traps the scheduler must be aware of. Some help of the computer to flag these will do no harm. These can be pre-defined filters using some programming not available to the user through normal filter creation, no problem at all, kind of unique need, keep it simple.

Best Regards,
Rafael
Rafael,
if activity is splitted manually you shall investigate if the last portion was not delayed. If there are many splitted activities this work will become time consuming. If last portion was delayed the links shall be reconsidered.
The problem exists when resources are limited.

What do you mean by competing SS and FF links?
All links are No Earlier Than, so only some of them are driving at any moment.

If an activity driving incoming link is FF and driving outcoming link is SS increasing its duration can shorten some path. If this activity is critical it can shorten project duration. I will think about filters.

Best Regards,
Vladimir
Rafael Davila
User offline. Last seen 10 hours 16 min ago. Offline
Joined: 1 Mar 2004
Posts: 5229
Vladimir,

However, if activity splitting is done manually and investigated then it can be a good decision as at times it can solve some issues on resource availability. I am an advocate of Continuous PDM and believe that Non-Continuous PDM shall be an exception that can be dealt under the rules of Continuous PDM simply by making appropriate management decisions on whether to split or not an activity, this from your teachings (or I am wrong?). Another option can be to increase the duration to fill a gap between competing SS and FF links if this is the case.

Another interesting case is when the increase in the duration of an activity decreases the duration of the job, this shall be dealt on a one by one case, same as above.

Perhaps you can help me with a filter (at Spider Forum) to flag those activities: those having competing SS and FF links and those that by increasing their duration their successors start date can be reduced by doing so.

Best Regards,
Rafael
If the whole activity will be delayed it is not a problem because it follows schedule logic.
But if only a part of activity will be delayed it may become a problem because the break is artificial. Negative lag does not mean that the last portion of activity will be delayed but the first portion can be done at any time.

Best Regards,
Vladimir
Stephen Devaux
User offline. Last seen 14 weeks 2 days ago. Offline
Joined: 23 Mar 2005
Posts: 667
"Stephen,
use volume lags, they are much more reliable.
Breaking activity is not a good decision - the last portion may be delayed due to limited resource availability"

Vladimir, you don’t have to convince me -- you just have to convince all the other software packages that don’t support volume (i.e., work) lags. (As far as I know, there’s only one package that supports volume lags -- I think it’s called -- uh -- is it called something like "Spider Project"?)

"Breaking activity is not a good decision - the last portion may be delayed due to limited resource availability."

But, using SS lags, the whole activity could also be delayed by resource unavailability, right?

Fraternally in project management,

Steve the Bajan
The schedule model shall reflect the reality.
Negative lags can be used but if possible shall be avoided.
The situations when they exist in the real life are very rare.

Stephen,
use volume lags, they are much more reliable.
Breaking activity is not a good decision - the last portion may be delayed due to limited resource availability.

Best Regards,
Vladimir
Shah. HB
User offline. Last seen 15 weeks 22 hours ago. Offline
Joined: 25 Nov 2008
Posts: 773
Hi Rafael

Many thanks for the link
Rafael Davila
User offline. Last seen 10 hours 16 min ago. Offline
Joined: 1 Mar 2004
Posts: 5229
Stephen

Agree with every word of yours. I can even imagine if duration of A = 1 day, then in such case probably I would use negative lag.

As you just said “I HAVE used negative lag: when to have used positive lag would have been even more fraught with uncertainty and risk”.

Perhaps this statement of yours says more than the whole article.

Best Regards,
Rafael
Stephen Devaux
User offline. Last seen 14 weeks 2 days ago. Offline
Joined: 23 Mar 2005
Posts: 667
Good article, Rafael. Thank you.

In general, I stick to the dictum that all models are distortions of reality -- use whichever model is best for a given situation, but always be aware that it is imperfect.

I try to stay away from negative lags, as I believe they increase risk -- if you plan something to occur 8 days before something else ends, what happens if the "logic predecessor" finishes 30 days late, or NEVER occurs? You have undertaken action, effort and expense needlessly.

On the other hand, I HAVE used negative lag: when to have used positive lag would have been even more fraught with uncertainty and risk. For example, if I want B to start 3 days before A finishes, but A has a duration of 20D. Which way of modeling is more dependable: A --> B with SS + 17, or A ---> B FS - 3? In most cases, I would likely determine that the latter way is a more dependable "model".

(Of course, let me admit that the most reliable of all is:

1. What is the event expected to occur 17D into A that will allow B to start?
2. Decompose A at the "interim deliverable", into A (17D) and A’ (3D).
3. Make A (17D) a predecessor of both A’ and B.

I have not always found it possible to get the precise data to use the third model, but it is my preference, when possible.

Fraternally in project management,

Steve the Bajan
Rafael Davila
User offline. Last seen 10 hours 16 min ago. Offline
Joined: 1 Mar 2004
Posts: 5229
Shah. HB
User offline. Last seen 15 weeks 22 hours ago. Offline
Joined: 25 Nov 2008
Posts: 773
Hi Shareef

FS link is a sub-logic present inside the SS link.

For example Installation of pipe supports tied with ss+7 days lag to Installation of main pipe

It means portion of work chunk of pipe supports on completion in the particular area installation of pipe begins
Mike Testro
User offline. Last seen 1 week 4 days ago. Offline
Joined: 14 Dec 2005
Posts: 4418
Hi Shareef

You need to follow location based planning where different tasks follow a natural FS logic.

It does not take long to set up a cascade of tasks for a set location or chainage with FS links and then copy and paste for as many times as you need.

Then you just add FS links between the zones and put them all under a summary bar.

Once you have set up a cascade then save the descriptions and durations in an excell file and re use them whenever you want.

Best regards

Mike Testro
Shareef Abdul Azeez
User offline. Last seen 2 years 39 weeks ago. Offline
Joined: 19 Sep 2005
Posts: 183
Hi Mike

I have been wanting to ask this many times as I see you always recommend a FS relationship only and emphasise not to use Lead / Lag.

For example if you have a road work with Unclassified excavation for 30 days then Subgrade for 30 days then Subbase for 25 days and so on...

Normally after the the first 7 days we will have enough open area to start Subgrade works and after 7 days of subgrade work we will have open area for subbase.

The best way for me would be to use a SS & FF logic (although some times this logic starts acting funny when the successors are driven by the finish link).

Now if I use only FS logic for this I will have to break down the activity into a lot of small activities.This is just the case for road works and when the scope of work is more I will only have time to make WBS structure breaking down the same work into a lot of small parts....

Is it really worth it?

I understand the first thing you would say is my activity duration of 30 days is too long(yes, generally should not be more than 2 or 3 update periods).

Normally for Tender Programmes I donot think we would require such level of details.

Best regards
Shareef A Azeez
Mike Testro
User offline. Last seen 1 week 4 days ago. Offline
Joined: 14 Dec 2005
Posts: 4418
Hi Ritesh

The only use for lead lags is to establish a curing or drying out period - and it should be set in calendar days.

No other lead lag form has a place in a properly prepared programme.

Best regards

Mike Testro