Contingency is probably the most misunderstood allowance in
a project estimate, right from its initial definition to its application during
the course of the project. Numerous companies use contingency in varying ways.
The problem is, with no one systematic approach there is no actual set of rules
or guidelines to follow. The application of contingency is really based upon
the definition that the owner of the estimate has for contingency.
The purpose of this paper then is to define what CMS Inc.’s
definition of contingency is when we believe it should be used, and how it
should be utilized as a forecast tool as part of the overall cost summary, and
project forecast at completion. In order to do that, we must recognize that we
do not have the only definition of contingency. Some companies have specific
rules about the application of contingency, which need to be followed during
the course of a project. As well, contractors and sub-contractors have their
own definition of contingency. These definitions of contingency are normally
slightly different to suit a different purpose.
CMS Inc. will use the following definition: Contingency is
an allowance to mitigate risk to the project.
This allowance is based on the level of definition at the
time of the estimate, and is to cover the risk of scope growth due to
incomplete definition. Even with a Class II or final estimate with a plus or
minus 10% accuracy, the scope is really based on 10% of the engineering, maybe
15% if the owner allows a high degree of front-end engineering. Even when the
design basis and specifications are clear, the actual details of how we will
execute the project are not. Consequently, contingency is there to mitigate the
risk because of expected scope growth. Since contingency is there for risk then
it should be considered as a risk allowance to be run down as the project
progresses. As more of the project is committed, there is less risk to the
project and less of an allowance is required.
There are various methods to run down contingency.
Contingency can be rundown linearly, as a percentage of commitment, against
specific events, or matching progress. All of these methods are acceptable as
long as a plan has been constructed to run them down.
Our preference is to run them down on a linear basis holding
10% of the contingency for after mechanical completion. This final 10% of
contingency is there to cover changes that are required during the
commissioning and start-up stages. The 10% is an acceptable number based on historical
data and experiences. This ensures that there are reasonable funds available to
make changes should something be found to be deficient in the design during
commissioning, while not holding on to excess funds that could be more
beneficial if applied elsewhere.
With the use of the Monte Carlo analysis risk programs,
which is a system where risk is assigned to specific tasks, a contingency
allowance is calculated based upon the overall calculated probability of
success. Contingency rundown should be based on the completion of those
specific tasks. As a task is completed the contingency for that task should
also be run down.
The advantages of running it down on a continuous basis are
that we do not see contingency as a cash account, we see it as an allowance and
a forecast buffer. At the start of the project we are really saying our
forecast is accurate to 10%, so we have added 10% contingency. As we progress
through the project, the level of unknown decreases as commitments are made and
work completed. As the unknowns decrease, the risk decreases and the need to
fund that risk decreases.
CMS Inc.’s position is that running it down linearly and
charting it creates cost awareness amongst the project team. Especially in the
early stages when we are still working the process details, and designers are
looking to design the best possible plant for the owner. During this time there
is often a tendency to forget that the project was appropriated on a certain
level of quality, and that construction has risk.
Graphically showing how much change we would expect, and how
much additional scope is being added quickly communicates how well we are doing
in managing changes to the scope of the project. With the plan and results on a
chart, if we are above the plan curve you can see quite clearly too much scope
is being added to the project. Conversely, if we are below the curve, not as
much scope is being added and management becomes more confident that the scope
will be delivered for the appropriate dollars.
Only allowing the current budget to change with an approved
scope change will keep the playing field fair for the contractor and the owner.
The contractor will be held accountable to a true budget, based on their
estimate of the cost plus the additional costs for scope that has been added
and approved by the owner during the execution of the project.
By not allowing contingency to be used for performance
issues, we can quickly identify a variance between the forecast and the current
control budget. These variances will indicate areas of either poor performance
or estimating problems. The other advantage, apart from identifying a problem
early and taking actions to mitigate it, is that at the end of project we can
quickly reconcile the final costs back to the ‘class two’ or ‘final’ estimate.
This provides a two-fold advantage in that it also aids the
estimating agency in compiling data in order to close the loop on their
estimating factors. If they find that they are consistently high in one area,
they have sufficient evidence to change their estimating unit. Equally, if they
are low in an area they have the opportunity to change it at the same time. The
basis of this also helps to modify a standard estimating database for different
locations and work conditions.
Then a company could estimate a job the same way for any
location and then apply a series of factors based on the historical data that
allows them to bring that estimate into a more probable number. A more accurate
estimate would make for a more effective use of funds. After all, there is no
sense in returning 20% of the appropriated funds, and there is no value to an
organization in trying to do a $200 million project for $150 million. So the
accuracy of the estimate is a key factor and an important benefit of not using
contingency as a buffer to the forecast.
A secondary note on the use of contingency; changes to
fabricated items during the course of completing engineering would not be
considered added scope. Budgets for equipment and materials should also include
allowances for changes made during fabrication, and growth in material
quantity. This would be added to what was committed and the growth allowance
again would be managed, but the commitment plus the growth allowance would end
up being your forecast. This applies in the field also.
It has never been known for a construction contractor to
come on to a project and execute the scope exactly, as per the drawings, with
everything fitting perfectly. There is always some level of change but this
amount is dependant upon on the quality of the package put together or the
quality of the engineering and the quality of the drawings. Field changes must
also be allowed for in the forecast. They need to be segregated into scope
changes, errors or rework. True scope changes would result in a change in
budget. The error and rework would become a measure of performance.
As we will address in our paper on Change Management, you
must really consider that there are three types of changes to a project.
First, the big “S” scope change is a change in the project
basis, i.e. a change in the original definition of the project.
Second, is the small “s” scope change, which are the ones
that are required to make the project safe and operable.
Thirdly, are deviations that really reflect project
performance such as over-runs in engineering, or the fact that a piece of
equipment cost more than what was originally estimated. These are trend changes
or estimating errors, but not additional scope. For example, if you are
purchasing a 90,000-barrel tank and the estimate was a million dollars for the
tank. When it was actually tendered and awarded, the best bid was $1.2 million.
This would give you a trend for $200,000. To cover this trend off with
contingency is not an acceptable way to use it since this is the same tank as
described in the basis nothing has changed, we just got the cost wrong.
In the next section, we will discuss how we see the misuse
of contingency and explain why we feel that there is an appropriate way to use
Contingency is used improperly in many ways.
For one, it is not there to cover additional scope due to a
change in basis. For example, if the project is to deliver a plant capable of
producing 20,000 bpd and the Owner changes it to 22,000 bpd then the costs
associated with the increase in capacity should be funded separately, including
its own contingency. If during the course of design you needed to put in two
additional heat exchangers, then this would be what we term as a small “s”
scope change. This is an addition to the scope as defined by the design
specification, but not a scope change as defined by the basis. This means we
are still building a 20,000 bpd unit, however we need additional heat
exchangers to make the process work. The budget for those heat exchangers,
engineering associated with them, and all other associated costs would be
increased to make it fair to the contractor. So the sum total of all of those
small 's' scope changes should be equal to the contingency that was allotted to
the project. However, we do not actually make a budgetary transfer. Considering
contingency to be an actual pocket of money is also a mistake. Contingency
should always be considered to be an allowance for the amount of risk that is
left in the project. So early on in the project, we have done little, therefore
we carry the full contingency. Conversely, at the end of the project, the risk
is minimal so we should carry a minimal contingency to the project forecast.
A major concern with contingency is its use as a “slush”
fund. We would normally find that this starts during design engineering, and
the overruns in engineering get covered by that “slush” fund. The reason being
is that is a natural tendency to believe our own organizations operate
effectively. Therefore any cost overrun must have come from the changes
introduced by the owner and not from inefficiencies within ourselves. Changes
are inevitable, especially early in the design stage. The initial design is
really only a preliminary one, although with the use of front end loading and
allowing engineering to progress before the project is appropriated, project
definition is becoming clearer and the overall overruns to the project can be
reduced. As a side note, this will probably lead to a reduction in the amount
of contingency to future projects. Since the risk to scope is becoming less,
then the need for that amount of contingency is also being reduced. Again,
contingency is dependent on the risk that is left to the scope, in the project,
With projects, there are always going to be changes so it is
unrealistic for an engineering contractor to believe that they can do a job
without any changes. Many of the changes are generated during owner reviews.
These changes should be expected and should be allowed for in the contractor’s
original budget. If the contractor has set aggressive targets in order to win
the contract, then that is their business decision, and they should be
accountable for it and not expect the owner to bury their poor performance with
Engineering is not an exact science; it develops as the
project progresses. However, when using contingency to continually ‘fill the
pot’ we easily lose sight of engineering overruns. You will also lose sight of
how much real scope has been added into the job. The contractor has very little
control over new scope brought into the project. Historically, the owner, as a
desire for something better, adds most of the new scope. Reviews or new process
design parameters may cause equipment to be sized or located a little
differently. Performance is totally a contractor issue. The contractors are
responsible for their own efficiencies and for managing its personnel. The
owner needs to know the difference.
The other danger of using contingency to fill the pot is
that no one is accountable for the budget. Every time someone says, “we had to
change this”, or “it took us a little longer to do that than we had in the
estimate”, or “this was not quite right so we had to rework this issue”, the
budget is continually moved. It is difficult to track a moving target, forecast
where it is going, and hard to hold those who have control of the budget
accountable for the budget. If no one is accountable then it makes it difficult
to manage the project effectively.
A greater danger of using contingency as a “slush” fund is
that the issues causing project overruns become hidden, and therefore cannot be
readily dealt with. The filling of the pot technique allows the contractor to
continue working without the owner recognizing that there is a problem. This removes
the ability to see the problems and we lose the ability to see the
Since engineering and procurement budgets are the first to
be used, they would also be the first to be topped up with the “slush” fund. By
the time we go into the field to construct the project, there is insufficient
contingency left to manage the risk through the execution stage of the project.
Once the project reaches the execution phase, you have reached the point of no
return. Changes in the way the job is to be executed are legitimate
applications of contingencies. There is always an inherit risk in construction.
There is a risk to the availability of manpower, or having to do things in a
different sequence, so contingency is there for the owner to cover the risk and
to take advantage of opportunities that may arise. Consequently, if there were
one overwhelming misuse in applying contingency, it would have to be its use as
a “slush” fund.
We will summarize CMS Inc.'s position on the use of
contingency as follows:
Contingency is an allowance for unknown scope
It must have a rundown plan, developed early in
CMS Inc.'s preference is to run it down linearly
over time, holding 10% back for completion / start up activities
Contingency is not a slush fund to be used to
top up poorly performing areas
By Martin Smith - CMS-Inc