In general, as a planning engineer one must review the performance of the project and see internally if any activity in the project schedule is creating negative float. This is to generate an alarm for the down the line construction team to convey an urgency or expediting the work progress. This is to be used as a project management technique in construction management.
But when the schedule is submitted to the client,as a monthly update, the constraint applied to the end date must be taken out and schedule should be allowed to run on the basis of a free flow logic.
Now taking the discussion further and to share my views with you, I would say that, the imposition of constraint in a schedule to be kept as minimum as possible (by saying so I do not specify a number) but the usage of constraints should be as minimum as possible otherwise it will be something like the absuses of scheduling techniques even though software does not limit us on the number of usage. As a matter of good practice, this should be in vogue.
Anyway.
Thanks.
PK.
Muscat
Member for
22 years 9 months
Member for22 years9 months
Submitted by Alexandre Faul… on Tue, 2007-10-09 15:16
Youre right, a "Must Finish constraint is purely for Crashing purpose", and "the slippage duration must be recovered from the activities in Longest/ Critical Path to bring back the schedule to the Baseline Finish date".
When the project in on the tracks, a good policy to represent the contractual end date is to add a finish milestone with a lioming from the project start milestone and a lag equal to the contractual project duration.
Alexandre
Member for
21 years 6 months
Member for21 years6 months
Submitted by Pradeep Kumar … on Tue, 2007-10-09 07:34
I believe imposing a Constraint date on the Finish Milestone is not a good practice, as you all know that, this would generate negative float.
However the schedule end date should be a free floating type which would be driven by the logic built into it and depending the progress % of its predecessors.
However if the imposition of the Must Finish constraint is purely for Crashing purpose or for a producing recovery plan , then the slippage duration must be recovered from the activities in Longest/ Critical Path to bring back the schedule to the Baseline Finish date.
Cheers.
Keep Planning.
PK.
Member for
22 years 9 months
Member for22 years9 months
Submitted by Alexandre Faul… on Mon, 2007-10-08 17:11
I should have made a mistake and got confused between Expected Finish and Finish On or Before; I have done the same exercise today, and everything is correct: Finish On or Before sooner than Scheduled Finish calculates a negative float, and Expected Finish calculates a shorter task
Thanks for your answers
Alexandre
Member for
18 years 5 months
Member for18 years5 months
Submitted by Patricia Le Clainche on Mon, 2007-10-08 16:55
Could you please tell us more about options you have. As far as I am concerned, I put a Primary Constraint "Finish On or Before" on all my Finish Milestones. And each time the predecessor(s) is(are) delayed, I get the "desired" negative float.
In some specific cases, I have some milestones without any predecessor and I use both Primary & Secondary constraints : the first one with "Finish On or after" and the second one with "Finish On or Before". Therefore, if the milestone is delayed, I can show a negative float , by changing the Primary contraint date.
I tested your constrained situation,applying constrain on finish milestone, on my PC and Primavera gave a negative float as usual.
You said in your system ,it shorten duration. Could you tell us which activity in project does Primavera shorten duration? Is it the next to the last one?
Have you upgrade Primavera to the lastest SP : SP4?
Thanks
Member for
19 years
Member for19 years
Submitted by Rodel Marasigan on Sun, 2007-10-07 20:30
You can use Must Finish By as a constrain under Enterprise-> Project then select the project that you wanted to constrain and click the Date tab. Enter an earlier date on “Must Finish By” text box and P5 will show it as negative float.
Member for
21 years 6 monthsRE: Finish On or Before
Hi Alex,
Thanks for the notes.
In general, as a planning engineer one must review the performance of the project and see internally if any activity in the project schedule is creating negative float. This is to generate an alarm for the down the line construction team to convey an urgency or expediting the work progress. This is to be used as a project management technique in construction management.
But when the schedule is submitted to the client,as a monthly update, the constraint applied to the end date must be taken out and schedule should be allowed to run on the basis of a free flow logic.
Now taking the discussion further and to share my views with you, I would say that, the imposition of constraint in a schedule to be kept as minimum as possible (by saying so I do not specify a number) but the usage of constraints should be as minimum as possible otherwise it will be something like the absuses of scheduling techniques even though software does not limit us on the number of usage. As a matter of good practice, this should be in vogue.
Anyway.
Thanks.
PK.
Muscat
Member for
22 years 9 monthsRE: Finish On or Before
Pradeep,
Youre right, a "Must Finish constraint is purely for Crashing purpose", and "the slippage duration must be recovered from the activities in Longest/ Critical Path to bring back the schedule to the Baseline Finish date".
When the project in on the tracks, a good policy to represent the contractual end date is to add a finish milestone with a lioming from the project start milestone and a lag equal to the contractual project duration.
Alexandre
Member for
21 years 6 monthsRE: Finish On or Before
Hi All,
I believe imposing a Constraint date on the Finish Milestone is not a good practice, as you all know that, this would generate negative float.
However the schedule end date should be a free floating type which would be driven by the logic built into it and depending the progress % of its predecessors.
However if the imposition of the Must Finish constraint is purely for Crashing purpose or for a producing recovery plan , then the slippage duration must be recovered from the activities in Longest/ Critical Path to bring back the schedule to the Baseline Finish date.
Cheers.
Keep Planning.
PK.
Member for
22 years 9 monthsRE: Finish On or Before
Hello all,
I am using Primavera 5.0 Build ID#:00000330.
I should have made a mistake and got confused between Expected Finish and Finish On or Before; I have done the same exercise today, and everything is correct: Finish On or Before sooner than Scheduled Finish calculates a negative float, and Expected Finish calculates a shorter task
Thanks for your answers
Alexandre
Member for
18 years 5 monthsRE: Finish On or Before
Bonjour Alexandre,
Could you please tell us more about options you have. As far as I am concerned, I put a Primary Constraint "Finish On or Before" on all my Finish Milestones. And each time the predecessor(s) is(are) delayed, I get the "desired" negative float.
In some specific cases, I have some milestones without any predecessor and I use both Primary & Secondary constraints : the first one with "Finish On or after" and the second one with "Finish On or Before". Therefore, if the milestone is delayed, I can show a negative float , by changing the Primary contraint date.
I hope it helps.
Cordialement.
Patricia
Member for
18 years 1 monthRE: Finish On or Before
Hi Alex.
I tested your constrained situation,applying constrain on finish milestone, on my PC and Primavera gave a negative float as usual.
You said in your system ,it shorten duration. Could you tell us which activity in project does Primavera shorten duration? Is it the next to the last one?
Have you upgrade Primavera to the lastest SP : SP4?
Thanks
Member for
19 yearsRE: Finish On or Before
Alexandre,
You can use Must Finish By as a constrain under Enterprise-> Project then select the project that you wanted to constrain and click the Date tab. Enter an earlier date on “Must Finish By” text box and P5 will show it as negative float.
Regards,
Rodel