Sun, 2013-03-24 00:49 (Steve):
Hi, Rafael.
First, I was trying to avoid getting back into our debate about the software’s assumption of continuous or non-continuous activities. We agree on almost everything, including all that you have said about making management decisions about where to split the activity. We seem to agree that:
- An activity can almost always be split if it is valuable to do so.
- Where we split an activity should always be a management decision.
- The software should point the user to where the constraints are that might result in a reverse CP anomaly.
All that is agreed. The only place we disagree is:
What should be the default that the SOFTWARE, not the user/scheduler, applies in creating the schedule. Again it’s NOT a disagreement about what the user should do, only about what the algorithm, which has been programmed “generically” by someone who has not a clue about the specifics of the project, should do.
- You are used to the continuous activity assumption that is programmed into CPM algorithms so that you seem not to see the continuous activty default as an optional assumption. The software HAS to make an assumption and it chooses to make the assumption that the activity is continuous, which often makes the project longer in a way that is not clearly visible to most users. We seem to completely agree that this should be made more visible, and I am quite comfortable with using the continuous assumption provided that this is made highly visible and the software identifies the drag with the delaying constraint/assumption.
The other possible default that the software could use is to generate the shortest possible schedule (which most users actually think that the software is doing!). This is certainly a legitimate alternative, and is both practical and better (i.e., shorter schedule) in the vast majority of instances. But once again, the software must show the user what it is doing by:Â
- Emphasizing the early start date of the SF/FF successor as being the prime driver;
- Stating that it is splitting out a milestone as the activity’s SF/FF finish; and
- Telling the user the amount of time being saved on the project duration through the input of the milestone.Â
By the way, the Sumatra.com Project Optimizer add-on to MS Project that computes drag does all of this and, additionally, does it ONLY if the user specifically elects to implement “optimization” of the schedule by splitting out milestones on activities with SF/FF predecessors. Once the user does this, they can see the impact and then go in and change where the activity is split, if they so choose.
Again, we are in complete agreement about what the user/manager should do, and about the fact that the software should act in a transparent and helpful manner. Our disagreement is just about the CPM algorithm’s default, which I believe should be to emphasize producing the shortest possible schedule, not assuming a longer schedule in a not-very-transparent way due to making an assumption (i.e., that the activity MUST be continuous) that is almost never valid.
Fraternally in project management,
Steve the BajanÂ