I'd add just a little clarification, especially for the less-experienced schedulers. Most specifications encourage you not to use constraints at all, but when one is scheduling a project that has a contractual deadline, make sure that that deadline is correctly shown. It is better to put a constraint on milestones in the network as contractually specified, as opposed to putting a deadline in the project detail form, "Must Finish By" date. When you run the critical path report, the milestone will appear on the list. This allows a demonstration to all parties that the contracted milestone (use the contract language to identify it) is a coherent piece of the plan. It also will ensure you, the scheduler, that in the case that a link is lost to the finish milestone, the float won't still be computed to the unseen project "Must Finish By" date. Also, there is a hierarchy of constraints that should be used. From the top to the bottom of this list are constraints with increasingly rigid behaviors:1. Start on or after allows logic to drive dates, but pulls in the forward pass the start to the date. Likewise, a Finish on or before allows logc to drive dates, but ensures that there is a deadline.2. Start on and Finish on also allow logic to drive, but sets in the forward and backward pass the activity to that date, and will stay on that date unless driven by logic.3. Mandatory Start or Mandatory Finish violates logic and keeps the activity so constrained at that date, come what may. The use of these constraints can lead to (on purpose or inadvertantly) deceit of the owner, and self-deception of the scheduler.THOUGH, I have seen a specified scheme from the owner that is a clever way to capture positive longest path float. Have two finish milestones tied to each other FF. The first finish mielstone is the ending milestone for all other activity paths. I call it the "COMPUTED COMPLETION DATE". Its only successor is the last milestone "CONTRACTED COMPLETION DATE" constrained with Mandatory Finish to contract completion, so it stays in place, in time. During computation the total float of the first milestone shows true total float whether positive or negative. Without this scheme, a one milestone critical path (Finish no later than) is shown as 0, whether it is positive or 0.
If you are setting constrains for the activities while updating , it will give negative float if the project is getting delay means . Better we can go on without constraints . From the Project Mangement Side if they had Advised to Set Constraints means you are free to go . Correct me if am wrong .
I'd add just a little
I'd add just a little clarification, especially for the less-experienced schedulers. Most specifications encourage you not to use constraints at all, but when one is scheduling a project that has a contractual deadline, make sure that that deadline is correctly shown. It is better to put a constraint on milestones in the network as contractually specified, as opposed to putting a deadline in the project detail form, "Must Finish By" date. When you run the critical path report, the milestone will appear on the list. This allows a demonstration to all parties that the contracted milestone (use the contract language to identify it) is a coherent piece of the plan. It also will ensure you, the scheduler, that in the case that a link is lost to the finish milestone, the float won't still be computed to the unseen project "Must Finish By" date. Also, there is a hierarchy of constraints that should be used. From the top to the bottom of this list are constraints with increasingly rigid behaviors:1. Start on or after allows logic to drive dates, but pulls in the forward pass the start to the date. Likewise, a Finish on or before allows logc to drive dates, but ensures that there is a deadline.2. Start on and Finish on also allow logic to drive, but sets in the forward and backward pass the activity to that date, and will stay on that date unless driven by logic.3. Mandatory Start or Mandatory Finish violates logic and keeps the activity so constrained at that date, come what may. The use of these constraints can lead to (on purpose or inadvertantly) deceit of the owner, and self-deception of the scheduler.THOUGH, I have seen a specified scheme from the owner that is a clever way to capture positive longest path float. Have two finish milestones tied to each other FF. The first finish mielstone is the ending milestone for all other activity paths. I call it the "COMPUTED COMPLETION DATE". Its only successor is the last milestone "CONTRACTED COMPLETION DATE" constrained with Mandatory Finish to contract completion, so it stays in place, in time. During computation the total float of the first milestone shows true total float whether positive or negative. Without this scheme, a one milestone critical path (Finish no later than) is shown as 0, whether it is positive or 0.
If you are setting constrains
If you are setting constrains for the activities while updating , it will give negative float if the project is getting delay means . Better we can go on without constraints . From the Project Mangement Side if they had Advised to Set Constraints means you are free to go . Correct me if am wrong .
Kind Regards ,
Gautham
There is no contraint on a
There is no contraint on a good network by critical path method.
yep over rides all logic
yep over rides all logic