Anoon,

Essentially yes.  The NEC ECC Contract has two parties - Employer/Client and Contractor.

The Project Manager is an appointed Agent of Client/Employer, and any failure of duty may consititute breach by Client/Employer.  Has duties somewhat similar to Engineer in FIDIC (though lots of differences in the details.)  Approves the "Accepted Programme."

With further apologies to anu, Ben, and Mike... hoping this will be my last "contribution" here.

Rafael and Anoon,

1. As conceived, NEC is a collaboration-oriented contract form that is intended to serve the needs of Project Managers and Contractors, not lawyers.  The obligations (and incentives) of the parties are substantially changed from traditional contract forms, so the behaviors are (supposedly) different from what one would traditionally expect.  The schedule also plays a much bigger role and imposes certain extra-contractual duties on both parties.  In other words, its intention is to do away with the caricatures of the abusive owner and the sly, cheating contractor - both practicing a zero-sum game - and replace them with a competent team working together to achieve successful completion for the benefit of both parties. Nevertheless, old habits die hard....
2. I believe the primary value of the TRA is as stated in the definition - i.e. it allows/forces the Contractor to explicitly accept and address the schedule risks which are his alone.  The transparency provides the Project Manager with some confidence that the Contractor is a) able to achieve the required schedule, and b) not implicitly shifting schedule risks back to the Project Manager.  I'd agree the results are not useful for day to day field management.  When a "Compensation Event" (i.e. a change) arises, however, the Contractor is entitled to include TRA in any time extension.  The existence of well-founded TRA in the "Accepted Programme" - and the confidence it inspires - can streamline the acceptance of such TRA in the extension request.
3. Aside from confidence-building, I see TRA as something to be removed prior to some mid-course schedule risk analysis (e.g. simulation).  That's a rarity after contract award in my experience.

Tom thank you again,

I just bookmarked the reference.

• I was under the impression that the whole duration of activity always belonged to the contractor. If 5 days then, day 1, day 2,.. , day 5 (call day 5 TRA) all belongs to the contractor. 
• It makes no difference if you need activity to be 11 days without any padding and say it is 10 days + 1 day TRA. 
• Naive to believe a contractor will not do it. 
• It is a pill hard to swallow for me,
• too much frosting makes me sick,
• too much effort for something that is so useless.

I am not a legal expert so I need help to see the light on this that seems nonsense to me.

Best Regards,

Rafael

Rafael, no problem.

This is directly from the NEC website - https://www.neccontract.com/About-NEC/NEC-Dictionary

Time risk allowance
This allowance is made by the contractor (in the ECC) when preparing his programme. These are owned by the contractor and provided to demonstrate that the contractor has made due allowance for risks which are his under the contract.
They must be realistic - unrealistic allowances could prevent the project manager from accepting the programme.

The TRA is one of several key attributes (in addition to float) that must be displayed for each activity in the schedule.    

 

Rafael,

No offense was intended by my post, which was directed at Anoon, not you.  The words that I took exception to were not yours; rather, they were in the article you linked - from the "Practical Law Construction Blog."   In that short article, the author

• invents a new term ("activity float"),
• states that "activity float" and "terminal float" are things that the "contractor adds" to his schedule, and
• suggests that the contractors in NEC contracts should claim ownership of "an activity float" by slapping a "TRA" label on it. 

From my perspective, those absurdities were written by someone who understands neither the basic concepts of logic-based scheduling nor the applications of those concepts in the NEC ECC.  Anu's reference to it as a "great article" seems misplaced.

I don't advocate padded activity durations in project schedules, and to the best of my knowledge the NEC terms don't explicitly advocate it either.  (It's the commenters and advice blogs like the one you linked that seem to push the idea.)  Nevertheless, padding of durations is the single most common "risk management approach" for schedules that I've encountered in recent years (since I started paying close attention) among several industries in the USA, and the NEC has nothing to do with them.  Though I've never been directly involved in an NEC contract, the demand for transparency has some appeal. 

I apologize for mis-spelling your name.  I've corrected it in the earlier post.

To anu h (the OP), Mike Testro and the other regular contributors in this Asta PP forum, sorry for the distraction. Carry on.   

    

Ideally, you will hire a certain Contractor for its expertise, meaning the Owner will rely on the Contractor's strategy to execute the tasks with corresponding payment as specified in the contract. Risks in general maybe different between the Owner and the Contractor. In my opinion, the Owner do not need to tell the Contractor exactly how much profit he/she is going to make (It is always a Contractor's business strategy and the Company or Owner have no control over it). So why specify a buffer in the Contract which I believe cannot have any technical basis? Why did I say that? Of course the Contractor have so many ways on where to put the "Bloat" (I love the term, thanks Rafael). For example: Work Productivity Rates can vary in so many ways (for sure you knew that), similarly, exact number of activities can never be determined prior to the signing of the contract. Well, I guess the question is: Who exactly the buffer or TRA intends to protect?

CPM schedules are complex; blind activity bloating can distort your plan in undesired and unsuspecting way.  

In the following example 10% activity bloating across the board caused an increase in project duration of 11.20 days over non-bloated schedule duration of 23 days. Because of traffic issues pouring mat foundation can only be scheduled for Saturdays. Due to fractional days calculated by the 10% increase pouring started late on bloated schedule and the model scheduled the remaining to next Saturday. 

Everyone with basic understanding of project risk modeling knows that activity durations are correlated when same resources are used for similar production activities. This correlation is difficult if not impossible to calculate. If padding activity durations then such padding shall be correlated, crude % calculation is wrong.

If you are serious about risk management you should get a full copy of the following paper. 

• https://www.pmi.org/learning/library/monte-carlo-simulations-project-networks-mislead-2537
• While Spider Project provides for Monte Carlo I find the 3 scenarios approach as suggested by Spider Project team superior to Monte Carlo.  The 3 scenarios approach can overcome all of the weakness in Monte Carlo simulations mentioned in this paper, a methodology that can be implemented within any CPM tool.

Our Project Managers use optimistic schedules for field management, they do not bloat activity durations, they know how bloating can impact the schedule. They know about parkinsons's law and understand any extra day will most likely be used. They know that the schedule used for field management shall never be bloated in any way, no matter if explicit or not. Task padding undermines the effectiveness of CPM networks in managing for timely completion.

We use probabilistic methods. Monte Carlo is perhaps the best known but not the only one that can be appliet to schedule networks.  We believe every uncertainty should be addressed via Risk Management, not Padding. 

Our Project Managers use the concept of Terminal Float to keep good probabilities of success to meet each contract milestone.

Anoon,

TRA has nothing to do with float.  The article Rafael linked goes off the rails in confusing/conflating the two terms.  It's not the only one I've seen among some of these legal sites that do not comprehend scheduling.

As I understand the NEC requirement, the contractor is obligated to a) consider and account for the schedule risks that he owns under the contract, b) prepare a schedule that is realistic with respect to those risks, and c) transparently display his risk buffering in the schedule - i.e. TRA.  (The "realistic" requirement has been used to promote the distribution of explicit TRAs in the schedule, corresponding to known risks, rather than collecting them at the end.) IF the contractor chooses to address schedule risk by padding activity durations, then he needs to explicitly show the amount of padding as TRA.  Alternately, he may choose NOT to pad durations but to include explicit buffer activities (i.e. 100% TRA) for specific risks.  In any case, the requirement for explict TRAs ensures that they are handled fairly during any mid-course corrections.

Terminal Float is like Project Float.  Formally it is not a fixed buffer, as it expands or contracts to fit the interval between Planned Completion and the (Contract) Completion dates.  It is owned by the Contractor.  Interestingly, any unused TRAs along the critical path automatically aggregate to the Terminal Float.   

Sorry for the interruption, I just want to ask (if I may). What do you exactly mean, is it Task specific Float or Project Float?

Is it Free Float or Total Float? I might agree with Rafael on this, that whenever you update your schedule say for example: on a daily basis, then everything changes. If it is a contract requirement then I guess it is not credible. As why specify a contract requirement that you know beforehand that it is variable and cannot be controlled? (Just my unsolicited opinion). 

I agree about bloating but if the TRA is open and visible for what it is then it should be acceptable.

Hi Ben

Why not consider a single non-modelled resource named TRA that has a calendar with 10% reduced hours which would extend the fully modelled duration but not disturb the logic.

Best regards

Mike Testro

TRA is a requirement of the NEC form of contract.  The NEC requires two things from the schedule in the contract clauses.

One is “terminal float” – which Powerproject covers with a Buffer Task.  The second is the TRA. This is an allowance per task that needs to be noted and is the contingency within each task for the “extra” risk -allowance above the “normal” duration.

Presently in Poweproject, this is acheived by users creating a UDF (or formulae showing, say, 10% of the task-duration) and type in an amount – which represents the amount of the task-duration that is assigned as a TRA.  Therefore, the is no out the box column for TRA but you can create your own using the UDF functionality.

The TRA (and the terminal float) belong to the contractor so if you had a 10-day task and did it in 9-days that extra day is added to the terminal float at the end of the plan.

For future versions of Powerproject, we are considering implementing specific behaviour to handle TRA as this form of contract is becoming increasingly popular.  We'd be interested to hear the thoughts of other existing users on how they think we can better represent TRA?

Ben @ Elecosoft