Alex, first off:

In reading your response in the other thread, i discovered I’d made a typo in listing the activities in the proposed network.
Correct is:

A 10d No preds
B 10d Pred: A/FS0
C 10d Pred: B/FS0
D 5d Preds: A/FS0, B/FF5
E 10d Pred: D/SS5
F 10d Preds: C/FS, D/FS, E/FS

not...

F 10d Preds: D/FS, E/FS

Now there are no "open end" activities -- all except the single sink activity have a finish have a finish successor. Yet the project schedule is still five days loner than it needs to be.

The problem is caused not by open end activities, but by the way the algorithm computes the early start of activities with FF and/or SF predecessors. ANY project potentially can have this problem, if the said activity has an SS successor -- it’s not at all unusual.

Dieter,

I really have to respectfully disagree with you -- there are many, many activities in which the finish of the task is constrained, but has no impact on when it can start. If as in the example, the said activity also has an SS successor, and may be on the CP, then we should always consider, and usually implement, a schedule by which we start it ASAP and allow only its finish to be constrained (as is implied by the FF predecessor). And i am sure that this is what you, as a competent scheduler, would always do -- to do otherwise is to delay the project completion for no reason other than its how some computer programmer who doesn’t know his elbow from a hole in the ground coded the algorithm.

Razi, it’s not about "Driving Relationships" (and really, I do understand critical path and have been teaching and consulting about it for 20 years); it’s about an algorithm written by a progarmmer who took a short cut:

The Finish of Activity C is constrained by the FF from B. Thus the Late Start of Activity C is also constrained. But the Early Start of C is NOT constrained by when it can finish. It’s ES is only constrained by the FS from A -- if you do the forward start manually, you see this. C can start as soon as A finishes. But it’s much simpler for a computer programmer, who probably couldn’t find a CP with both hands and a mirror, to simply have the finish date and duration of Activity C override the "definition" of early Start, i.e., the earliest time that an activity can start.

Most of the time, this does not matter (and I’m sure most schedulers aren’t even aware of it). However, in the present example, because of the SS successor to C being on the CP, we have a situation where (1) the project duration is lengthened, and (2) the project gets shorter as one of the "CP" activities gets longer (and vice versa)! If that isn’t a dead giveaway that something’s wrong, I don’t know what is. By noticing that the schedule can be shortened by starting C earlier than the software currently says it can, we can save days (perhaps weeks in some cases!) on the schedule.

The CPM algorithm should not assume that one thing is constrained just because something else is -- in this case, that an activity’s start is constrained because its finish is. If such is the case (as is the rare occurrence), the scheduler should input a Start No Earlier Than constraint.

The true picture is that a milestone representing the finish of C is the only thing constrained by the FF relationship. And then the project should finish a week earlier.

Dietrich, far from this sort of situation not being possible, it’s actually quite common. I assume that you sometimes use an FF or SF constraint --and ANY time you do, the software will compute the ES of the successor based on its duration. If that successor activity also has an SS (or SF) successor (quite common, surely), the schedule of that path will be unnecessarily delayed -- and if that path is the critical path, the scheduled completion will be delayed!

Given this sort of situation, a good scheduler should look to see if C can be started earlier. And the vast majority of time, in my experience, it will turn out that it can be (especially when the alternative is to add time to the schedule).

Unfortunately, it’s hard to see these situations! Schedules are constantly being unnecessarily elongated due to resource shortages, work problems, union contracts, subcontractor inefficiencies, and customer whim. It’s unfortunate that sometimes they’re also bloated due to a computer programmer who has no concept of the implications of an algorithmic decision.