You are of course correct - I will in future modify such statements to allow for stated contractual commencement dates for sections of the works where a start on or later constraint is the most efficient way of acheiving the requirement.
Best regards
Mike Testro
Member for
20 years 10 months
Member for20 years10 months
Submitted by Andrew Flowerdew on Mon, 2011-12-19 17:41
I agree with others that the use of constraints should be avoided if at all possible and as Mike said, the Employer can not insist that you put one on a contractor activity BUT if for example, the contract states you won’t get access to part of the site, (even if you’re ready to move into that part of the site before that date), until a certain date then I believe using a constraint is valid.
That said, I note you have called it a mandatory constraint – do you mean by this that the date is set at a certain date and can not be changed or can a “can not start before a certain date” type constraint be used. This type of constraint would probably be more appropriate as it would allow the milestone date to be delayed when rescheduling but never be shown earlier than the stated date. Exactly how constraints react will depend on the software settings.
In the above example having no constraint at all, (or some other way of making sure access isn’t shown until a certain date), could result in a programme that shows you getting access before the allowed date. If on the critical path it could then also possibly show a corresponding early completion – both would be completely wrong!
I pulled out an old updated schedule for a small project (long finished) with a mandatory constraint for the start of a shut down and as im running through Keith Pickavances book that question kind of came up.
In line with what you said Mike, if you release it and re-schedule, the end date slips by 11 days but the previously constrained Shutdown slips 46 days? No delays added or dates changed.
Does this mean it is a markedly forced program?
Best wishes for the festive season.
Aidan
Member for
16 years 7 months
Member for16 years7 months
Submitted by Gary Whitehead on Sun, 2011-12-18 14:56
Mandatory constraints on interim milestones have 3 major effects on your schedule:
1) Regardless of wether the driving logic says the milestone should happen earleir or later than the mandatory date, the milestone wil allways show that date, and all of it's successors will be forecast based on this mandatory milestone date. So if the milestone is on the critical path, it will make absoultely no difference to the project finish no matter how quickly or slowly you permorm any activities upstream of the milestone, or how much client delays any of these activities.
2) The float of all activities upstream of the constrained milestone will relate to the mandatory date of the interim milestone, and not the end of the project. This means you no longer have a single critical path through the project: you have a critical path from start to the interim milestone, and you have a second from either start or interim milestone through to project finish.
3) Any of the upstream activities can experience negative float, making even more of a mockery of your critical path.
Botom line is that the float of activities upstream will be screwed, whereas for the activities downstream it will be their early dates.
As Mike says, the constraint would have to be removed before any meaningful delay analysis could be performed (wether this was to the benefit of the client or contractor).
I would also make sure the client was aware that you would only be using the constrain for client reports, and it would not be present in the internal schedule you would be using for runnnig the job.
For a start a client can only insist on a mandatory constraint for hiis own input - such as free issue material.
He cannot insist on it for your own scope of works - so don't add any.
For his own tasks keep them in until they are causing a problem with the free flow of your own logic - then take them out and report the results.
My Philosophy is that there should be no constraints at all in a construction programme - the software suppliers are to blame for including them in the system - if they weren't there the planner would have to do the job properly..
Before I start any delay analysis I clear the baseline programme of constraints and reschedule - the result is often quite illuminating.
Member for
19 years 10 monthsHi Andrew You are of course
Hi Andrew
You are of course correct - I will in future modify such statements to allow for stated contractual commencement dates for sections of the works where a start on or later constraint is the most efficient way of acheiving the requirement.
Best regards
Mike Testro
Member for
20 years 10 monthsI agree with others that the
I agree with others that the use of constraints should be avoided if at all possible and as Mike said, the Employer can not insist that you put one on a contractor activity BUT if for example, the contract states you won’t get access to part of the site, (even if you’re ready to move into that part of the site before that date), until a certain date then I believe using a constraint is valid.
That said, I note you have called it a mandatory constraint – do you mean by this that the date is set at a certain date and can not be changed or can a “can not start before a certain date” type constraint be used. This type of constraint would probably be more appropriate as it would allow the milestone date to be delayed when rescheduling but never be shown earlier than the stated date. Exactly how constraints react will depend on the software settings.
In the above example having no constraint at all, (or some other way of making sure access isn’t shown until a certain date), could result in a programme that shows you getting access before the allowed date. If on the critical path it could then also possibly show a corresponding early completion – both would be completely wrong!
Member for
19 years 10 monthsHi Aidan That is correct -
Hi Aidan
That is correct - constrainst distort the logic and are often used to rig a programme - particularly if there is only a print version to review.
In some software the presence of constraints can be hidden from view.
Best regards
Mike Testro
Member for
14 years 6 monthsThanks Gary/Mike.I pulled
Thanks Gary/Mike.
I pulled out an old updated schedule for a small project (long finished) with a mandatory constraint for the start of a shut down and as im running through Keith Pickavances book that question kind of came up.
In line with what you said Mike, if you release it and re-schedule, the end date slips by 11 days but the previously constrained Shutdown slips 46 days? No delays added or dates changed.
Does this mean it is a markedly forced program?
Best wishes for the festive season.
Aidan
Member for
16 years 7 monthsAiden, Mandatory
Aiden,
Mandatory constraints on interim milestones have 3 major effects on your schedule:
1) Regardless of wether the driving logic says the milestone should happen earleir or later than the mandatory date, the milestone wil allways show that date, and all of it's successors will be forecast based on this mandatory milestone date. So if the milestone is on the critical path, it will make absoultely no difference to the project finish no matter how quickly or slowly you permorm any activities upstream of the milestone, or how much client delays any of these activities.
2) The float of all activities upstream of the constrained milestone will relate to the mandatory date of the interim milestone, and not the end of the project. This means you no longer have a single critical path through the project: you have a critical path from start to the interim milestone, and you have a second from either start or interim milestone through to project finish.
3) Any of the upstream activities can experience negative float, making even more of a mockery of your critical path.
Botom line is that the float of activities upstream will be screwed, whereas for the activities downstream it will be their early dates.
As Mike says, the constraint would have to be removed before any meaningful delay analysis could be performed (wether this was to the benefit of the client or contractor).
I would also make sure the client was aware that you would only be using the constrain for client reports, and it would not be present in the internal schedule you would be using for runnnig the job.
Member for
19 years 10 monthsHi Aidan For a start a client
Hi Aidan
For a start a client can only insist on a mandatory constraint for hiis own input - such as free issue material.
He cannot insist on it for your own scope of works - so don't add any.
For his own tasks keep them in until they are causing a problem with the free flow of your own logic - then take them out and report the results.
My Philosophy is that there should be no constraints at all in a construction programme - the software suppliers are to blame for including them in the system - if they weren't there the planner would have to do the job properly..
Before I start any delay analysis I clear the baseline programme of constraints and reschedule - the result is often quite illuminating.
Best regards
Mike Testro