(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.
Greetings of the day,
Ownership of float, whether it belongs to employer or contractor. Is it necessary to mention in the contract, if it is not mentioned in the contract to whom it will belong.
For example an employer delayed a non critical activity for 90 days and the float for that activity was 50 days. bcoz of this the project got delayed. Is contractor eligible for an EOT 90 days or just only 40 days.
Thanks n Best Regards
Mudasir Mohammad
Printer-friendly version
Send to friend
Ownership of Float
BACKGROUND
Who owns the float? The purpose of this article is not to re-invent the wheel and dwell in to the complexity which already revolves around this Million dollar question. However, this question commands utmost respect regarding its gravity when it comes to business implications it can have when not properly responded.
The industry has witnessed various standpoints as a response to this question. The wide classifications of these standpoints are as follows:
§ Contractor owns the Float – Contractor Ownership
§ Employer owns the Float – Employer Ownership
§ Project owns the Float – Joint Ownership
In recent times, the paradigm has strongly shifted towards ‘Joint Ownership’ and has gained wide acceptance and recognition.
Various forms of Contracts have introduced clauses to direct and manage this ‘Joint Ownership’ without letting one party to gain undue advantage over the other. Programming methods have been adapted to complement the Contractual requirements and ensure this ‘Joint Ownership’ of float.
This article is focused to contemplate on a consistent and widely applicable practice which can lead to efficient management of the ‘Joint Ownership’ of float. To attain such an objective, let us discuss the ways for best performance of programming methods and complementing contract provisions.
TYPICAL CONTRACT
For the purpose of this discussion let us adapt for example the ‘Construct only’ form of Contract where in the Design responsibility is entirely retained by the Employer and the Contractor is required to perform the Procurement and Construction part of the Contract. Such definition of scope can be termed as ‘Deliverable Portion’.
In principle, in such contractual arrangements the Contractor is paid to perform the scope of services / works as per the design and specifications laid out by the Employer. Needless to say, with reasonable performance of the Contractor’s scope, the success of the performed scope depends heavily on the accuracy, efficiency and timing of the Design / specifications issued by the employer.
In essence, the risks in performing the Deliverable Portions being inter-relative are deemed to be ‘Jointly Owned’ both by the Employer and the Contractor as per their respective Deliverable Portions and hence the risks should be allotted accordingly. The Employer owns the risk of design efficiency and the Contractor owns the risk of construction, with an inter-relation with each other, particularly in matters of time.
CONTRACT PROGRAMME
Given that, ‘Programming’ forms part of the scope to be performed by the Contractor for which the Contractor is being paid by the Employer. The Contract Programme forms the most important document of the Contract which best speaks out the inter-relation of time based risks borne by various parties. This Contract Programme carries primary bearing and implication to all other contract mechanisms regarding time based risks.
Hence as discussed in previous paragraphs, the essence of ‘Risk allocation’ and ‘Joint Ownership’ should also be equally applicable to the Contract Programme with the same effect and strength with particular relevance to the ownership of float. It is highly important to understand that the lack of float in a Contract Programme is a qualified risk to the obligor.
However, the Contract Programme does not share the tangible nature of the ‘Built’ Scope and due to this reason the demarcation and allocation of risks in the Contract Programme becomes very difficult to be properly defined. The topics following in this article are the preferable ways to define and demarcate such risk allocations and mainly ‘Float’.
DELIVERABLE PORTIONS
As explained earlier, the performance of the project depends on Deliverable Portion of the parties involved. The ownership and risk allocation should be based on the portion of each party. Such Deliverable Portions should aptly be reflected in the Contract Programme. Any normal programme in a ‘Construct only’ contract would typically comprise two portions, as following:
§ Design & Detail
§ Procurement & Construction
In normal practice, the Contractor proposes an integrated programme with activities involving both the above portions.
Alternatively, each party can prepare separate programmes for its own Deliverable Portion and coordinate to achieve an integrated programme.
In both the cases, it is highly important that ‘Pacing’ should be avoided both by the Employer and the Contractor while programming for their respective Deliverable Portion. The element of Pacing if adopted by any one party pushes undue risk to the other party and hence leads to unwanted dispute.
The best method to achieve the above intent is to adopt a practice as elucidated below:
§ The Owner floats the tender with a well detailed ‘Deliverable Portion’ programme (Design Programme in this instance)
§ Such a programme should form the integral and final part of the Contract Programme and hence the Contract.
§ It also provides the Contractor an opportunity to build its risk assessment around this programme (while establishing the Contract Programme) and appropriately price the tender to include for its construction delivery risks.
§ It also avoids the imbalance of power and hence the imbalance of risk at a later stage when the Contractor seeks approval / acceptance of the proposed Contract Programme and the Employer with its bargaining power attempts to use the programme for its own benefit.
DEMARCATION
During the integration of Deliverable Portions of the Employer and the Contractor, the portions can be demarcated from each other by placing constraints at terminal nodes of a Deliverable Portion. The programme is otherwise free flowing well within each portion.
Such demarcation segregates the ownership of float and confines the ownership only to the extent of the Deliverable Portion belonging to each party. This approach provides a justifiable share of ‘Joint Ownership’ of float between the parties as per the extent of the Deliverable Portion a party has to perform.
In this case the float available in the Deliverable Portion (Design) shall be owned by the Employer and the float available in the Deliverable Portion (Construction) shall be owned by the Contractor.
TIME RISK ALLOWANCE
In their respective Deliverable Portions, the Employer and the Contractor are encouraged to add reasonable time risk allowance known as ‘Delay Contingency’. Such an allowance is also a kind of float in other guise but with distinct and reserved ownership.
Moreover, apart from the above allowance, the Employer and the Contractor may also agree to assign another ‘Joint Delay Contingency’ to address other ‘Neutral Risks’ in the project.
NOTIFICATION OF WORK PROGRESS
As a practice which is currently upcoming, notification of work progress enables the parties to be aware of consumption of float well before the delay event affects the critical path. This is nothing but notification to the parties about the consumption of float in order to engage in precautionary remediation before any damage is done. More importantly it is reiterating and reserving the float by a party within its Deliverable Portion and notifying the other party of potential breach by float encroachment.
CONCLUSION
Hence a delay event within a Deliverable Portion of an integrated programme is allowed consumption of float available only within that portion. Any further encroachment of float into the other party’s Deliverable Portion is easily identifiable and becomes culpable. Such an approach of float management duly complemented by Contract provisions turns out to be an effective tool in avoidance of lengthy and complicated dispute resolution procedures.
The concluded discussion might not have addressed all specific circumstances of delay occurrence and float ownership but is reasonably sufficient to convey the thought behind the proposed approach. The success of this approach would realize only when adapted by programming practices with project specific diligence and care rather than making a general adaptation. Contributing feedback and suggestions from the readers are most welcome.
Disclaimer: The material contained in this article is provided for general purpose only and does not constitute legal or other professional advice. Appropriate advice should be sought for specific circumstances and before an action is taken.
© Bharath Nagaraj July 2015
Forensic Schedule Analysis April 25, 2011 121 of 134
E. Ownership of Float
In the absence of contrary contractual language, network float is a shared commodity between the owner and the contractor. Conventional interpretation of the principle of shared float allows the use of float on a first-come-first-serve basis, thereby allowing the owner to delay activities on that path up to the point where float is consumed. Therefore, as a corollary, if pacing is defined as the consumption of float, it follows that both owners and contractors are allowed to pace non-critical work.
Project float is the time between the last schedule activity on the baseline schedule and the contractual completion date where the contractual completion date is later than the scheduled completion date. In this case, in the absence of contrary contractual language, project float is owned solely by the contractor.
Seems like there was a fix on last revision I happen to agree.
To me makes a lot of sense as consumption of project float can put the contractor at risk while there is still some float that will have no delaying effect on the execution. As a matter of fact some Monte Carlo algorithms use this knowledge to rule out activities that will never be part of the critical path in their runs, saving a lot of computer time. It only works when not performing resource leveling.
Maybe AACEI and SCL are getting closer.
Hi folks
I'm not sure where Musadir is but the attitude to float is quite different depending on location and contract.
Certainly the Society of Construction Law's Protocol (and the convention in the UK generally) is that float belongs to the project and can therefore be used by the party that needs it first.
However, the Association for the Advancement of cost Engineering International (AACEI) has its own guide document - the "Recommended Practice for forensic Schedule". On the subject of float, it recommends that Project Float is owned solely by the contractor.
The AACEI position in fact more accurately reflects that of the NEC2 and NEC3, even though this is in regular use in the UK. These contracts note a distinction between the "Completion Date" and the "contractor's planned completion date". The contractor's programme, which must be accepted by the Project Manager must identify float.
Clause 63.3 of the NEC2 states - " A delay to the Completion Date is assessed as the length of time that, due to the compensation event, planned Completion is later than planned Completion as shown on the Accepted Programme"
That seems pretty clear. The planned completion may be before the contractual Completion Date. Therefore the contractor owns the float.
Like you say, if delay analysis was easy, everyone would be doing it!
Mike,
EOTs following Ron Winter procedure is easy, any scheduler shall be able to perform, other methodologies, especially forensic methodologies are another story.
Not every job ends in court, usually simple procedures and common sense gives the right answer to most jobs. I hope some day Ron and his AACEI friends find time to issue a similar recommendation to solve the issues of compensation on the Ron.
Best regards,
Rafael
Hi Rafael
If delay analysis was easy anyone could do it.
Float - or lack of it in all its forms - is only one variable to contend with.
To answer Mudasir's question in paractical terms float belongs to whoever grabs it first.
The prudent planner will ensure that enough of it is hidden in his programme to start with.
Best regards
Mike Testro
http://ronwinterconsulting.com/Time_Impact_Analysis.pdf
Suggest using a TIA as described above, one of the many different TIA prescriptions.
Mere use of float values can be misleading as some software are notorious for yielding wrong float values, some even say there are activities that have free float greater than their own total float.
Another reason is that other relevant effects can be missed. Perhaps the most easy is the effect of calendar on the finish duration of a job. Say you can finish in a week but a week delay gets your activities a week latter, into rainy season, or a X-mass recess.
This is one of the issues I have with most delay analysis practices as they pay too much emphasis on float values or longest path that many software cannot handle well, some because of poor handling of calendars, other because some of these calculation do not work under resource leveling.
It is about cause and effect, show it with your model, Ron Winter prescription is easy to apply.
Email: PPadmin@planningplanet.com
Replies