activities relationships

Hi Ahmed,

The Start-Finish relationship is almost never used - so I really wouldn’t put too much time in trying to understand it. I’ve been using MSP for nearly 10 years and have never found the need for it. You’re absolutely right in that it can be extremely confusing. Stick with the conventional links.

Cheers.

James.

Dear James,
Thanks a lot and i think u have right its more theoretical relation and i think its related to milestone i mean no time activities!!!:)

You have to be very clear about the statement of the condition that you are imposing with the links.

FS: B cannot start until, or any earlier than, A finishes. This does not mean that B will start when A finishes, since other conditions may make B start later than that.

SF: B cannot finish until, or any earlier than, A starts. Again, other conditions may make B finish later than that.

The condition is always a statement about the start/finish of B relative to the start/finish of A.

Although FS is easier to visualise than SF, they are not that substantially different.

SF leaves you wondering where the start of B is going to be. If you think it is confusing for the guy who is writing it, imagine how confusing it is for the audience.

Good modeling can eliminate the need to use anything other than FS links. If you find yourself trying to use FF, SS, SF links try to find a better model of the project which allows you to use just FS. There usually is one.
Also, avoid the use of negative lag.

Trevor,

I have to disagree with your statement of: "avoid the use of negative lag". This is a perfectly valid "fine-tuning" element of a logical relationship, and indicates that you can probably begin the successor as you approach the end of the predecessor activity.

It must be remembered that there are very few incontrovertible logic-links. Most logic tends to be somewhat "fluffy" of "fuzzy" if you prefer. The amount of fuzziness depends upon the type of project and the assumed content of an activity description. The more general the activity descriptions, the fuzzier the logic. For instance: Design, Manufacturing, Installation. At detailed level, the links would be FS - with occasional negative lags (I prefer the term LEAD). At summary level there would have to be leads.

I agree in that good modelling can eliminate the use of leads. However, in order to get rid of the leads, the level of detail at which you’d be obliged to programme would probably become extraordinarily impractical and cumbersome. To avoid twisting yourself in knots, take a more pragmatic approach to the use of the relationships. There is absolutely nothing wrong in using SS, FF if it is the best indicator of the relationship. A perfect example is "Manufacturing Support". There is no defined content of the activity - it happens on an ad-hoc basis - yet you KNOW that it will be required and it will absorb an element of time - AND it can only finish when the equipment is delivered. It’s most logical relationship, therefore, is FF with the delivery of the equipment or SS with the beginning of the manufacturing.

Cheers.

James.

PS. A programme should be a guide - not a rock tied around your neck.

Naturally, I am compelled to reply, with some explanation of my reasons for avoiding negative lag.

I don’t entirely disagree with your entire position.
In some relatively rare cases it may be reasonable to use SS, FF, SF and/or negative lag.

However, usually when I see it, it is because someone has given up on the modeling before they have chopped up the project into sufficient detail. Also, it is often used as a way to artificially shorten the duration of the critical path and show the project finishing by some deadline date.

Although the plan might look plausible, the problem surfaces at execution.

With a simple FS0 link, the completion of Task A is a distinct event which is a trigger for the start of Task B.

The main problem with negative lag is that the trigger for the start of Task B never goes off because it is always in the future. If the lag was say -5 days you have to guess, because you can’t know, when you are 5 days away from finishing Task A. In a swimming race, the swimmers try to start their dive, say, 1 second before the gun goes off, which looks plausible in the plan, but they don’t know when the gun will go off so they guess, and if they go early they are disqualified. Its a big risk for very small payoff, which might work or not.

Example of why an SS link with positive lag is inferior modeling compared to FS link with zero lag and more tasks detail:

dig 100 metres of trench in 100 days
is a FS predecessor to:
lay 100 metres of pipe in 100 days

This would initially look like a 200 day project, but you may know you can start laying the first 25 metres of pipe when you have dug the first 25 metres of trench. Typically, I have seen this re-modeled as a SS link with 25 days (positive) lag, to make a 125 day project. But it isn’t accurate modeling because there is no way that you can start laying that pipe after 25 days of trench digging unless there really is 25 metres of trench. A better alternative is to chop up the trench digging into 4 x Tasks of 25 metres of trench and make each of them a FS0 predecessor to the 4 x Tasks of laying 25 metres of pipe. Sure, it turns 2 Tasks into 8 Tasks but that’s the price of better modeling, and a very small one. It makes the execution much more controllable and the progress measurement just so much easier.

Trevor,

Please make sure that the trench is compacted and the FDT was done before laying the pipes...

Hi Ahmed,

Agree with James.

Also as much as possible, make your activities relationship simple: FS, SS.

Cheers,

Charlie