Contingency as a Buffer and the Case for an “Adjustment to Balance” Allowance

By Ghaith Al-Hiyari posted 03-10-2018 18:10

  

I just finished reading one of technical articles in the Cost Engineering Journal  (Jan / Feb 2018 edition). The article is titled “How to Successfully Use Earned Value on Projects” by Joseph Lukas, PE, CCP.

While the article had tons of useful tips and laid down the general sound principles for EVM. One offshoot paragraph that discussed schedule and budget contingency management left me a bit unsettled. The paragraph reads as follows:

The reason for having a schedule contingency is to buffer changes to the project completion date.Each time a schedule is updated, the completion date can change based on the actual progress of tasks . However, clients find it frustrating when the project team gives them a new completion date every-time a schedule update is done.A better approach is to adjust the project contingency duration up or down based on actual progress to keep the project completion date constant.every time a schedule update is done.”


I can’t help but feel objection for using a contingency allowance, whether it is in its cost or schedule form to balance the bottom-line of the project cost or schedule to a specific number or date. I strongly suggest that the contingency draw-down should follow the rules that contingency was planned for. If contingency was made available to counter certain risks or uncertainties in the project, those allowances should be drawn down when those risk events cease to exist.

Now, if clients or management find it frustrating when the project team gives them a new completion date or bottom line at every schedule or cost update, which is understandable, an adjustment to balance line item or task, can be introduced to the bottom line of the cost report or schedule, independent of the contingency allowance, to tune out any nominal fluctuations in the bottom-line of the schedule.


I think the separation between the contingency allowance drawdown and the adjustment to balance buffer can promote sound cost and schedule management.


I would be happy to hear your thoughts on this.

Regards,
Ghaith

2 comments
30 views

Permalink

Comments

03-21-2018 20:36

Hi John, Thank you for your comments and thoughts. I think this is a subject that requires much needed debate and discussion.Here is why there is a growing following to the idea that contingency should not be looked at from a pure mathematical & probabilistic approach. It is one of the angles to be tackled from, but not the only one. 

In many cases, contingency allowance is expected to cater for more than just systematic risks, such as project specific ones that are not covered by any other specific allowance.

The emergence of Mega multibillion dollar projects, with various components that carry variable risk profiles and levels of design detail, makes managing hundreds of millions of contingency dollars in a single line item at the bottom of the project baseline , into an overly simplistic approach that does not cater for the specific uniqueness of the underlying risks. 

An example of the challenges faced  when dealing with a project contingency allowance  in aggregate is how to establish when the contingency should be used? and the development of a time phased contingency plan. Many Asset Owners with cost driven projects and fiscal  funding constraints are not satisfied with just determining the overall project contingency allowance. They require breaking that contingency allowance over the project number of fiscal years, with each year having it's own contingency and drawdown curve.This cannot be done without having a quantifiable breakdown of the contingency allowance. Which could be at the  WBS level and/ or inline with the risk breakdown structure. 

A similar challenge will be experienced when we try to distribute contingency responsibility across the project organization.The project team that is managing a specific scope should have access to the contingency allowance associated with that scope.

Hence, there is a  growing belief that the adjustment of a blanket contingency allowance at the bottom of the baseline budget or schedule to offset project overruns might not be the best way to conduct proactive cost and schedule management, which we are tirelessly promoting in an industry that is plagued with schedule and cost overruns.

I must agree that nailing down the contingency breakdown to the cent may not be attainable. However, a weighted breakdown & allocation that reflects the project risks profile (systematic & project specific) will significantly improve forecasting visibility.

Reporting potential forecasted cost overruns should not wait until the contingency allowance is significantly depleted. It should start, in my opinion, at the moment when the risk impact of a certain event exceeds what had been allowed for in the project contingency plan.

Here are a few references and resources from the AACE archives that address the same issue. I think there is alot of room for improvement in the way we handle contingency management:

- Significance of WBS in Contingency Modeling, John Gengxin Zhao, 2006 AACE International Transactions, Risk 05

- Contingency Misuse and Other Risk Management Pitfalls, Iqbal Noor, PE CCE ; Robert L. Tichacek, PE, 2009, Cost Engineering, Vol. 51

- Contingency Allocation: A Computer-Aided Approach, Irtishad Ahmad, 1992, AACE Transactions, F.5
Cheers, Ghaith

03-19-2018 08:25

Ghaith, first, we should applaud Mr. Lucas for suggesting a "schedule contingency" which is per RP 70R-12; a practice few use. The question of drawdown is not covered in that RP, but it is my opinion that mechanistic drawdown based on a risk register is not consistent with principles. i.e., contingency is defined as something quantifiable only in "aggregate". Our tools for quantifying it are feeble; we must remain humble that most fail to identify, let alone quantity the risks driving performance (e.g., systemic risks). So we set a buffer and then draw-down based on periodic reassessment of risks on work remaining, not per the risk register as risks are closed. We cannot apply deterministic project control-think to a stochastic value (the illusion of control bias).