Scheduling With Constraints

Deleted by Rafael Davila as to avoid annoying requests to revive this discussion as it is older tha 3 years.

Hi Idris,

Using 'Finish on or before' constraint does make sense sometime. For example, our supplier need to provide us 10 equipment deliveries @ 1 delivery/month. These delivery activities in supplier schedule can't be tied with each other as they are individual tasks and don't depend on each other. But this creates 10 finish points in the supplier schedule. Linking these 10 deliveries with one 'Project Finish' milestone will create 9 months float on 1st delivery, 8 months float on 2nd delivery and so on. These float values don't show correct picture as on time delivery is very important for us and we don't have any float in our master schedule. Applying Finish on or before constraint on these activities help to control unnecessary float values in the supplier schedule. I see same philosophy in your case and these constraints might have been applied to control unnecessar floats.

Syed

The milestone for the buildings are ok to use finish on or before 

The Landscaping has a finish on or after which is only one day sooner than the project finish date so this would not be a good idea to use this here. If you are consirned about the weather time frame of installation of the landscaping during no plating temperatures you can create another calendar for this weather sensitivie work and assign the landscaping activities to this calendar or you can use a start on or after constraint but it can not be 1 day prior to project completion.

The 5 item Project Finish should have a Finish ON or before milestone not a finish on.

Hi, Idris.

By "straitjacketing", I mean that the activities in the schedule can no longer move around freely as they should when driven by events and network logic. In addition, drag will often move from activities to the constraint, and float calculation will be distorted, which in turn can distort drag calcualtion.

In general, it seems to me that you should be guided by Mike's advice. (Always a good idea IMO, unless he's expressing an opinion about cricket.)

However, the client is always correct -- if the client insists on having you input these arbitrary constraints, I would do it for client reporting. However, i would manage my schedule (i.e., perform critical path analysis) elsewhere, on the working schedule where I would not include such constraints.

Fraternally in project management,

Steve the Bajan

Hi Idris

My advice is never ever use Must start - Must finish constraints unless it is on the first task in the schedule.

Every milestone has to be fixed in place by correct logic.

For instance if there is a milestone for Employer Input (Design - Materials - Approval) etc then it can be located in live time by using an ALAP constraint on the task and a FS successor link.

That way the schedule logic remains dynamic with no "straightjackets" imposed.

Whenever I am presented with a baseline programme for delay analysis the first thing I do is take off all the constraints and reschedule to see where the true criticality lies.

This often reveals a flawed or rigged programme.

Best regards

Mike Testro

I edited the post, try the suggested way to get the link working and let me know.

Best Regards,

Rafael

Hi, Idris. I, like you, look forward to the comments from the experts. But I will mention a couple of things I teach my classes:

Calendar-based constraints have the effect of overriding the logic. This usually has the effect of "straitjacketing" schedule analysis. I recommend:

1. Doing all schedule optimization BEFORE placing constraints (the optimization may often moot the impact of a constraint by pulling the constrained event earlier than the constraint) and placing the constraints one at a time as the last step in scheduling. Then, as you input each constraint, look to see its impact on the schedule (particularly project completion delay -- that is the constraint's critical path drag.) How much is that impact costing (drag cost)? Can you/your customer live with that? is there some way you could reduce it?
2. Whenever doing critical path analysis during execution, first filter out the (straitjacketing) calendar constraints. Then do the analysis and determine any changes you want to make. Finally, as with initial planning, place the constraints back one at a time and again measure each one's critical path drag and drag cost.

Just to be clear, No Later Than constraints will not have drag, but can cause negative float, which must be resolved. No Earlier Than and ON constraints  can often have drag.

Hope that helps, and I eagerly await the experts' comments re practical application and perhaps legal (forensic?) issues.

Fraternally in project management,

Steve the Bajan