(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.
We have a Task called ROS (Required on site date)
Normally we apply a as late as possible constriant on this task,
The Task Predacessor is delivery to site
Task Successor is Construction with a Lag (The Theory being that we want everything on ste 2 to 6 weeks prior to use)
I have been advised that a ALAP constriant is not acceptable in a Court case so I am not allowed to use it.
Is this TRUE ?
Printer-friendly version
Send to friend
Hi Mark.
ALAP does not remove the float - it just places it before the start rather than at the end of it.
Best regards
Mike Testro
Go ahead and use As Late As Possible, it just removes all the float. It would be a good idea to keep the duration long enough just in case something goes wrong. Have you tried Longest Path Approximator? http://scheduling.spacetechnology.net It is capable of moving the data date back to the beginning of the month, and then you can see the critical path. Hint: Ask for a free sample!
Jay,
I respect your opinion. But beleive me there are some cases where two schedules are unevitable. Here is an example from my experience.
Here in Hungary we have a huge construction firms, They established a project based system for the whole company, all the projects, with BOQ, schedules, resources, contracts, document have to put into the system in a unified way. Similar activities has to have the same ID-s, even if they are in different projects (just to have the options to compare them). % complete data, all the costs has to be up to date at the end of every 10days etc.
The management has project level reports three times a month, concerning actual accomplishments, deviations from the approved plans, actual costs etc. And they also have company level reports three times in a month. If they fel a problem, they can dig into details, and find out what can be the cause behind the problems. If discrepency betwen the fact and the approvd plan is above of an accaptable level, new plans has to be made for the rest of the project, and from this point this plan will be followed, and used for forecasting.
This system requires, a rigid regulation, and everybody have to follow it.
There is no chance to satisfy the requests of the client from this system. I've tried couple of times... Client sometimes has a similar system with own regualtions, so even the WBS on the second level was completely different, different codes should have been used etc. Not to mention the different informatic background
Summarizing the above mentioned... Schedules have to satisfy different requirements. If client requiements difer from the requirements of my management ( in terms of the used softare, applied codes, details, where to put emphasi, etc.) than only two schdule can be the solution. Basically I agree with you, but sometimes there are no other solution. I've tried to avoid it every time, because no one would like todouble his work - but again, sometimes you cannot do that.
Miklós
Again My Opionion
1) Can't use two schedules as anything on paper can be used in a court. WOW the "lawayers" can analyse your internal schedule. Strange how they find out about these things
2) Cant use another system as all needs to be auditible WOW if you have a date in your procurement schedule reflecting ROS this should be in line with your as this is what is auditable.
3) Mike thanks for the tip about lag vs task.
Guys
Maybe I'm off topic, but let me share my experience why to have two separate plans even if two schedule have to be updated, and I AM AT THE CONTRACTOR's SIDE
If there is a prepared guy at the opposite side, may be I cannot do that, and if both parties are prepared it would lead to one final common schedule. But I very rarely have this situation.
Miklós.
ps. Anyway ALAP is a good solution for me. I do the same thing.
Hi Jay
It is good planning practice for your ROS task to be set at ALAP linked to the start of construction.
I can think of no reason why this should not be allowed in any tribunal related to delay analysis.
I would advise however that you change the 2 to 6 week lead lag into a task called something like "Stock Control" or "Delivery Delay Risk" and give it the appropriate duration.
When you are linking the ROS task to a work package that has a number of tasks - any one of which could be the first to start as the construction process gets underway - then you have a problem selecting which package task to link it to.
I get round this in PowerProject by creating a hammock of all the package tasks and linking the ROS to the start of the Hammock - ALAP every time.
Best regards
Mike Testro
Gary,
Of course how much float you want to protect is up to you, anyway some will still be taken away for free. As the contractor it shall be your choice.
But keep in mind using a most probable version and an optimistic version is a well known approach science the days of PERT and then Monte Carlo. Keep also in mind buffers such as rain days and the like artificially delay the job on the short run while on the long run the optimistic will move toward the most probable.
I believe the scientific way is through the use of probabilities but the truth is this is confusing for the average user, therefore I prefer using the optimistic for management on the short run and the most probable as a prediction for the long run and leave probabilities to higher management, when required.
We have no problem with our schedules as we name them differently, we are clear of the difference, the optimistic is our target in the hope to meet the most probable, we all know eventually unforeseen will happen and we better be "ahead" for some time. Another way to avoid confusion is that our optimistic schedules are only released in look ahead versions.
As a matter of fact being "ahead" is by itself a motivational issue we strive to reach and keep, we do not delay the schedule when ahead, we make it even shorter. We do not stop batting because we are ahead on the game by many runs.
Perhaps in the UK the need to lie is not as much of a need as in the USA because your protocols differ substantially as to the acceptance that the use of float is at some cost. My warning goes especially to those working under American contracts, especially if on a US jurisdiction.
Jay,
At times it is better to manage some procurement functions on a separate document/software you can update by linking to the schedule database or by importing/exporting actualization, no doubt these are linked. Using the CPM as a Jack of all Trades is not necessarily the best way, let each system complement each other.
Regards,
Rafael
Hi Rafael,
We are in danger of taking the thread off topic, so I will be brief.
You make some very valid arguments as to why seperate programmes should be used in order to protect the contractor's float.
But there are some very valid arguments against using seperate programmes, which in my opinion outweigh them.
These include:
-Not having to update 2 programmes
-Not having 2 versions of the truth which could get confused
-Not having to lie to the client
-Not risking delay to the project because the client believes one of his deliverables is required much later than the project team actually need it
-Being able to pass a client audit on planning procedures
My view is the above list puts you more at risk of finding yourself in a dificult claim situation by running two programmes than not.
This is obviously a very general statement, and the balance may shift depending on your relationship with the client, legal jurisdiction and contract clauses you've signed up to.
But as a general rule, I struggle to justify labelling lying to the client for contractual advantage as best practise.
Cheers,
G
I do not agree.
Perhaps bad practice to the eye of the owner who pretend to take ownership of all float.
I still encourage the use of 2 schedules, one that is the "Most Probable" version, one that will better predict long rung outcome. For the actual administration many suggest using an "Optimistic" version, a version that will not include buffers that might not happen, a version to target in the hope of meeting "Most Probable".
For example the most probable will include allowance for rain days, it will predict some activities to occur latter and you will plan accordingly. But what if it does not rains, you might find out not able to start an activity not because of rain but because other requirements were delayed, such as the delivery of materials or specialized equipment.
Do not be naive, most forensic protocols give float for free as it does not matter, and some has said float belongs to the Contractor until the day he submits the baseline, make sure you keep some float for yourself by means of extending duration of activities with float in a way it still makes sense such as the reduction of crew size or assignment of lower productivity equipment. Then in your "Optimistic" version you assign larger crews and higher productivity equipment.
It is a lie consumption of float does not matter, don't be a fool, don't let anyone steals from you all float, at least be half fool and keep some for yourself. I have seen such a recommendation in many websites by lawyers who practice on the side of the Contractor and would not be surprised of listening the contrary by law firms that represents the owner's side.
From http://www.awci.org/cd/pdfs/8401_d.pdf
As with many construction issues, the ownership of the float is a matter which can be clearly settled by a specific contract provision. Obviously, the discretion to use float time is something a contractor should consider bargaining for in the contract. However, failing a clear allocation of this resource or even worse facing a contract document allocating float to the owner, the contractor should consider preparing his schedule to show minimal float so that he can exercise greater control over his work activities.
Come on, are you to submit a schedule that will put you in a difficult claim situation?
I shall assume you are not so fool and will not submitt such a schedule that will put you in a difficult claim situation, then you will need a second scehdule to perform actual management.
Regards,
Rafael
Obviously this will depend on the legal jurisdiction under which your contract is being administered, but I am not aware of any contract law or legal decisions which outright bans the use of ALAP constraints.
Constraints should be used with caution, but as long as you can demostrate the ALAP constraint reflects the reality of the planned working logic, I would fight to retain it. Use of ALAP to ensure deliveries are not programmed to arrive months before required is in my view quite justified.
If you can, avoid having seperate programmes for project and contract management, as previously suggested. Sometimes a difficult client makes this unavoidable, but it is not good practise.
If the contract schedule cannot be used for management then keep two versions, one for the contract and one to actually manage the job.
Hi ;
It may vary depend on the project and project specification.
Email: PPadmin@planningplanet.com
Replies