(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.
Good morning
I'm new in this forum so, first of all, I want to thank you anyone who will loose a little bit of its time to reply.
I'm actually working for a structural steel company and I'm experincing trouble in reaching an Approved baseline programme.
In particular I've the following issue, which I try to summarise:
The project is composed by several sub-site, almost indipendent one for the other (say building A, B, C, D).
All building are similar to each other.
We need an access date for each of the building, dictaded by the contractor (to simplify I would say we need the concrete foundation to start erect our steel work on top)
As per subcontract programme we have a total period during which we need to complete all the building with a single milestone at the end. Access dates for each building are clearly defined in the contract.
Given the restrain I've built a programme similar to the one below, including same "resource" link and considering the possibility to work with the same resources/crane jumping from building A to C, for example, bearing in mind also a possible learning curve.
Now we are in the current status:
- the Contractor (who is our client, we are a subcontractor) is late in giving access to building A, C, D and he want to postpone access date.
- Contractor mention the following contract clause: "Use of float-suppression techniques (such as preferential sequencing, special lead/lag restraints, extended activity time or imposed dates) shall be cause for rejection of the proposed Baseline Programme and any revision or updates [...]"
Bearing in mind that, as clearly stated in another clause, "free float [...] is jointly owned by both" can he reject the programme using this?
Basically, in his opinion, there is no reason to link Building A with building C, which are indipendent.
In our view the delay in access A, B, C, instead, create a different overlapping between the buildings, obliging us to bring more resources on site (even if for a shorter period). That's not easy as some resoursces (menagement, special trailers, big cranes, etc.) cannot be easily doubled or, at leaste, not for free and we would loose all advantages of learing curves.
We believe the Approved Baseline should reflect the subcontract situation (which we used to price the job) and any delay of the access dates should be managed later on with revised programme and claim (if any and reasonable).
They substain the floats (i.e. between completion of building A and Milestone) belong to everybody so they can move access dates freely as (looking at the single building only) it is not critical.
What do you think about?
(I hope my explanation is clear enough)
Many thanks
Giordano
Printer-friendly version
Send to friend
Under resource constraining the software simply figure it out the re-sequencing for you and if good software will disclose the new resource dependencies [the dashed links in case of using Spider Project] it will automatically re-align when needed. Keep in mind some software are incapable of disclosing resource dependencies as a different type of link.
If your software is incapable of showing resource dependencies as links different to hard link maybe it will be able to show you the delay reason as some software can do, otherwise you should consider looking for better software capable of disclosing what have been done.
Even in case of no changed conditions you want to know what activities are delayed because of resource constraining, software incapable of disclosing this is very poor and will force you to use archaic methods.
It seems to be the claim of client that he is finding out your solution is far from good, otherwise if your re-sequencing is good there is no need to object to manual methods unless specifically prohibited by the contract specifications that might prohibit use of soft logic instead of automatic resource leveling. I use automatic resource leveling but believe the ones in charge of managing the schedule shall be free of using their preferred method, still scheduling shall be managed, it is not anarchy.
The problem I find here is that you are a Subcontractor telling the General Contractor how to reschedule when it should be that he as a GC takes charge, manage the schedule and require you to follow it, then the impact, if any, you shall be able to claim. I do not see the GC taking the leadership role or maybe it is he is not managing a CPM at all. Maybe he did not took into consideration your resource limits before contracting your company and pretends you provide unlimited resources, now he is changing the contract conditions and shall take responsibility as a GC to manage the schedule and assume responsibility on the impact.
Thank you Mike for your help.
I would prefere also to use "manual" change in the logic instead of automatic leveling of resorces even if it is not simple.
Theexample I proposed, in reality, is a summary and each building is composed by, at least, 30 activities.
To complicate the picture there are also (in tha "actual" situation) partial access dates to certain areas of the building allowing to start somewhere with some activities but not enough to complete the all building.
It seems, in any case, any possible solution pass trought assignment of resources to the programme.
This would allow to compare if a different distribution give right to extra-money but extention of time is difficult to prove and calculate simply mainteining the logic and links of the baseline and simply change acess dates.
Please bear also in mind that we don't have yet an approved baseline programme and this discussion is in place in order to find an agreement on the programme itself.
Your and others commentor help has been really appreciated.
Hi Giordiano
Sorry to come late into this discussion but you are facing a typical Sub-Contract claim situation.
The solution is application of an As Planned v As Built analysis.
Youre baseline is driven by the agreed planned access dates.
These have to be replaced by the As Built access dates and the programme rescheduled.
Now - if the delay can be mitigated by redeployment of key resources then this must be taken into account.
For instance if the original deployment was for block A > B > C > D but the access dates were A > D > C > B then you are obliged to re deploy your key resource to the new sequence - provided always that it did not cost you any money.
This is achieved by adjustment of the soft logic - Resource levelling does not enter into the argument.
Rafael + Vladimir and I have had this discussion over many years but this is the first time it has cropped up in an delay analysis topic.
The reason why not to do it is that once you have pressed the "resource level" button it is very difficult to find out what your software hase actually done - andif you don't know then how are you going to convince a Judge?
When you adjust the logic you can write down what you have changed and what the result is for every change.
Keep it simple.
Best regards
Mike Testro
Baseline Schedule.
Revised schedule using preferential logic - for illustration purposes only access to Building A was delayed.
Revised using resource leveling and no preferential logic - because the software I use can display resource dependencies I am displaying them as dashed arrow, these are not hard links and whenever the resource leveling figures out there is a better sequencing they will be changed.
As you can see the job without preferential logic ends at month 11 instead of month 14 that results if keeping original preferential logic.
If the special lifts and resources are not continuously required, then there is a possibility that impact is less than under the assumption that they are needed across the board during the whole work on each building. If this is the case more detailed schedule and detailed resource loading is needed for better planning.
Thank you Rafael for your prompt reply.
Your suggestion seems clear:
if I understand well t would be better to load resources on programme and avoid the links.
In that case, with different access dates, we would have a different distribution of resources (maybe extra-cost) but, probably, no right to ask for an extension of time.
This is what we wanted to avoid for several reasons:
Teams can not be perfectly doubled. Some resources needed for special lift, to be done in each locations, are costly and not easy to find in the local market (i.e. strand jacks, special trailers, huge crane). In this respect we can not accept that principle as the programme (without link from building to building) could potentialy show several lifting with strand jacks ("special operation" in terms of resources and procurament time of equipment) at the same time and this is not possible to us.
Than, as you can imagine, 9 girls cannot do a baby in a month and we would not like to accept the principle that our contract duration can be "legally" squezeed putting all the activities in parallel at the end of our contract period.
At least the baseline should reflect a picture wich is the one in the subcontract agreement and approved considering the information we had at the time it was signed (including amount of resources that we planned to use considering a certain total duration).
Than, if access changes or are delayed, accelarations, time and cost impacts (if any) should be assested.
Is this position correct?
Many thanks again for your help.
The use of preferential logic instead of true resource leveling is tricky.
Because the work on the buildings is independent of one another if you delay Building A it does not mean an automatic delay on any of the remaining buildings you artificially linked using preferential logic as to force the elimination of resource overloads. To avoid this trap many specifications prohibit the use of preferential logic as a substitute of resource leveling, therefore try with the following.
Email: PPadmin@planningplanet.com
Replies