Agreed wrt the project start milestone. I see no reason to apply an explicit constraint to it, for the reasons you mention. Implicitly, that's why my previous comments were confined to completion milestones.
Member for
16 years 3 months
Member for16 years3 months
Submitted by Zoltan Palffy on Mon, 2020-09-21 15:44
The first activity can be Start on to After and only affects the early start dates.
The last activity should be finish on or before. This will be where the backward pass begins.
The finish on constraint can delay an early finish or accelerate a late finish to satisfy the imposed date.
But the finish on or before imposed on an activity that limits the latest time it can be finished or the late finish date. The finish on or before constraint affects only the late dates. Use this constraint to ensure that the late finish date of an activity is no later than the date imposed.
Member for
22 years 9 months
Member for22 years9 months
Submitted by Alexandre Faul… on Sat, 2020-09-19 15:43
isn't that strange to assign a Start On constraint to the first activity of the project? the project start date in the project form isn't enough?
when the Start ON date is later than the Project Start date (it cannot be earlier in P3/P6), I presume that the software will calculate the project duration from the Project start date, not the constraint; and where is the truth?
I always instruct my trainees NOT to assign a Start On (or Start On or Later) constraint on the project start milestone, BUT to use the Project Start date.
Great! Obviously, if your project goes into negative-float territory, then both milestones will merge and be pushed late. The Contract Completion milestone would no longer be correct, as it no longer sits on the contract date.
"Hard constraint" means different things to different people and is not generally defined; I'd suggest you avoid using the term. In P6, a Finish On constraint essentially combines an early constraint on the forward pass with a late constraint on the backward pass. The resulting scheduled (early) dates don't violate the logic constraints of the schedule, so it's not nearly as objectionable as a Mandatory Finish constraint.
For a completion milestone, the primary difference between a Finish-On and a Finish-On-or-Before constraint is that the former prevents the milestone from depicting an early completion - the milestone just sits on its contract (constraint) date with zero total float. That's the situation that many project managers want to present, even though it's incorrect - there's certainly a chance for the project to finish before or after its constraint date depending on the progress of the work. Changing the constraint from FO to FOB may correct the float for intermediate milestones, but not for a milestone at the end of the project. (That's what the Project must finish by constraint is used for, but I prefer to avoid it.) I sometimes split the milestone into two: Forecast Completion and Contract Completion, with an FF tie between them and an FO constraint on the latter. Even with its issues, that can be easier than making a special bar to display a contract-date UDF.
For a final completion milestone, the preferred approach typically depends on the agreed treatment and allocation of project float (or terminal float) - the interval between the forecast early completion date and the contract completion date. That's much more a contract issue than a scheduling issue. Good luck, tom
Member for
18 years 11 monthsAlexandre,Agreed wrt the
Alexandre,
Agreed wrt the project start milestone. I see no reason to apply an explicit constraint to it, for the reasons you mention. Implicitly, that's why my previous comments were confined to completion milestones.
Member for
16 years 3 monthsThe first activity can be
The first activity can be Start on to After and only affects the early start dates.
The last activity should be finish on or before. This will be where the backward pass begins.
The finish on constraint can delay an early finish or accelerate a late finish to satisfy the imposed date.
But the finish on or before imposed on an activity that limits the latest time it can be finished or the late finish date. The finish on or before constraint affects only the late dates. Use this constraint to ensure that the late finish date of an activity is no later than the date imposed.
Member for
22 years 9 monthsHi Heather and Tom,isn't that
Hi Heather and Tom,
isn't that strange to assign a Start On constraint to the first activity of the project? the project start date in the project form isn't enough?
when the Start ON date is later than the Project Start date (it cannot be earlier in P3/P6), I presume that the software will calculate the project duration from the Project start date, not the constraint; and where is the truth?
I always instruct my trainees NOT to assign a Start On (or Start On or Later) constraint on the project start milestone, BUT to use the Project Start date.
Alexandre
Member for
18 years 11 monthsGreat! Obviously, if your
Great! Obviously, if your project goes into negative-float territory, then both milestones will merge and be pushed late. The Contract Completion milestone would no longer be correct, as it no longer sits on the contract date.
Member for
6 years 9 monthsThanks for the detailed
Thanks for the detailed response Tom. I love the idea of the Forecast Complete and Contract Completion. I'll be using that tip - best of both worlds!
Again, thanks!
Member for
18 years 11 monthsHeather,"Hard constraint"
Heather,
"Hard constraint" means different things to different people and is not generally defined; I'd suggest you avoid using the term. In P6, a Finish On constraint essentially combines an early constraint on the forward pass with a late constraint on the backward pass. The resulting scheduled (early) dates don't violate the logic constraints of the schedule, so it's not nearly as objectionable as a Mandatory Finish constraint.
For a completion milestone, the primary difference between a Finish-On and a Finish-On-or-Before constraint is that the former prevents the milestone from depicting an early completion - the milestone just sits on its contract (constraint) date with zero total float. That's the situation that many project managers want to present, even though it's incorrect - there's certainly a chance for the project to finish before or after its constraint date depending on the progress of the work. Changing the constraint from FO to FOB may correct the float for intermediate milestones, but not for a milestone at the end of the project. (That's what the Project must finish by constraint is used for, but I prefer to avoid it.) I sometimes split the milestone into two: Forecast Completion and Contract Completion, with an FF tie between them and an FO constraint on the latter. Even with its issues, that can be easier than making a special bar to display a contract-date UDF.
For a final completion milestone, the preferred approach typically depends on the agreed treatment and allocation of project float (or terminal float) - the interval between the forecast early completion date and the contract completion date. That's much more a contract issue than a scheduling issue. Good luck, tom