TIME RISK ALLOWANCE

great explenation Ben

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."

Tom, For the sake of clarity: You mean the set-up is: Contractor - Project Manager (Referee) - Owner. Is that what you mean? And the Project Manager approves the Schedule + TRA? If it is then, Ok..(please don't be bothered with my earlier post, I don't know how to use Asta Power Project either). Thanks.

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.

Unsolicited Opinion: For me, it is just a formula for sophisticated and legalized corruption. Upss! Is there any formula? Forget the formula, let's just split it 50-50, 5% for you and 5% for me, Easy! Wait, but how about the retention? Well, honestly...though I'm really grateful for what you have done to the project,..I would say that I'm not really satisfied in terms of quality. Anyway, let's talk about your future project with us. End of Story (sorry only one episode).

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

I am not convinced yet that Time Risk Allowance is any good for field schedule management. 

I wonder how Time Risk Allowance values are used for contract management. 

I understand most claim methodologies are based on cause and effect analysis.  It is difficult for me to visualize how Time Risk Allowance values are to be considered on Time Impact Analysis, on change orders, on delay claims as well as on any other accepted methodology for these purposes.

Time Impact Analysis is based on comparing current contract milestone(s) dates versus the impact of delaying events on the milestone(s).  In a similar way impact on change order is based on schedule model where cost and contract milestones are adjusted accordingly. The same with regard to Delay Claims. 

1. Is there a way to calculate impact of Time Risk Allowance values on Change Order as well as on delay claims?
2. Is there a provision on NEC to give some guidance on the above?
3. Is there a Recommended Practice for dealing with Time Risk Allowance values to calculate impact of Change Order as well as impact of delays ?

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.    

Tom,

Thanks for the clarification, it is welcomed. I agree the article is a disaster, I was looking for a definition of TRA, something new to me as we do not use it at home, I was not concerned in specific comments about float.

I edited for content my postings due to some misunderstanding on my own, sorry for any inconvenience.

If you have a good reference to share for NEC-TRA that would be good.

Once again sorry a hundred times for any inconvenience, my mistake.  When you say the article "Rafael linked" it is cristal clear.

Rafael

 

Tom,

You are correct TRA is not Float but Activity BLOAT! My mistake, sory for any inconvenience.  I noted my confussion when editing my post.  Because english is not my language I use to make such edits after initial post, usually for diction corrections. I was editing my posting while you was submitting yours. 

TRA is explicit Activity Duration Bloating[Padding] ! 

• Bloating distorts true plan, distorts resource demand, distorts time related costs, ...
• Values for TRA as a fixed % of task duration do not make much sense.
• This is not good practice; it promotes planning for delayed successors.

TRA as mandated by the NEC promotes bad scheduling practice. 

Lags are to relationships what durations are to activities. If you pad activity duration then why not padding lags? In the same way you might need to adjust remaining-duration-pad remaining-lag-pad might need tobe adjusted. If NEC requires/mandates activity duration to be padded then it should mandate padding of lag.

By the way my first name is Rafael not Raphael.

Best Regards,

Rafael

Edited for content due to some missunderstanding on my own, sorry for any inconvenience.

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.   

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.   

English is not my language but in this case I find the term “bloating” better than “padding” a term more commonly used.

If you Google for "padding estimates project management" you will find a lot of articles on the subject. I just did it again and got about 522,000 results (0.27 seconds). There is an almost universal consensus that activity padding is wrong.  Mandating activity padding under the label TRA to the point lack of such TRA can be a cause of schedule rejection is wrong.

The end result will be that in order to show some TRA many schedulers will manipulate the numbers as to eliminate padding and transparency will be lost.

 

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.

Many thanks for the very clear explanation Tom, I really appreciate it. However I will surely go with Rafael with this one. "Bloat" will never help in automatic resource leveling, and most importantly, will never show exact critical path. In real life, wise contractors for sure will put a lot of "Bloat" in their tasks, and you legalize them to show even 10%. I guess the one who invented the concept is a Contractor in real life. (again, just my unsolicited opinion).

TRA is explicit Activity Duration Bloating! 

• Bloating distorts true plan, distorts resource demand, distorts time related costs, ...
• Values for TRA as a fixed % of task duration do not make much sense.
• This is not good practice; it promotes planning for delayed successors.
• Contractors’ float in ECC programmes
  • 

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). 

If float continuously varies as the schedule progress should TRA be adjusted upon every update for the thouthands of activities that might have float?

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

Perhaps terminal float should be good enough to reserve some float to the contractor, to me it is a great concept.  No matter what terminal float will always be on the critical path. I wonder why the insistence of some in overdoing it and complicating things.  TRA is like additional sugar on something already sweetened. 

The concept of terminal float is not new, for decades it has been advocated by many. The NEC is pioneer in adding it to contract terms.

BTW - I do not believe activity durations shall be bloated in any way. 

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

http://constructionblog.practicallaw.com/ask-the-team-does-the-contract…;

• Once the ECC mechanism is understood, the danger for a contractor is blindlingly obvious: if it fails to identify each item of activity float as a time risk allowance, it risks its activity float being used up by events for which it is not responsible.

Not sure what it means as I never used NEC3, though I suggest borrowing some of the concepts.