Critical Activities

True Critical Path shall consider all constraints, constraints shall not be limited to rules of logic or to a single project end date. At times it is more important an intermediate contractual date than the overall finish. Even when both are important one might be more than the other. As a matter of fact in some of our jobs the liquidated damages for some intermediate milestones can be substantially more than that for the overall project finish. Some works that are not so important might be contracted for latter, like for example you cannot star work on certain activities because access will not be available before certain date.

In addition to date constraints material constraints shall be considered on the critical path computation, lack of some material resource will stop the job until the material is available, the same goes for financial constraints, resource availability and others.

Schedule without constraints will not necessarily show true critical path. Date constraints, financial constraints resource and material constraints are real and must be considered.

What the software shall not do is to display values that have no real world meaning. Negative float is an aberrant computation that is not needed to show criticality. Negative float is the result of an impossible, late being earlier than early, as if travel within time can be accomplished. The problem is on using this computation as if equal to true float when it is equals to wrong float.

True float exists, it shall be computed taking into consideration all constraints modeled in a correct mathematical algorithm that do not result in the impossible.

Spider Project computations for true and resource critical float are correct, Spider Project can take into account financial constraints. Spider Project do not pretend to travel in time, always early is earlier than late.

People who use software that wrongly manipulate critical path computations will require some external software or special procedures to un-manipulate the flawed computations.

Good software shall not mix "true float" with "back to the future float".

Because tomorrow cannot be earlier than yesterday true float shall rule out negative values, physical interpretation of time is a real constraint that shall be considered always in the computation of true float, anything else shall be displayed separately and called something like back to the future float or impossible float.

Calling all date constraint artificial is in error, many date constraints are real and therefore not artificial. There are cases when a date constraint is used to force resource leveling mathematics, this is a case of an artificial date constraint, true constraint is resource availability and is mathematically represented on a very different way on CPM models.

I agree that the must finish constraint can easily cause this problem. It's certainly a double-edged sword. The constraint can be helpful to show the float to a contract completion date. On the other hand, if the entire project is running behind schedule, virtually all activities may show as critical, which is not always the intended effect, nor is it leveraging true CPM scheduling.

One thing that I use often is Acumen Fuse's 'Schedule Cleanser' which will model a schedule without constraints (and other constraining elements) to show the true critical path and a "what if" of the project end date. I used this tool on my own for 2.5 years before coming to work at Acumen. If this is a capability you would be interested in, I can certainly provide more information.

Tom Polen

 "must finish by date"  is "the mother of all date constraints", so you have date constraints. Try getting rid of this constraint and see what happens, make the field empty.  Does it makes sense now?

To me calculations that make the impossible possible are nuts, late dates earlier than early dates are nuts, it is not true that in order to show criticality negative float is needed, correct mathematical models can display criticality without such thing as negative float. For decades many forensic analyst have fought against it but unfortunately many that claim knowledge of the model have accepted such manipulation of float under the excuse it is a mathematical computation, yes but a misleading one.

Maybe you got the wrong algorithm on the mother of all constraints.

Another one to check/un-check is the option to make open ends critical.

OOPS, the mother of all constraints and hidden if P6 behaves like this, it should be obvious, perhaps shown with some type of marker like some other software do.

What a mess if you rely at some point on a date constraint applied to the last activity different to this the mother of all date constraints. Double jeopardy.

Make sure you know the basics on how to get the correct values for float, some software are notoriously unreliable.

Try the sample schedule on the following link to make sure you can use your software to get correct values of float.

http://www.planningplanet.com/forums/primavera-version-pm5-pm6/533853/bars-red-color-critical-activities-or-float-0

I am assuming you are using P6? If so check the 'Must Finish By Date' in the 'Projects' Window under 'Dates' tab. If this has been set too early then the whole schedule can become critical.

RE: Is there something wrong with the links?

They might be out of sequence even if the original logic makes sense. Out of sequence happens because there are links, without links there is no such thing as out-of-sequence. Out-of-sequence means it did not happened as planned, some say the schedule was wrong I say make as much out-of-sequence to occur it it means getting ahead of original plans. No plan is perfect and no matter how good there is always room for improvement, then why not encourage improvement by those at the site who know best?

I suggest starting by filtering for out of sequence events, ie SS/SF/FS/FF links, you want to know which specific link created the issue. 

Even a milestone activity, yes a zero duration activity, that was not updated to show actual progress can create issues with out of sequence.

• Milestone activities do not always auto-update, they will if you updated them using "as planned" a big problem if you update some activities as planned and other with manual adjustments. In such case it might be that for the manually adjusted successors you assigned a date prior to the milestone date assigned as planned.
• If your software is incapable of filtering for all out-of-sequence activities including prior updates occurrences at a single click of the mouse then you shall go back to prior update files. Some software post the report to a log file while it might be you will have to perform again a schedule run to get the report for every update.

Always compare progress override with retained logic output, this can give you some clues. I do favor always fixing the schedule on every update as to eliminate out-of-sequence events but some say it it not always necessary. They say at times is a waste of time I say it is laziness. Making the correction on time can prevent that latter corrections on a claim be declared self serving.

Believe it or not some owners pretend you to create the perfect schedule, to know the future, and protest if you change plans. But by their actions they prevent you from owning the means and methods, they hijack your control of the job. The contractor has the right to keep controls of the means and methods, he has an obligation to keep the owner informed.

Make sure your updating procedures are not preventing you to see what is really happening.

Finish no latter than constraints can be another issue but in order to make all activities critical all activities must be connected to the activity with such date constraint. Look for them as they might be causing some paths to become critical. 

Good luck.