Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Finish on vs Finish on or Before as constraint for critical path

6 replies [Last post]
Heather Hadley
User offline. Last seen 1 year 32 weeks ago. Offline
Joined: 29 Jan 2019
Posts: 27
Groups: None

Hello Gurus!

 

I have always been taught (maybe incorrectly) and used hard constraints - Start On / Finish On - for the first and last activity in my P6 schedule.  I have completely stayed away from soft constraints because I'm not familiar with them and I've always kept my schedules clean where I have not had a reason to add a soft constraint.  I'm currently working with a group on best practices and I've been challenged with using a Finish On or Before rather than a Finish On for portfolio type schedules that have individual projects within the portfolio.  We need to establish critical paths within that portfolio.

 

I've been doing some research and it looks as if Finish On or Before will create what I need although I still think the Finish on will as well.  I'm just wondering what everyone else's best practices are.

 

Thanks!

Heather

Replies

Tom Boyle
User offline. Last seen 9 hours 29 min ago. Offline
Joined: 28 Nov 2006
Posts: 304
Groups: None

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.

Zoltan Palffy
User offline. Last seen 6 weeks 6 days ago. Offline
Joined: 13 Jul 2009
Posts: 3089
Groups: None

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.

 

 

Tom Boyle
User offline. Last seen 9 hours 29 min ago. Offline
Joined: 28 Nov 2006
Posts: 304
Groups: None

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. 

Heather Hadley
User offline. Last seen 1 year 32 weeks ago. Offline
Joined: 29 Jan 2019
Posts: 27
Groups: None

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!

Tom Boyle
User offline. Last seen 9 hours 29 min ago. Offline
Joined: 28 Nov 2006
Posts: 304
Groups: None

 

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