Stephen,

Be happy, it is at the playoffs that the series count, now it is just practice, remember the Bambino.

I disagree with regard to that we disagree. I agree with your point about the warning. You are correct, it might be overlooked, a warning is welcomed. Perhaps the warning can be toggled on and off but shall be present at some kind of schedule run report. I would toggle off the warning as I would keep reverse CP on most situations unless critical, activity splitting is not a solution to be blindly applied.

Enjoy the cricket game.

........

oops ,   ... sorry

Stephen,

-"The CPM algorithm should be designed to provide the shortest possible schedule given durations and dependencies. Ask most schedulers and they'll tell you that is what it does -- and they usually don't know about the anomalies. To allow a situation where the project can be made shorter by making a CP activity longer (but not by splitting it!) is an absurdity."

The above statement is wrong. The Continuous PDM is a model that has its rules, software that is designed under the Continuous PDM and breaks its rules is wrong. Don't blame the "rats" for the misunderstanding on how the model works, in any case blame the keyboard jockeys that believe they understand Continuous PDM just because they can type some garbage into their schedules. The poor kids cannot understand that if by increasing an activity duration this moves ahead the start of the activity and therefore move ahead the start of successors linked by the start node, elementary math.

The following is a sample job where reverse logic is used, merely by looking at Drag ( a negative value, how about that? ) and Superfloat you will be able to predict schedule performance as you increase/decrease activity duration. With these metrics you will be able to identify reverse logic and even decide when and how to split some activities when convenient.

Two activities of different durations linked by SS and FF links of equal lag can create a case of reverse logic that can be solved by splitting the activity, Superfloat will also be helpful here, perhaps the more common case of possible "reverse logic" in Continuous PDM models. Be ware that depending on how you want your model to perform this might or might not be a case of unforeseen "reverse logic", but the metrics is there for you to verify. Applying the split or no split across the board to all activities is wrong modeling.

Best Regards,
a proud "rat", MSCE class of 1978

I understand you love baseball, but I am A YANKEE FAN, there is nothing like sweeping the Red Sucks. BU should be moved far from Fenway, it brings bad luck, it is not the "Bambino".

Hi Stephen,

you wrote "As far as I know, no current s/w has that option."

Look at Super Float in Spider Project.

Best Regards,

Vladimir

Hi, Miklos.  Very interesting discussion.  And I'd love to meet and discuss further!  Interestingly, Vladimir Liberzon and I had a discussion on precisely this topic two years ago in my apartment in Boston, when he showed me the new version of Spider Project that computes critical path drag. 

Although my niece has spent a lot of time in Indonesia, I doubt I'll ever get there, but I'll buy lunch if you ever get to Boston! And then we can exchange books.

Your description of how (most) CPM algorithms work is right on target -- the issue is whether that is how they should work. I'd add two exceptions to the "most" above (and you may be aware of both):

1. PROJECT/2, the first commercially-available CPM algortihm was developed at MIT in the mid-1960s and marketed by Project Software & Development, Inc. (PSDI) of Cambridge, MA. It had a second option for the backward pass called the "slip" option which would allow an otherwise unconstrained activity late finish to slip as far as it could go without delaying the end of the project.  This resulted in some activities having different float totals on their start and finish.  In my opinion, this was an enhancement in that it drew the scheduler's attention to an alternative option (often one that provided an opportunity for less resources). As far as I know, no current s/w has that option.

2. MS Project limits the user to only one relationship between any two entities.  Without additional milestones, this causes an unnecessary "Procrustean bed" where an activity of 30D duration whose first day is on the CP, but whose finish may have 200D of float, shows as critical with zero float/slack. And to compute the very important critical path drag, you have to have correct float totals.

As you wrote: "PDM has got a basic hypothesis for activities which is: activities should carry out with the same intensity without interruption."  This too, I believe, was because the original MIT s/w (which was actually called PROJECT -- forerunner of PROJECT/2) was programmed that way. In those days, it was simply much, much easier to "program in" such a rigid hypothesis than to actually come up with alternative algorithms. Unfortuantely, I believe they absolutely chose a bad hypothesis, and one that has been delaying projects and costing both time and lives ever since.

Are there tasks that cannot be interrupted and must be carried out with the same intensity throughout, like pouring cement? Of course.  But is that usually the case?  Absolutely not -- that is the tiny percentage of cases. Should schedulers break up tasks when their intensity can be varied, or even use only FS relationships, as Mike Testro recommends? Probably -- but in my experience: (a) schedulers won't do it, and (b) if they do, it will lead to longer projects. 

As mentioned, people die because of longer projects: hospitals, potable wells, pharmaceuticals, disaster relief, defense systems... It's bad enough that people die because the work takes time, or there aren't enough resources.  But surely it's a disgrace to our shared profession that people die because of the way a bunch of 1960s graduate students at MIT coded their software! And schedulers blithely arrange 10,000-task schedules without realizing that the "reverse CP anomaly" of an FF relationship preceding an SS relationship is adding several weeks to their schedule. (If they noticed, they would fix it, because it is almost certainly not a "pouring concrete" instance.)

The CPM algorithm should be designed to provide the shortest possible schedule given durations and dependencies. Ask most schedulers and they'll tell you that is what it does -- and they usually don't know about the anomalies. To allow a situation where the project can be made shorter by making a CP activity longer (but not by splitting it!) is an absurdity.

Finally, there is the omission of the critical path drag (and drag cost!) calculation. The fact that the software quantifies the stuff that's OFF the CP (float) but quantifies nothing that's ON the CP is bizarre!

1. Information about CP activities is (if you'll pardon the expression!) critical! To shorten the schedule or pull in a subdeliverable, either up front or when attempting recovery, is hugely aided by drag calculation.

2. People's attention is drawn to what is measured. Measure only float, and attention is drawn to non-critical tasks, and dangerous techniques like "pacing the project" to the CP's length, rather than shortening the CP, become standard. (See William Duncan's article: "Scheduling is a Drag" at http://www.projectsatwork.com/content/articles/246653.cfm )

3. Float is relatively easy to compute "manually" -- but drag isn't! In fact, in a large and complex network with PDM relationships, even if one knows exactly what to do, it can take a day or two to compute the drag for all the CP activities -- and then when you optimize part of the schedule, they can all change and you have to repeat the process!  In other words, it's exactly the sort of computation that computers were made to do!  But first, they have to compute float correctly, and with MSP, not all do that unless the necessary milestones are included. That's why Sumatra's product (with whom, by the way, and as with Spider Project, I have no financial arrangement) allows the user to automatically input the necessary milestones and "fix" both the reverse CP anomaly and the slack computations.

Good conversation, Miklos, and thank you: I had never heard the term "relaxation as splittable activities" used before. I will use it in my graduate classes in the future.

Fraternally in project management,

Steve the Bajan

Hi Faiz

You may want to look at the PP thread called Ban trhese Planning Abominations to understand my planning philosophy.

Best regards

Mike Testro

Hi Faiz

Every task should have at least one outgoing link - if only to the completion milestone which is alone exempt from the rule.

Best regards

Mike Testro