| Adding Constrained Milestones |
| |
|
Ron Winter
|
| |
|
March 20, 2002
|
| |
|
I was once asked if it was OK for a Contractor to add constrained milestones to his schedule updates to indicate upcoming events or needs. This is my reply to that question.
|
| |
|
I have a general 'rule of thumb' that says that anything that enhances or adds to the communication between Contractor and Owner is 'good.' Your Milestones fall into this category. It is good for all parties to understand external constraints and conditions that might affect the project. As long as no additional logic is added, and the wording of the milestone descriptions is neutral, then nothing can be hurt.
|
| |
|
I also have another 'rule of thumb,' that is that you should only use the 'lightest' possible constraint whenever you put one in. By this I mean that you should give preference to using Start-No-Earlier-Than, Start-No-Later-Than, Finish-No-Earlier-Than, or Finish-No-Later-Than constraints over Start-On and Mandatory-Start constraints. I also encourage using Start-On constraints over the use of Mandatory-Start constraints for the same reason.
|
| |
|
Why only use the minimum constraint possible? You should say what you really mean. Is it true that you milestone MUST start on that date? What if the rest of the project is delayed or advanced? Will that milestone occur on that date regardless? If so, then use Mandatory-Start. That constraint overrides any logic regardless of circumstances. At least Start-On constraints can be delayed if the logic requires it. Better still to use Start-No-Earlier-Than constraints. This allows the late float calculations to 'flow' through the milestone, allowing the succeeding activities to show project float.
|
| |
|
Constrained Milestones with logic can be dangerous for claims issues. In the Baseline Schedule, I typically do not allow any constrained milestones that do not DIRECTLY relate to a specification requirement. On subsequent updates, I allow the constraint but advise the Contractor in writing that I reserve the right to remove any such constraint for the purposes of delay analysis. Otherwise, such milestones constitute "reserving the float." Most specifications forbid this action. If not specified, then the Contractor has the right to reserve the float (but I still insist on removing the constraint for delay analysis.)
|
| |
|
I once represented an Owner on a project where the Foreman was playing 'Scheduler.' He put in such a constrained milestone for his own scheduling purposes and months later, this caused a few activities after this constrained milestone to go to zero float. Understand, this was not the "Project Critical Path," only a few artificially constrained activities. We then had an "Owner's Delay" to one of those activities and the Contractor claimed for time extension and extended overhead. It took weeks of my time explaining over and over again how this delay did not delay the completion of the project and thus could not be compensible or excusable. [True Story]
|
| |
